qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] vhost-user graceful connect/disconnect
Date: Wed, 20 Dec 2017 15:56:45 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

On Wed, Dec 20, 2017 at 02:45:48PM +0800, Fam Zheng wrote:
> On Tue, 12/19 16:21, 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.
> > 
> > 2. When the vhost-user connection is established the object emits a QMP
> >    event so management software can hotplug the virtio device:
> > 
> >    VHOST_USER_CONNECTED source=vhost-user0
> > 
> > 3. The management software hotplugs the virtio device:
> > 
> >    (qmp) netdev_add vhost-user,id=netdev0,vhost-user=vhost-user0
> >    (qmp) device_add virtio-net-pci,netdev=netdev0
> 
> Why cannot the management software start the slave then hot plug chardev +
> netdev + virtio-net-pci? That way we don't need the vhost-user connected 
> event.

There's an advantage to keeping the vhost-user object in QEMU:

In Step 1 the vhost-user object pre-initializes the vhost-user slave to
avoid synchronous vhost_*() calls during hotplug (e.g.
vhost_set_owner(), vhost_get_features()).  When vhost_dev_init() and
other code gets called it won't be necessary to block anymore.  This
makes the vhost-user master robust against slaves that respond slowly or
are malicious.

It's messy to do pre-init outside QEMU and then pass the necessary state
in.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]