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

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

On Sun, Jun 04, 2023 at 11:40:54PM +0000, Parav Pandit wrote:
> 
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Sunday, June 4, 2023 5:49 PM
> 
> > > Legacy can utilize the 1.x hw plumbing without building new hypothetical PF
> > hardware.
> > 
> > Maybe.
> > Whether 1.x BAR can be reused for legacy would depend on a bunch of factors.
> > E.g. with 1.x using VIRTIO_F_NOTIF_CONFIG_DATA - probably not.
> >
> Not really because legacy doesn't have that feature.
> Legacy notifications are subset of 1.x feature.
> This was also discussed.

So for legacy such hardware will likely not want to use the same BAR.


> > Let's just say, we are not in the position where we dictate these things to OS
> > vendors yet.  One of motivations of the spec is making writing drivers easier so
> > let's add an option for that pls.
> >
> There is no need to add multiple options at this point when the hw vendors are not going to implement.
> When we find another vendor to implement, we can always add the new method.
> Marvell and Nvidia both are forwarding with AQ at present proposal.
> 
> > > VF has BAR for driver notifications. This BAR is used for 1.x and legacy.
> > 
> > But it's the same piece of silicon - be it in PF or in VF.
> > I really don't see why it matters.
> >
> In same piece of silicon one needs to open yet another PCI steering entry to tell that treat this for VF.
> This double size programming is useless.
> 
> Yet again we are discussing same point as before.
> 
> > > There is no need to ask vendors to build new HW to put driver notifications
> > on the PF BAR for VFs, when it already exists on the VF.
> > I'm talking about giving vendors an option not asking them.
> >
> Ok. Understood.
> When a vendor prefers to implement such cross hw forwarding it can be done.
> There isn't a desire to burn and program extra hw for functionality that already exists on the VF.
> Hence, VF's doorbell on PF can be parked for the future option when one actually wants to implement it.

I reached out to windows team to know how big a problem this is. Let's
see.


I have another idea meanwhile: VF already has notification
capability. The only issue is offset has to be queried through modern
BAR.  How about we agree that for legacy, we just agree that offset 0 is
used?  Does not sound like a big sacrifice of memory to me, and we
completely avoid the new command and the need to tie PF and VF.

-- 
MST


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/