Re: [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ

[Jason Wang <jasowang@redhat.com>]

å 2023/5/11 21:02, Parav Pandit åé:
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, May 11, 2023 8:55 AM
> > > 1) device features
> > > 2) driver features
> > > 3) queue address
> > > 4) queue size
> > > 5) queue select
> > > 6) queue notify
> > > 7) device status
> > > 8) ISR status
> > > 9) config msix
> > > 10) queue msix
> > > 11) device configuration space
> #9 may not even go to the group owner device.


It the config_msix_vector register so I don't understand why it can't 
work but can work with your proposal.


> What do we gain from bisecting it?


1) No need to deal with the offset in the hardware

2) transport independent

3) avoid duplication with the (legacy support of) transport virtqueue


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

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.

For modern, if the feature is something related to the transport, we 
need new transport interface for sure.


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


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

Thanks


> > > It focuses on the facilities instead of transport specific details
> > > like registers (we don't even need legacy registers in this case), I
> > > gives more deterministic behavior so we don't need to care about the
> > > cross registers read/write.
> > This needs thought, it is definitely more work.  Effort that could be maybe spent
> > on new features.  What is the motivation here? supporting legacy mmio guests?