> From: Michael S. Tsirkin <[email protected]> > Sent: Monday, June 5, 2023 9:50 AM
> > Can you explain the motivation of : why querying notification offset via the > group member PF is a problem, if there is." > > I tried already, I can repeat if you like: > > So, I am thinking of a model of using a tiny stub driver for the member. This is what is proposed here. > Control path driver is bigger as it operates AQ command, that would be the > owner driver. E.g. for PCI this driver needs to map BAR offsets. The bar belongs to the PCI VF and hence BAR mapping will be done by the VF tiny stub driver, aka vfio vf driver in this proposal. And control path driver provides the AQ facility to issue the commands for register read/write. > Then it handles all data path for this member: driver and device > notifications. > It is clean and easy on all systems assuming you know offsets at device probe. > But getting it in software from another driver (owner driver) is AFAIK tricky > on > some systems. > We can assume that systems will eventually improve as multiple OS are improving one way or another. > Generally solutions can be found, they can be more or less robust, and if > systems designers have to overcome obstacles in implementing virtio they will > just go to a competing interface as opposed to jump through hoops and work on > extending either the OS or the virtio spec. > > Yes I know your sales department tells you there's no demand for this feature > on anything that is not linux/x86 and maybe arm, and maybe this means there > won't ever be either, but let's just not raise this again can we? E.g. there > was > some interest from microsoft at some point, I think there was a reorg and that > project died but hey you never know. > Anyway, you asked I am trying to answer. > It is not the sales department. MS has zero virtio tc presence to show the interest. MS has zero inbox driver to my knowledge without current feature. Hence, the absence shows lack of interest and hence building something for them with pessimism that they will not extend is not right IMHO. > The cleanest way is just doing things consistently through one device. I would surely do that for all future devices which will be self-contained. The cost of doing that for legacy is not worth the efforts. And since we agree that read/write 4 commands are OK on the AQ, the 5th command is no exception to it. We are not at the point of questioning the existence of 4 commands itself on AQ. > In this case for data path it has to be the VF, so let's just make this part > simple > and self contained. > So data path is on the VF to do driver notifications by the tiny stub vfio vf driver. It queries the PF driver when it wants to use AQ facility. > > > I don't see a problem with AQ that covers VF,SF/SIOV for legacy. > > > > Proposed AQ command is cheap and covers both VF, SF/SIOV. > > Well for SIOV BAR has to be the owner BAR. This was exactly the reason I asked > for this. If it's not to be I think this is my second preference: > no new command at all, and SIOV will come up with its own. So a AQ notify query command services both VF and PF. It always returns the BAR number for the own. A PF would have delegated the window in the PF BAR to the SF/SIOV. And hence, this command is just fine like rest of the 4 commands. (Linux already has SF accessing the PF dedicated BAR for more than 2 years for non virtio device). --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
