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

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

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


Subject: Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state


On Thu, Sep 21, 2023 at 6:39âPM Parav Pandit <parav@nvidia.com> wrote:
>
>
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Thursday, September 21, 2023 3:40 PM
> >
> > On Thu, Sep 21, 2023 at 09:17:53AM +0000, Parav Pandit wrote:
> > > Vdpa stack make total sense when the underlying device is not virtio and
> > hence emulation.
> >
> > Which linux framework is used is kind of beside the point but since you bring
> > this up - not necessarily.
> >
> > E.g. I personally don't care much about "stack" but clearly we need a virtio
> > driver on the host to be involved, teaching vfio about virtio is probably a much
> > worse idea than creating a mode in the vdpa driver which mostly sets up the
> > IOMMU and otherwise gets out of the way of using the VF and just drives the
> > PF.
> Well, vdpa has to drive large many things including cvq, config space, msix and more.

Just to clarify, vDPA has the flexibility to decide if it wants to
deal with the above not (except the MSI-X which is hidden in the vDPA
layer).

That is to say, if vDPA wants, nothing prevents vDPA from assigning
CVQ and config space to guests.

> It can help to overcome some issues as you listed below.
> So that way vdpa over virtio is useful.
>
> In vfio world, there is nothing significant to teach about virtio.

It would be pretty fine if it's nothing, not nothing significant.

Thanks



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