qemu-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Hajnoczi
Subject: [Qemu-devel] vhost-user graceful connect/disconnect
Date: Tue, 19 Dec 2017 16:21:51 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

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

Advantages of this approach:

 * Does not require spec changes.
 * Can be implemented without vhost-user.c qemu_chr_fe_read/write_all()
   calls that hang QEMU until the slave sends data.
 * Allows slave to set the number of queues, feature bits, etc via the
   vhost-user socket.  It is not necessary to manually specify feature
   bitmasks and other slave-specific information on the QEMU
   command-line.

I haven't thought through disconnection but I imagine the vhost-user
object would emit a VHOST_USER_DISCONNECTED event so the management
software can hot unplug the device.

Thoughts?

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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