qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Vivier <lvivier@redhat.com>
To: "Dr . David Alan Gilbert" <dgilbert@redhat.com>
Cc: "Michael S . Tsirkin" <mst@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Amit Shah <amit@kernel.org>,
	qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH v2 0/2] migration: fix virtio-rng
Date: Wed, 12 Apr 2017 15:53:10 +0200	[thread overview]
Message-ID: <20170412135312.1686-1-lvivier@redhat.com> (raw)

When post-copy migration is enabled, the destination
guest can ask for memory from the source when the
vmstate is restored.

In the case of virtio, a part of the virtqueue
is migrated by the vmstate structure (last_avail_idx)
another part is migrated inside the RAM (used_idx).
On the source side, the virtqueue can be modified
whereas the vmstate is already migrated, and the destination
side can ask for the value in RAM. In this case we have
an inconsistency that can generate this kind of error:
    "VQ 0 size 0x8 < last_avail_idx 0xa - used_idx 0"
in hw/virtio/virtio.c:2180, virtio_load().

This happens with virtio-rng as the chr_read()
function which modifies the virqueue is called
by the rng backend and the rng backend continues to
run while the migration is running and the CPU is stopped.

This series fixes this problem by ignoring chr_read()
calls while the CPU is stopped. The first patch of the
series fixes another problem triggered by this error
case: a use-after-free case.

The probability to have this problem is very low, as
generally the post-copy phase is very short, so the window
to modify the virtqueue while the vmstate has been sent
is very small... except if you are doing trans-continental
guest migration with high latency and post-copy phase that
can be run for minutes.

I've been able to reproduce the problem locally on a host,
by adding network latency with "tc". Another condition is
to have an rng daemon running in the guest to generate
events in the virtio-rng device.

v2:
- add a vm state change handler to restart the virtio-rng
  process when the CPU restarts (it also replaces
  the post_load function).

Laurent Vivier (2):
  migration: don't close a file descriptor while it can be in use
  virtio-rng: stop virtqueue while the CPU is stopped

 hw/virtio/trace-events         |  3 +++
 hw/virtio/virtio-rng.c         | 29 +++++++++++++++++++++++------
 include/hw/virtio/virtio-rng.h |  2 ++
 migration/migration.c          |  6 +++---
 4 files changed, 31 insertions(+), 9 deletions(-)

-- 
2.9.3

             reply	other threads:[~2017-04-12 13:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-12 13:53 Laurent Vivier [this message]
2017-04-12 13:53 ` [Qemu-devel] [PATCH v2 1/2] migration: don't close a file descriptor while it can be in use Laurent Vivier
2017-04-20 18:48   ` Dr. David Alan Gilbert
2017-04-21  9:19   ` Juan Quintela
2017-04-12 13:53 ` [Qemu-devel] [PATCH v2 2/2] virtio-rng: stop virtqueue while the CPU is stopped Laurent Vivier
2017-04-21  9:20   ` Juan Quintela
2017-04-13 14:51 ` [Qemu-devel] [PATCH v2 0/2] migration: fix virtio-rng Stefan Hajnoczi
2017-04-17 19:33 ` Amit Shah

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=20170412135312.1686-1-lvivier@redhat.com \
    --to=lvivier@redhat.com \
    --cc=amit@kernel.org \
    --cc=dgilbert@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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).