From patchwork Sat Aug 23 10:19:07 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laszlo Ersek X-Patchwork-Id: 382415 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 60F4E1400B2 for ; Sat, 23 Aug 2014 20:20:03 +1000 (EST) Received: from localhost ([::1]:40577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XL8QT-00005b-BU for incoming@patchwork.ozlabs.org; Sat, 23 Aug 2014 06:20:01 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XL8Pv-0007cW-Ap for qemu-devel@nongnu.org; Sat, 23 Aug 2014 06:19:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XL8Pp-0001H9-4s for qemu-devel@nongnu.org; Sat, 23 Aug 2014 06:19:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14629) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XL8Po-0001H5-Sz for qemu-devel@nongnu.org; Sat, 23 Aug 2014 06:19:21 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7NAJKu0020924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 23 Aug 2014 06:19:20 -0400 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-22.ams2.redhat.com [10.36.116.22]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7NAJ9Sw030085; Sat, 23 Aug 2014 06:19:17 -0400 From: Laszlo Ersek To: Michal Privoznik , Eric Blake , "Daniel P. Berrange" , Paolo Bonzini , Kevin Wolf , Stefan Hajnoczi , Juan Quintela , David Gilbert , Laszlo Ersek , qemu devel list Date: Sat, 23 Aug 2014 12:19:07 +0200 Message-Id: <1408789147-18675-3-git-send-email-lersek@redhat.com> In-Reply-To: <1408789147-18675-1-git-send-email-lersek@redhat.com> References: <1408789147-18675-1-git-send-email-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH 2/2] pflash_cfi01: write flash contents to bdrv on incoming migration 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 A drive that backs a pflash device is special: - it is very small, - its entire contents are kept in a RAMBlock at all times, covering the guest-phys address range that provides the guest's view of the emulated flash chip. The pflash device model keeps the drive (the host-side file) and the guest-visible flash contents in sync. When migrating the guest, the guest-visible flash contents (the RAMBlock) is migrated by default, but on the target host, the drive (the host-side file) remains in full sync with the RAMBlock only if: - the source and target hosts share the storage underlying the pflash drive, - or the migration requests full or incremental block migration too, which then covers all drives. Due to the special nature of pflash drives, the following scenario makes sense as well: - no full nor incremental block migration, covering all drives, alongside the base migration (justified eg. by shared storage for "normal" (big) drives), - non-shared storage for pflash drives. In this case, currently only those portions of the flash drive are updated on the target disk that the guest reprograms while running on the target host. In order to restore accord, dump the entire flash contents to the bdrv in a post_load() callback. - The read-only check follows the other call-sites of pflash_update(); - both "pfl->ro" and pflash_update() reflect / consider the case when "pfl->bs" is NULL; - the total size of the flash device is calculated as in pflash_cfi01_realize(). When using shared storage, or requesting full or incremental block migration along with the normal migration, the patch should incur a harmless rewrite from the target side. It is assumed that, on the target host, RAM is loaded ahead of the call to pflash_post_load(). Suggested-by: Paolo Bonzini Signed-off-by: Laszlo Ersek --- hw/block/pflash_cfi01.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c index fddef39..593fbc5 100644 --- a/hw/block/pflash_cfi01.c +++ b/hw/block/pflash_cfi01.c @@ -94,10 +94,13 @@ struct pflash_t { void *storage; }; +static int pflash_post_load(void *opaque, int version_id); + static const VMStateDescription vmstate_pflash = { .name = "pflash_cfi01", .version_id = 1, .minimum_version_id = 1, + .post_load = pflash_post_load, .fields = (VMStateField[]) { VMSTATE_UINT8(wcycle, pflash_t), VMSTATE_UINT8(cmd, pflash_t), @@ -982,3 +985,14 @@ MemoryRegion *pflash_cfi01_get_memory(pflash_t *fl) { return &fl->mem; } + +static int pflash_post_load(void *opaque, int version_id) +{ + pflash_t *pfl = opaque; + + if (!pfl->ro) { + DPRINTF("%s: updating bdrv for %s\n", __func__, pfl->name); + pflash_update(pfl, 0, pfl->sector_len * pfl->nb_blocs); + } + return 0; +}