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

["Michael S. Tsirkin" <mst@redhat.com>]

On Sun, May 21, 2023 at 02:44:03PM +0000, Parav Pandit wrote:
> 
> 
> > 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.

Now I am lost. legacy register access is on top of aq which
sends commands through pf.  how are you going to send
commands without attaching a driver, I don't know.

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

No, on some OS-es (windows, iokit, more) a single driver can't bind to
many devices without a lot of pain.  If you are mapping VF BAR, this has
to be done by VF driver, and please just avoid pain for everyone by
exposing the necessary info through the VF itself.
A capability seems perfect for this.

An alternative is not to map VF BAR at all, steal space from PF BAR instead.
Guest is not accessing this anyway. So I really do not see why not
from software point of view. There's a hardware reason? Could you
talk to hardware guys about this? You objected to AQ too then
hardware guys told you it is not a big deal.


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

How was I supposed to raise this issue on v1 if it was not there?
Stop arguing in circles and things will move forward.

If we have trouble converging on the notification thing, how about we
make progress without it for now?  Merge a slow version that sends kicks
through aq, then work on the best way to make notifications faster,
separately.


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

VF(member) driver can't implement AQ commands at all. They are sent to
PF(owner) thus by PF(owner) driver.  In virt configs, VMM can trap
legacy access and talk to owner driver to send them.  It can also talk
to member driver to send notifications.  You can I guess have VMM get
member BAR offsets from owner and pass them to member for mapping. This
raises all kind of questions of trust.
If you can map BAR from PF that would be simplest, VMM then only pokes
at PF and not VF. If not then we really should expose this info
n the VF if at all possible.





-- 
MST