diff options
| author | Markus Armbruster <armbru@redhat.com> | 2016-03-15 19:34:54 +0100 |
|---|---|---|
| committer | Markus Armbruster <armbru@redhat.com> | 2016-03-21 21:29:03 +0100 |
| commit | 62a830b688a93419baa89061b6b5faf8b5e10808 (patch) | |
| tree | 546264772d3bb4ca39b61aa14f13eac1d44eb016 /qemu-doc.texi | |
| parent | 13fd2cb68953ac066116d444415f9d5ec7ce1200 (diff) | |
ivshmem: Require master to have ID zero
Migration with ivshmem needs to be carefully orchestrated to work.
Exactly one peer (the "master") migrates to the destination, all other
peers need to unplug (and disconnect), migrate, plug back (and
reconnect). This is sort of documented in qemu-doc.
If peers connect on the destination before migration completes, the
shared memory can get messed up. This isn't documented anywhere. Fix
that in qemu-doc.
To avoid messing up register IVPosition on migration, the server must
assign the same ID on source and destination. ivshmem-spec.txt leaves
ID assignment unspecified, however.
Amend ivshmem-spec.txt to require the first client to receive ID zero.
The example ivshmem-server complies: it always assigns the first
unused ID.
For a bit of additional safety, enforce ID zero for the master. This
does nothing when we're not using a server, because the ID is zero for
all peers then.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-40-git-send-email-armbru@redhat.com>
Diffstat (limited to 'qemu-doc.texi')
| -rw-r--r-- | qemu-doc.texi | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/qemu-doc.texi b/qemu-doc.texi index 0dd01c78fd..79141d3582 100644 --- a/qemu-doc.texi +++ b/qemu-doc.texi @@ -1295,12 +1295,17 @@ When using the server, the guest will be assigned a VM ID (>=0) that allows gues using the same server to communicate via interrupts. Guests can read their VM ID from a device register (see ivshmem-spec.txt). +@subsubsection Migration with ivshmem + With device property @option{master=on}, the guest will copy the shared memory on migration to the destination host. With @option{master=off}, the guest will not be able to migrate with the device attached. In the latter case, the device should be detached and then reattached after migration using the PCI hotplug support. +At most one of the devices sharing the same memory can be master. The +master must complete migration before you plug back the other devices. + @subsubsection ivshmem and hugepages Instead of specifying the <shm size> using POSIX shm, you may specify |