On Mon, Jan 22, 2018 at 07:09:06PM +0800, Wei Wang wrote: > On 01/19/2018 09:06 PM, Stefan Hajnoczi wrote: > Thanks for the quick implementation. Not sure if the following issues could > be solved with this approach: > - After we boot the slave VM, if we don't run the virtio-vhost-user driver > (i.e. testpmd), then the master VM couldn't boot, because the booting of the > virtio-net device relies on a negotiation with the virtio-vhost-user driver.
This is a limitation of QEMU's vhost-user master implementation which also affects AF_UNIX. It cannot be solved by this patch series since this is the slave side. Here is what I suggest. Introduce a new VIRTIO feature bit: #define VIRTIO_F_DEVICE_READY 34 When the device supports this bit we extend the device initialization procedure. If the device is not yet ready, the FEATURES_OK status bit is not accepted by the device. Device initialization fails temporarily but the device may raise the configuration change interrupt to indicate that device initialization should be retried. Using a feature bit guarantees that existing device and driver behavior remains unchanged. On the QEMU side the changes are: 1. Virtio hardware registers and configuration space are available even when vhost-user is disconnected. This shouldn't be difficult to implement because QEMU always has a virtio device model for each vhost-user device. We just need to put dummy values in the registers/configuration space until vhost-user has connected. 2. When vhost-user connects, raise the configuration change interrupt and allow vhost-user to process. On the guest side the changes are: 1. virtio_pci.ko must set VIRTIO_F_DEVICE_READY and handle !FEATURES_OK by waiting for the configuration change interrupt and retrying. This doesn't fully solve the problem because it assumes that a connected slave always responds to VIRTIO hardware register accesses (e.g. get/set features). If the slave crashes but leaves the virtio-vhost-user PCI adapter connected then vhost-user requests from the master go unanswered and cause hangs... > - Suppose in the future there is also a kernel virtio-vhost-user driver as > other PCI devices, can we unbind the kernel driver first, and then bind the > device to the dpdk driver? A normal PCI device should be able to smoothly > switch between the kernel driver and dpdk driver. It depends what you mean by "smoothly switch". If you mean whether it's possible to go from a kernel driver to vfio-pci, then the answer is yes. But if the kernel driver has an established vhost-user connection then it will be closed. This is the same as reconnecting with AF_UNIX vhost-user. Stefan
signature.asc
Description: PGP signature
