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

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

On Mon, Jun 05, 2023 at 04:04:57PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > 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.

Yes I think these 4 are fine.

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

No. The VMM talks to either PF for config space or VF for data path.

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

For the owner? owner of SRIOV group is PF, not VF.

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

It would be fine if it could return PF BAR, but in your proposal
it can't.

> (Linux already has SF accessing the PF dedicated BAR for more than 2 years for non virtio device).


What's the point of this discussion even? You ask some questions
apparently to clarify what issue I'm trying to address.  I try to
clarify. You then turn around and say we agree, there's no issue, all of
this does not matter, case closed.  Whom do you expect to convince with
this line of reasoning? 

-- 
MST