Re: [Qemu-devel] vhost-pci and virtio-vhost-user

[Wei Wang <wei.w.wang@intel.com>]

On 01/11/2018 05:56 PM, Stefan Hajnoczi wrote:
> On Thu, Jan 11, 2018 at 6:31 AM, Wei Wang <wei.w.wang@intel.com> 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.
>

OK, the advantages of letting the guest join the vhost-user negotiation 
sounds convincing to me. Thanks.



>> 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.

This is how virtio works. A new feature with a new feature bit. Now, we 
let the guest driver join the vhost-user negotiation (including feature 
negotiation), the default device/driver feature negotiation is free to use.
I'm thinking if it is worthwhile to do some kind of mediated 
passthrough, which passes the selected messages only. Because many 
messages are not necessary to be passed down (e.g. VHOST_USER_SEND_RARP 
is not needed for simple VM-to-VM communication), though might be safe 
to do. I plan to see your full passthrough code first, and see if 
changing to mediated passthrough would be simpler.

Best,
Wei