OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



> From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> On
> Behalf Of Michael S. Tsirkin
> Sent: Monday, June 5, 2023 5:57 PM

> > 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.
>
Ok. so we at least converge on it. :)
 
> No. The VMM talks to either PF for config space or VF for data path.
>
Ok. than offset 0 for notification.

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

I really don't understand what you want to say.
What I explained above is for SF (not VF), you asked things for VF...

You suggested that tiny stub vfio driver to perform discovery of notification must be done only through the VF without explaining "why such rationale" when there is anyway VF-PF driver interaction for the AQ.

But anyway, we need to progress; since the notify offset of 0 is acceptable for legacy VF notifications as you suggest, 

I will drop the 5th notify query command for now.
And add description to use the existing notify capability of VF with notify offset of 0 for legacy q notifications. 

Rolling v4 now.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]