[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]