On Mon, Feb 29, 2016 at 7:40 PM, Markus Armbruster <arm...@redhat.com> wrote:
> 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 <arm...@redhat.com>
> ---
Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com>
> docs/specs/ivshmem-spec.txt | 2 ++
> hw/misc/ivshmem.c | 6 ++++++
> qemu-doc.texi | 5 +++++
> 3 files changed, 13 insertions(+)
>
> diff --git a/docs/specs/ivshmem-spec.txt b/docs/specs/ivshmem-spec.txt
> index 047dfc0..b062acd 100644
> --- a/docs/specs/ivshmem-spec.txt
> +++ b/docs/specs/ivshmem-spec.txt
> @@ -164,6 +164,8 @@ For each new client that connects to the server, the
> server
> - sends interrupt setup messages to the new client (these contain file
> descriptors for receiving interrupts).
>
> +The first client to connect to the server receives ID zero.
> +
> When a client disconnects from the server, the server sends disconnect
> notifications to the other clients.
>
> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
> index f6fce15..9a292e5 100644
> --- a/hw/misc/ivshmem.c
> +++ b/hw/misc/ivshmem.c
> @@ -869,6 +869,12 @@ static void ivshmem_common_realize(PCIDevice *dev, Error
> **errp)
> return;
> }
>
> + if (s->master == ON_OFF_AUTO_ON && s->vm_id != 0) {
> + error_setg(errp,
> + "master must connect to the server before any peers");
> + return;
> + }
> +
> qemu_chr_add_handlers(s->server_chr, ivshmem_can_receive,
> ivshmem_read, NULL, s);
>
> diff --git a/qemu-doc.texi b/qemu-doc.texi
> index 0dd01c7..79141d3 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
> --
> 2.4.3
>
>
--
Marc-André Lureau
