Hello! > OK so it's a misconfigured kernel. > Fine but I'm not happy with silently using userspace instead.
It's not silent. You get two warnings in the log: --- cut --- 2015-11-13T08:43:51.146802Z qemu-system-aarch64: KVM does not support MMIO eventfds 2015-11-13T08:43:51.146915Z qemu-system-aarch64: unable to start vhost net: 38: falling back on userspace virtio --- cut --- > If people ask for vhost they should get it. > How about > - kicking vhost from userspace This can be interesting, this would be similar to forwarding IRQ through the userspace if we don't have irqfds. But i believe this would require a lot to implement. To tell the truth, i'm not ready for this. Actually, for now i just want to provide some way to switch kernels and use the same userspace configuration, and make all possible conbinations working somehow, without critical faults. Anyway, if we want to use vhost, i suppose we want to get maximum performance, which can not be achieved with userspace event forwarding, so it's IMHO okay just to fallback to userspace (which we already do, just we miss to catch some situations), just explain why. I even plan to add another warning, when eventfds work and irqfds don't. Currently we just silently fall back to userspace IRQ forwarding. > or > - failing vhost init That's what my patch does. vhost_dev_enable_notifiers () is called from within vhost-net init routine. I intentionally patch vhost.c so that it should also have the same effect on vhost-scsi. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia