Re: [virtio-dev] [PATCH 08/11] transport-pci: Introduce virtio extended capability

[Jason Wang <jasowang@redhat.com>]

On Wed, Apr 12, 2023 at 3:01âAM Parav Pandit <parav@nvidia.com> wrote:
>
>
> > From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> On
> > Behalf Of Jason Wang
> > Sent: Monday, April 10, 2023 11:29 PM
>
> > > However, it is not backward compatible, if the device place them in
> > > extended capability, it will not work.
> > >
> >
> > It is kind of intended since it is only used for new PCI-E features:
> >
> New fields in new extended pci cap area is fine.
> Migrating old fields to be present in the new extended pci cap, is not your intention. Right?

Right, but what I want to say is, such migration may cause unnecessary
problems. And I don't see why it is a must for your legacy MMIO bar
proposal.

>
> > "
> > +The location of the virtio structures that depend on the PCI Express
> > +capability are specified using a vendor-specific extended capabilities
> > +on the extended capabilities list in PCI Express extended configuration
> > +space of the device.
> > "
> >
> > > To make it backward compatible, a device needs to expose existing
> > > structure in legacy area. And extended structure for same capability
> > > in extended pci capability region.
> > >
> > > In other words, it will have to be a both places.
> >
> > Then we will run out of config space again?
> No.
> Only currently defined caps to be placed in two places.

What's the advantage of doing this?

New drivers should provide backward compatibility so they must scan the pci cap.
The Old driver can only scan the pci cap.

> New fields donât need to be placed in PCI cap, because no driver is looking there.

It would be much more simple if we forbid placing new fields in the
PCI cap, it is already out of space.

Thanks

>
> We probably already discussed this in previous email by now.
>
> > Otherwise we need to deal with the
> > case when existing structures were only placed at extended capability. Michael
> > suggest to add a new feature, but the driver may not negotiate the feature
> > which requires more thought.
> >
> Not sure I understand feature bit.
> PCI transport fields existence is usually not dependent on upper layer protocol.
>
> > > We may need it even sooner than this because the AQ patch is expanding
> > > the structure located in legacy area.
> >
> > Just to make sure I understand this, assuming we have adminq, any reason a
> > dedicated pcie ext cap is required?
> >
> No. it was my short sight. I responded right after above text that AQ doesnât need cap extension.