> From: David Edmondson <[email protected]> > 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)?
