RE: [virtio-comment] RE: [PATCH v2 1/2] transport-pci: Introduce legacy registers access commands

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Sunday, May 21, 2023 10:33 AM

> > Yet you initiate same discussion point that we already discussed again after
> summarizing.
> > A driver is not attached to two devices.
> > A driver is attached to a single device.
> 
> And that device is the owner no? to send commands?
>
Not for legacy registers access as discussed before.
 
> > If (legacy_offset == queue_notify_offset)
> >    *db = guest_supplied_q_notify_content; else
> >     virtio_net_send_aq_cmd();
> >
> > "simple" is really a subjective term in this context.
> 
> yes this is qemu. sure.
>
Not limited to QEMU.
A driver will be able to do this as well.

> So we have legacy emulation send commands to VF or to PF.  Okay. But let us
> avoid the need for VF driver to send commands to PF to initialize.
> Just get all information it needs from VF itself.
> 
> 
> Maybe it's a good idea to reuse existing notification capability, or maybe a new
> one, but let's avoid making VF driver depend on PF commands.
>
We agreed in v1 on Jason's suggestion to have the AQ command and yet you and Jason hinder this in v2 with this exact repeated question.
Lets please avoid this and move forward.

> > We have already these design choices and tradeoff in v0 and v1, it doesn't fit
> the requirements.
> 

> So, I am saying one model is small driver for VF and a big one for PF.
> And to keep the VF driver simple, it should get information simply from config
> space capability.

VF driver is small that does usual vfio passthrough work.
PF driver implement AQ for variety of use cases that we listed in the AQ cover letter.
VF driver implements 5 AQ commands that you suggested to split from 2 to 4.