qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] vhost: accept VIRTIO_F_ORDER_PLATFORM as a valid SVQ feature


From: Michael S. Tsirkin
Subject: Re: [PATCH] vhost: accept VIRTIO_F_ORDER_PLATFORM as a valid SVQ feature
Date: Thu, 2 Mar 2023 18:31:28 -0500

On Thu, Mar 02, 2023 at 03:47:48PM +0100, Eugenio Perez Martin wrote:
> On Thu, Mar 2, 2023 at 12:43 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Thu, Mar 02, 2023 at 12:30:52PM +0100, Eugenio Perez Martin wrote:
> > > > You need to pass this to guest. My point is that there is no reason to
> > > > get it from the kernel driver. QEMU can figure out whether the flag is
> > > > needed itself.
> > > >
> > >
> > > Ok, I can see now how the HW device does not have all the knowledge to
> > > offer this flag or not. But I'm not sure how qemu can know either.
> > >
> > > If qemu opens /dev/vhost-vdpa-N, how can it know it? It has no way to
> > > tell if the device is sw or hw as far as I know. Am I missing
> > > something?
> > >
> > > Thanks!
> >
> > This is what I said earlier.  You can safely assume vdpa needs this
> > flag. Only exception is vduse and we don't care about performance there.
> >
> 
> Ok now I get your point, thanks for explaining.
> 
> But I'm missing why it is wrong to start using it properly from the
> kernel.
>
> I didn't test vDPA in non x86 / PCI, but if it does not work
> because of the lack of this feature flag the right fix would be to
> offer it, not to start assuming it in qemu, isn't it?
> 
> I can see how "assume VIRTIO_F_ORDER_PLATFORM from qemu" may need code
> comments and extra explanations, but to start offering it properly
> from the device is expected somehow.
> 
> Thanks!

Does kernel always expose it?

-- 
MST




reply via email to

[Prev in Thread] Current Thread [Next in Thread]