On Thu, Jan 04, 2018 at 06:53:07PM +0200, Michael S. Tsirkin wrote: > On Tue, Dec 19, 2017 at 04:21:51PM +0000, Stefan Hajnoczi wrote: > > Hi, > > Vhost-user implementations assume the slave is already running before > > the master starts. The slave is required during virtio device > > initialization (e.g. feature bit negotiation) and so it is simplest to > > assume that the master is already available and will respond immediately > > to the VHOST_USER_GET_FEATURES message. > > > > I have thought about how to let master and slave start in any order. > > Some approaches involve changes to the VIRTIO specification so that > > guest drivers can wait until the vhost-user connection is established. > > > > We can avoid spec changes using PCI hotplug: > > > > 1. Introduce a new vhost-user object that manages a connection: > > > > -chardev ... > > -object vhost-user,id=vhost-user0,chardev=chr0 > > > > Note this object is *not* a NetClient. It's a resource for managing > > a vhost-user connection and can be used with any device type (net, > > scsi, blk, etc). > > > > This object tries to establish a connection. When a connection is > > established it sends vhost-user protocol messages to fetch > > information needed for virtio device initialization (like the number > > of virtqueues supported, features bits, etc). This information is > > stashed so that vhost_*() calls later on do not require synchronous > > communication with the vhost-user slave. > > I'm not sure how important or feasible this last part is.
The guest should not hang if the vhost-user slave fails to respond in a timely manner. This is important to prevent failures cascading if a vhost-user network switch hangs, for example. There are a few points where device emulation requires a full vhost-user message exchange. Theses are the vulnerable points. Depending on how virtio emulation is implemented, it may be possible to perform the vhost-user communication out-of-line with vcpu execution. That way the vcpu continues to execute while vhost-user communication is in progress. Unfortunately the VIRTIO_PCI_STATUS/VIRTIO_PCI_COMMON_STATUS hardware register writes are points where vhost-user message exchanges need to happen. That means the vcpu will hang until vhost-user communication has finished. It's not possible to resume guest execution without waiting for the vhost-user slave because the guest might start using the device before the vhost-user slave has been fully initialized. I don't see a way around this problem yet. If everything was async at the virtio hardware level then it would be easy to prevent hangs. Stefan
signature.asc
Description: PGP signature
