On Fri, Mar 3, 2023 at 12:31 AM Michael S. Tsirkin <m...@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 <m...@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
