On Sun, May 21, 2023 at 02:44:03PM +0000, Parav Pandit wrote: > > > > From: Michael S. Tsirkin <m...@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 --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org