On Tue, Dec 19, 2017 at 2:56 PM, Michael S. Tsirkin <m...@redhat.com> 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!
