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

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Mar 03, 2023 at 10:08:17AM +0100, Eugenio Perez Martin wrote:
> On Fri, Mar 3, 2023 at 12:31 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > 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?
> >
> 
> As far as I know the only vdpa device exposing it is alibaba/eni_vdpa

That is my point then. qemu should set it and ignore what kernel says.

-- 
MST