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? -- MST
