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=-8.4 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT 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 52658C10F0E for ; Mon, 8 Apr 2019 03:33:00 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1DD5A20879 for ; Mon, 8 Apr 2019 03:33:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1DD5A20879 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 ([127.0.0.1]:46675 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDL1n-0007mE-D3 for qemu-devel@archiver.kernel.org; Sun, 07 Apr 2019 23:32:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47353) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDL0s-0007Tb-DM for qemu-devel@nongnu.org; Sun, 07 Apr 2019 23:32:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hDL0r-0003YD-7j for qemu-devel@nongnu.org; Sun, 07 Apr 2019 23:32:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60704) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hDL0p-0003X5-2o for qemu-devel@nongnu.org; Sun, 07 Apr 2019 23:32:01 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D173B30832E3; Mon, 8 Apr 2019 03:31:57 +0000 (UTC) Received: from xz-x1 (dhcp-14-116.nay.redhat.com [10.66.14.116]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 33B345C28D; Mon, 8 Apr 2019 03:31:54 +0000 (UTC) Date: Mon, 8 Apr 2019 11:31:52 +0800 From: Peter Xu To: Catherine Ho Message-ID: <20190408033152.GF23212@xz-x1> References: <1554688616-18583-1-git-send-email-catherine.hecx@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <1554688616-18583-1-git-send-email-catherine.hecx@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Mon, 08 Apr 2019 03:31:57 +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: Re: [Qemu-devel] [PATCH v3] migration: do not rom_reset() during incoming migration X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juan Quintela , Markus Armbruster , qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , Paolo Bonzini , Richard Henderson Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Message-ID: <20190408033152.QO-Mo_31miXONEqXwTfMdxTSMiKg3jDTaOiMAd5s5YI@z> On Sun, Apr 07, 2019 at 09:56:56PM -0400, Catherine Ho wrote: > 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 > --- > hw/core/loader.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/hw/core/loader.c b/hw/core/loader.c > index fe5cb24122..946bb8ff00 100644 > --- a/hw/core/loader.c > +++ b/hw/core/loader.c > @@ -1087,6 +1087,13 @@ static void rom_reset(void *unused) > { > Rom *rom; > > + /* > + * 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. I'm unconfident about correcting English in patches, but it does look a bit odd to me... I would say: 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; The change looks good to me but of course it'll be nicer if some other people can review it. > + > QTAILQ_FOREACH(rom, &roms, next) { > if (rom->fw_file) { > continue; > -- > 2.17.1 > Regards, -- Peter Xu