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 v2 0/2] transport-pci: Introduce legacy registers access using AQ



> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, May 11, 2023 4:58 PM
> 
> On Thu, May 11, 2023 at 08:47:04PM +0000, Parav Pandit wrote:
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Thursday, May 11, 2023 9:39 AM
> > >
> > > On Thu, May 11, 2023 at 01:28:40PM +0000, Parav Pandit wrote:
> > > > This is not the objective to transport all PCI virtio fields over AQ.
> > > > Transport VQ commands proposal commands and commands in this
> > > > proposal
> > > are just fine the way there without quoting it as "transport".
> > >
> > > I mean, it's a transport in a sense of where it will reside in e.g.
> > > linux virtio stack - below virtio core.
> > > We don't save much code there by reusing the same register layout of
> > > legacy pci.
> > > But let's at least make this feature complete, and then we'll see
> > > whether it is cleaner to reuse legacy layout or build a new one.
> >
> > I don't follow your comment about "this feature complete".
> > When you say _this_, it means the feature proposed in this patch of
> supporting legacy over PCI VFs?
> >
> > If so, anything missing in this proposal?
> 
> I think I commented at least on what I see as missing is first of all a need to
> support INT#x emulation since level interrupts are I think not supported for VFs.
> right?

I don't see it mandatory as I responded in [1].
I didn't see your response on [1].

[1] 71d65eb3-c025-9287-0157-81e1d05574d1@nvidia.com/">https://lore.kernel.org/virtio-comment/71d65eb3-c025-9287-0157-81e1d05574d1@nvidia.com/



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