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

[Eugenio Perez Martin]

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