[virtio-dev] RE: [virtio-comment] Re: [PATCH 00/11] Introduce transitional mmr pci device

[Parav Pandit <parav@nvidia.com>]

> From: David Edmondson <david.edmondson@oracle.com>
> Sent: Tuesday, May 2, 2023 3:18 AM
> 
> In line with our recent discussion about agreeing requirements for specification
> changes, I wanted to say that we have a significant existing estate of VMs using
> the legacy interface where the customer is disinclined to update their software
> to a newer version (which might consume the 1.x interface).
> 
> Given that, some mechanism for supporting a (mostly) hardware offloaded
> legacy interface would definitely be useful to us, and the proposal here seems
> like a sensible approach.
>

Thanks, David, for the inputs.
I am working on v1 to have legacy interface supported using proposed AQ.

I realized that below listed PCI extended capabilities is not useful for this work because existing capabilities in the legacy region need to be anyway there.
And new AQ interface-based method doesn’t use any new capabilities.
So, I will drop below #5 for now.

Regarding, open question below, the AQ commands for the SR-IOV group are for specific group member.
Hence, will keep the query as VF level, unless we want to optimize this further.
Since its one-time query per VF, it is not hurting the perf.

> > 5. PCI Extended capabilities for all the existing capabilities located
> > in the legacy section.
> > Why?
> > a. This is for the new driver (such as vfio) to always rely on the new
> > capabilities.
> > b. Legacy PCI regions is close to its full capacity.
> >
> > Few option questions:
> > 1. Should the q notification query command be per VF or should be one
> > for all group members (VF)?