> From: Jason Wang <jasow...@redhat.com> > Sent: Monday, May 15, 2023 3:31 AM
> > What do we gain from bisecting it? > > > 1) No need to deal with the offset in the hardware > In context of legacy is doesn’t matter much given that its over AQ. > 2) transport independent > AQ commands are transport independent so, it is covered. > 3) avoid duplication with the (legacy support of) transport virtqueue > Modern interface does not need mediation; hence it is not duplication with legacy. > > > Every new additional needs involvement of the hypervisor as Michael noted > below on "effort" point. > > > I'm not sure I get your point. > > If additional effort is not wanted, we need a full PCI over adminq, > that's what I suggested, then we don't need any extension for any new > features probably. > When there is already a PCI VF, I don’t see why one would implement "PCI over adminq". It is impractical. And SF/SIOV is bit still far in future. When "PCI over adminq" happen, it is really a very different set of commands that emulated the "PCI virtio" device. I don’t know when/why. > If we choose to invent dedicated adminq commands: > > For legacy, we don't need any new additional effort since the above 11 > maps to the legacy virtio-pci facilities. > Only few commands are needed. Modern interface config doesn’t travel through mediation. > For modern, if the feature is something related to the transport, we > need new transport interface for sure. > Everything is transport as it flows to/from driver to device covered in the respective transport chapter. 😊 > > > > > The register offset and read/write is far simpler interface for hypervisor. > > > If this is true, why not go full PCI over adminq? Hypervisor in this > case even don't need to deal with config space. > I don’t see a use case now and its extremely heavy to do so and it doesn’t apply to PCI VFs at all. > > > > > Not to do cross register access is what we need to define in the spec for > > 1.x or > future things. > > > You can't assume the hypervisor behaviors, so the device or at least the > spec should be ready for that. > My above comment is for the driver to device interface to access registers on its natural boundary. Which part of the proposal assumes a hypervisor behavior? Nothing to do with hypervisor.
