From patchwork Tue Sep 29 12:06:43 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kurz X-Patchwork-Id: 524076 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 59982140778 for ; Wed, 30 Sep 2015 10:21:08 +1000 (AEST) Received: from localhost ([::1]:55890 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zh58s-0005Fb-Bk for incoming@patchwork.ozlabs.org; Tue, 29 Sep 2015 20:21:06 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgtgM-00021n-UF for qemu-devel@nongnu.org; Tue, 29 Sep 2015 08:06:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgtgI-0007oB-SD for qemu-devel@nongnu.org; Tue, 29 Sep 2015 08:06:54 -0400 Received: from e06smtp14.uk.ibm.com ([195.75.94.110]:57772) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgtgI-0007nx-Hy for qemu-devel@nongnu.org; Tue, 29 Sep 2015 08:06:50 -0400 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 29 Sep 2015 13:06:47 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 29 Sep 2015 13:06:46 +0100 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: gkurz@linux.vnet.ibm.com X-IBM-RcptTo: qemu-devel@nongnu.org Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 3ACE01B08072 for ; Tue, 29 Sep 2015 13:08:32 +0100 (BST) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t8TC6jrq26869930 for ; Tue, 29 Sep 2015 12:06:45 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t8TC6i0u017824 for ; Tue, 29 Sep 2015 06:06:44 -0600 Received: from smtp.lab.toulouse-stg.fr.ibm.com (srv01.lab.toulouse-stg.fr.ibm.com [9.101.4.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t8TC6ivd017812; Tue, 29 Sep 2015 06:06:44 -0600 Received: from bahia.huguette.org (icon-9-164-178-159.megacenter.de.ibm.com [9.164.178.159]) by smtp.lab.toulouse-stg.fr.ibm.com (Postfix) with ESMTP id C3D7E220227; Tue, 29 Sep 2015 14:06:43 +0200 (CEST) From: Greg Kurz To: aneesh.kumar@linux.vnet.ibm.com Date: Tue, 29 Sep 2015 14:06:43 +0200 Message-ID: <20150929120001.14795.67055.stgit@bahia.huguette.org> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15092912-0017-0000-0000-000005A20695 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 195.75.94.110 Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" Subject: [Qemu-devel] [PATCH v2] virtio-9p: migrate virtio subsections 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+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org In a cross-endian setup, the virtio-9p device has state in @device_endian. It must be migrated. This patch just adds the minimal support to live migrate generic virtio subsections where @device_endian is handled. Please note that this is unrelated to the fact that we block migration when the 9p share is mounted in the guest. It fixes the case where we want to migrate an unactive 9p device (not mounted in the guest) to a QEMU with different endianness: the migration currently succeeds but leaves the device in an inconsistent state that causes mount to hang until we reboot the guest. Signed-off-by: Greg Kurz --- v2: more detailed change log --- hw/9pfs/virtio-9p-device.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c index 93a407c45926..e3abcfaffb2a 100644 --- a/hw/9pfs/virtio-9p-device.c +++ b/hw/9pfs/virtio-9p-device.c @@ -43,6 +43,16 @@ static void virtio_9p_get_config(VirtIODevice *vdev, uint8_t *config) g_free(cfg); } +static void virtio_9p_save(QEMUFile *f, void *opaque) +{ + virtio_save(VIRTIO_DEVICE(opaque), f); +} + +static int virtio_9p_load(QEMUFile *f, void *opaque, int version_id) +{ + return virtio_load(VIRTIO_DEVICE(opaque), f, version_id); +} + static void virtio_9p_device_realize(DeviceState *dev, Error **errp) { VirtIODevice *vdev = VIRTIO_DEVICE(dev); @@ -130,6 +140,7 @@ static void virtio_9p_device_realize(DeviceState *dev, Error **errp) } v9fs_path_free(&path); + register_savevm(dev, "virtio-9p", -1, 1, virtio_9p_save, virtio_9p_load, s); return; out: g_free(s->ctx.fs_root);