From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7F02C3A589 for ; Tue, 20 Aug 2019 07:21:23 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6B5F6216F4 for ; Tue, 20 Aug 2019 07:21:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6B5F6216F4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:34002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hzySI-0005Ga-2D for qemu-devel@archiver.kernel.org; Tue, 20 Aug 2019 03:21:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42878) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hzy8y-0005yv-Oi for qemu-devel@nongnu.org; Tue, 20 Aug 2019 03:01:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hzy8x-0003pH-G2 for qemu-devel@nongnu.org; Tue, 20 Aug 2019 03:01:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39514) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hzy8u-0003gG-FN for qemu-devel@nongnu.org; Tue, 20 Aug 2019 03:01:20 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2D682315C024; Tue, 20 Aug 2019 07:01:14 +0000 (UTC) Received: from 640k.localdomain.com (ovpn-112-20.ams2.redhat.com [10.36.112.20]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2A58860BE2; Tue, 20 Aug 2019 07:01:12 +0000 (UTC) From: Paolo Bonzini To: qemu-devel@nongnu.org Date: Tue, 20 Aug 2019 08:59:52 +0200 Message-Id: <1566284395-30287-34-git-send-email-pbonzini@redhat.com> In-Reply-To: <1566284395-30287-1-git-send-email-pbonzini@redhat.com> References: <1566284395-30287-1-git-send-email-pbonzini@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Tue, 20 Aug 2019 07:01:14 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 33/36] migration: do not rom_reset() during incoming migration X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catherine Ho Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" From: Catherine Ho Commit 18269069c310 ("migration: Introduce ignore-shared capability") addes ignore-shared capability to bypass the shared ramblock (e,g, membackend + numa node). It does good to live migration. As told by Yury,this commit expectes that QEMU doesn't write to guest RAM until VM starts, but it does on aarch64 qemu: Backtrace: 1 0x000055f4a296dd84 in address_space_write_rom_internal () at exec.c:3458 2 0x000055f4a296de3a in address_space_write_rom () at exec.c:3479 3 0x000055f4a2d519ff in rom_reset () at hw/core/loader.c:1101 4 0x000055f4a2d475ec in qemu_devices_reset () at hw/core/reset.c:69 5 0x000055f4a2c90a28 in qemu_system_reset () at vl.c:1675 6 0x000055f4a2c9851d in main () at vl.c:4552 Actually, on arm64 virt marchine, ramblock "dtb" will be filled into ram druing rom_reset. In ignore-shared incoming case, this rom filling is not required since all the data has been stored in memory backend file. Further more, as suggested by Peter Xu, if we do rom_reset() now with these ROMs then the RAM data should be re-filled again too with the migration stream coming in. Fixes: commit 18269069c310 ("migration: Introduce ignore-shared capability") Suggested-by: Yury Kotov Suggested-by: Peter Xu Signed-off-by: Catherine Ho Acked-by: Peter Xu Signed-off-by: Paolo Bonzini --- hw/core/loader.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/hw/core/loader.c b/hw/core/loader.c index 9fb93a6..baa4448 100644 --- a/hw/core/loader.c +++ b/hw/core/loader.c @@ -1112,6 +1112,15 @@ static void rom_reset(void *unused) { Rom *rom; + /* + * We don't need to fill in the RAM with ROM data because we'll fill + * the data in during the next incoming migration in all cases. Note + * that some of those RAMs can actually be modified by the guest on ARM + * so this is probably the only right thing to do here. + */ + if (runstate_check(RUN_STATE_INMIGRATE)) + return; + QTAILQ_FOREACH(rom, &roms, next) { if (rom->fw_file) { continue; -- 1.8.3.1