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

[Parav Pandit <parav@nvidia.com>]

> 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?

> "
> +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.
New fields donât need to be placed in PCI cap, because no driver is looking there.

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.