Re: [Qemu-devel] vhost-user graceful connect/disconnect

[Stefan Hajnoczi]

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