From patchwork Tue Mar 15 18:34:54 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Markus Armbruster X-Patchwork-Id: 8591761 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id C456EC0553 for ; Tue, 15 Mar 2016 18:51:28 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 1F562202E6 for ; Tue, 15 Mar 2016 18:51:28 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 529DB202AE for ; Tue, 15 Mar 2016 18:51:27 +0000 (UTC) Received: from localhost ([::1]:50759 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afu3y-0005hR-PL for patchwork-qemu-devel@patchwork.kernel.org; Tue, 15 Mar 2016 14:51:26 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43935) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aftoF-0006r9-Ck for qemu-devel@nongnu.org; Tue, 15 Mar 2016 14:35:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aftoC-0001yA-Gk for qemu-devel@nongnu.org; Tue, 15 Mar 2016 14:35:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aftoC-0001xS-6R for qemu-devel@nongnu.org; Tue, 15 Mar 2016 14:35:08 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id C61F5C00DE04; Tue, 15 Mar 2016 18:35:07 +0000 (UTC) Received: from blackfin.pond.sub.org (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2FIZ5gM007908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Mar 2016 14:35:06 -0400 Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 09E4A3006AEC; Tue, 15 Mar 2016 19:34:57 +0100 (CET) From: Markus Armbruster To: qemu-devel@nongnu.org Date: Tue, 15 Mar 2016 19:34:54 +0100 Message-Id: <1458066895-20632-40-git-send-email-armbru@redhat.com> In-Reply-To: <1458066895-20632-1-git-send-email-armbru@redhat.com> References: <1458066895-20632-1-git-send-email-armbru@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: claudio.fontana@huawei.com, cam@cs.ualberta.ca, mlureau@redhat.com, david.marchand@6wind.com, pbonzini@redhat.com Subject: [Qemu-devel] [PATCH v3 39/40] ivshmem: Require master to have ID zero X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 Reviewed-by: Marc-André Lureau --- 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 f3912c0..a1f5499 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 90930f2..18f6802 100644 --- a/hw/misc/ivshmem.c +++ b/hw/misc/ivshmem.c @@ -874,6 +874,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 using POSIX shm, you may specify