qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org, mukawa@igel.co.jp,
	marcandre.lureau@redhat.com, Wei Wang <wei.w.wang@intel.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	n.nikolaev@virtualopensystems.com
Subject: Re: [Qemu-devel] vhost-user graceful connect/disconnect
Date: Fri, 5 Jan 2018 16:14:53 +0000	[thread overview]
Message-ID: <20180105161453.GI28322@stefanha-x1.localdomain> (raw)
In-Reply-To: <20180104184236-mutt-send-email-mst@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 2733 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

      reply	other threads:[~2018-01-05 16:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-19 16:21 [Qemu-devel] vhost-user graceful connect/disconnect Stefan Hajnoczi
2017-12-20  6:45 ` Fam Zheng
2017-12-20 15:56   ` Stefan Hajnoczi
2017-12-21 11:01 ` Marc-André Lureau
2018-01-04 10:47   ` Stefan Hajnoczi
2018-01-04 11:15     ` Wei Wang
2018-01-05 15:49       ` Stefan Hajnoczi
2018-01-08 11:22         ` Wei Wang
2018-01-08 16:09           ` Stefan Hajnoczi
2018-01-12  6:53             ` Wei Wang
2018-01-12 10:45               ` Stefan Hajnoczi
2018-01-04 16:53 ` Michael S. Tsirkin
2018-01-05 16:14   ` Stefan Hajnoczi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180105161453.GI28322@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mst@redhat.com \
    --cc=mukawa@igel.co.jp \
    --cc=n.nikolaev@virtualopensystems.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wei.w.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).