On Thu, Jan 11, 2018 at 6:31 AM, Wei Wang <address@hidden> wrote:
On 01/11/2018 12:14 AM, Stefan Hajnoczi wrote:
2) requires the driver to join the vhost-user negotiation.
The driver must participate in vhost-user negotiation. The vhost-pci
patches try to avoid this by taking features bits on the QEMU
command-line and hardcoding the number of supported virtqueues. That
doesn't work in production environments because:
1. What if the driver inside the VM has been updated and now supports
different features?
2. What if the user isn't allowed to modify the VM configuration?
3. What if the management software doesn't expose the feature bits
command-line parameter?
4. What if the number of virtqueues must be different from QEMU's
default value to limit resource consumption?
Users will find it incovenient to manually enter feature bits for the
driver they are using. The driver needs to be part of negotiation so
it can indicate which features are supported, how many virtqueues,
etc.
Without above two, the solution already works well, so I'm not sure why would
we need the above two from functionality point of view.
The "[PATCH v3 0/7] Vhost-pci for inter-VM communication" series is
incomplete. It is a subset of vhost-user-net and it works only for
poll-mode drivers. It's the requirements that haven't been covered by
the vhost-pci patch series yet that make me prefer the
virtio-vhost-user approach.
The virtio device design needs to be capable of supporting the rest of
vhost-user functionality in the future. Once the code is merged in
QEMU and DPDK it will be very difficult to make changes to the virtio
device.