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: [PATCH v3 0/3] transport-pci: Introduce legacy registers access using AQ


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



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