Re: [Qemu-devel] [virtio-dev] [PATCH v3 0/7] Vhost-pci for inter-VM communication

[Stefan Hajnoczi]

On Tue, Dec 19, 2017 at 2:56 PM, Michael S. Tsirkin <address@hidden> wrote:
>>  * Please handle short reads/writes and EAGAIN with the UNIX domain socket.  
>> Do
>>    not use read/write_all() functions because they hang QEMU until I/O
>>    completes.
>
> I'm not sure I agree with this one. vhost-user uses this extensively
> right now. It might be a worth-while goal to drop this limitation
> but I don't see why we should start with vhost-pci.
>
> And in particular, VCPU can't make progress unless a slave is present.

Hang on, we're talking about different things:

The QEMU vhost-user master blocks because vhost_*() functions are
synchronous (they don't use callbacks or yield).  Fixing that is
beyond the scope of this patch series and I'm not asking for it.

This patch series adds a from-scratch vhost-user slave implementation
which has no good reason to be blocking.  A single malicious or broken
guest must not be able to hang a vhost-pci network switch.

>>  * How can the the guest limit the number of virtqueues?
>
> I think it is feasible to pass in host features, # of vqs etc.  Assuming
> compatibility with existing guests, I don't think you can do anything
> else really if you assume that vhost guest might boot after the
> virtio guest.
>
> So either you give up on compatibility, or you allow the vhost
> guest to block the virtio guest.
>
> I think compatibility is more important.
>
> We can later think about ways to add non-blocking behaviour
> as a feature.

I agree it's a separate feature because it will require non-vhost-pci
related changes.

I have posted a separate email thread to discuss a solution.

>>
>>  * Please include tests.  See tests/virtio-net-test.c and
>>    tests/vhost-user-test.c for examples.
>
> Unit tests are nice but an actual way to test without
> running a full blown dpdk stack would be nicer.
> Something along the lines of a port of vhost user bridge
> to the guest.

Yes!