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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 5D284C636CD for ; Tue, 7 Feb 2023 15:18:51 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pPPjp-0001ZE-CB; Tue, 07 Feb 2023 10:18:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pPPjb-0001RV-9U; Tue, 07 Feb 2023 10:18:20 -0500 Received: from mail-vs1-xe2d.google.com ([2607:f8b0:4864:20::e2d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pPPjY-0001D2-R8; Tue, 07 Feb 2023 10:18:14 -0500 Received: by mail-vs1-xe2d.google.com with SMTP id a24so16620551vsl.2; Tue, 07 Feb 2023 07:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qCIrFd39avKPlw2r7zce1/kGjlqMZFpM3Z8F2/TZNQY=; b=O3BmJAjEdHJhOmthIESdyVA91Me6EL5MobwLjydUPQY+cH30T6U8RYsJTL8lSlzkIK 9FkZIVjOLgeGxpi0yrBDvnYNZXSBgkbKdrrXZZ8TtEbe7oP2H6I5ROjT7lHa9juwWHdv EmDrtC0oEQ+Y7VKT7gtKNAVh9CgqGy6MeF/aHFDecKXyMPuqQMrGLvf/UUmkKo7WvI28 BTSSNw2uCKBaL4iVxJqzAeG2hHMTwHxeFKyy+p3FvAtyzbL4Yu7BEMbMs2xxIQTHU64B iJk6Wh51tnVLEgGa3icEzBrEqq6a2PqyRhh267nsA87B5Vn5btz3FCzanbnR6BsNRTtL HfcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qCIrFd39avKPlw2r7zce1/kGjlqMZFpM3Z8F2/TZNQY=; b=dGRi2f7McG35Dc/cn1hEfF2HM5RftnnkWbSwUidrektXEM5MAVFcL9mK1MIPYxee8h U1XZNaQQIOGGLwty5A+Mg/3gqfOV3pwiE6xRxZhOGeRfn7aUHUN9e6Y6aYj4Ys3yhj4f zmHW1bzvoOTVh6bvzzsDeZtKO6p83yC3kryAjh2TYXvovxcw8DniaevglrcU5TRjtC3O B2+l5WkemjUa/7LRbdkBvpjYYI461SeYZA0LCTS5zatm8IeMkO9v8RTp0KkCA2uHJN0+ ck8maK18Dan+lPhH0mTrIeS3V8Elu/2yasZ7T1MblaZDTShJ289a8bDnZEup/ujr1EYU SyDw== X-Gm-Message-State: AO0yUKUCl9j2zQCCBj1JpPl2KE4LUe4Hp9IKheSKrOYHPlHCz5NOMJi9 tQu32/+tL/Zi6fBuQALjRGLuxVQGA3GVATrOzTU= X-Google-Smtp-Source: AK7set8BBRXpFmebvZDVXzPezqhM5NvmV9x+unxeM04qdHVtEglrpmEPsgEUhr2jNTJzA32CtBJGNE6SS9kB5riHLtw= X-Received: by 2002:a05:6102:837:b0:411:ac71:dde0 with SMTP id k23-20020a056102083700b00411ac71dde0mr55064vsb.38.1675783090046; Tue, 07 Feb 2023 07:18:10 -0800 (PST) MIME-Version: 1.0 References: <20230204151027.39007-1-shentey@gmail.com> <20230204151027.39007-9-shentey@gmail.com> <10bf125e-85a4-72cc-07de-0d6206941f62@linaro.org> <87h6vzcdlb.fsf@secure.mitica> In-Reply-To: <87h6vzcdlb.fsf@secure.mitica> From: Bernhard Beschow Date: Tue, 7 Feb 2023 16:17:56 +0100 Message-ID: Subject: Re: [PATCH v3 8/9] hw/i386/x86: Make TYPE_X86_MACHINE the owner of smram To: quintela@redhat.com Cc: =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , qemu-devel@nongnu.org, Thomas Huth , Richard Henderson , Eduardo Habkost , qemu-trivial@nongnu.org, BALATON Zoltan , Laurent Vivier , Sunil Muthuswamy , Marcel Apfelbaum , Paolo Bonzini , "Michael S. Tsirkin" , Igor Mammedov , Ani Sinha , "Dr. David Alan Gilbert (git)" Content-Type: multipart/alternative; boundary="000000000000cd8bd605f41da7a5" Received-SPF: pass client-ip=2607:f8b0:4864:20::e2d; envelope-from=shentey@gmail.com; helo=mail-vs1-xe2d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org --000000000000cd8bd605f41da7a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 6, 2023 at 11:06 AM Juan Quintela wrote: > Philippe Mathieu-Daud=C3=A9 wrote: > > On 4/2/23 16:10, Bernhard Beschow wrote: > >> Treat the smram MemoryRegion analoguous to other memory regions such a= s > >> ram, pci, io, ... , making the used memory regions more explicit when > >> instantiating q35 or i440fx. > >> Note that the q35 device uses these memory regions only during the > >> realize phase which suggests that it shouldn't be the owner of smram. > > > > Few years ago I tried something similar and it wasn't accepted because > > the MR owner name is used in the migration stream, so this was breaking > > migrating from older machines. > > I don't remember the details O:-) > > Migration code, really depends on RAMBlocks names, not memory region > names. But as far as I remember, that don't matter too much because the > memory region names ends tangled quite a bit with the RAMBlock name, righ= t? > > > Adding David/Juan for double-checking that. > > trace_vmstate_save(se->idstr, se->vmsd ? se->vmsd->name : "(old)"); > > You can try to enable this trace and see that every section has the same > name with and without your change (i.e. that memory region name is not > seen by the migration stream). > > But that is the only help that I can came with. > > The code that you are changing (smram) is something that I don't know > about to give you more help. > > Looking at the patch, it looks that the name was before and now the > "sram", so perhaps it could help. But I don't know. > > In the i440fx you say that you only use it until realize, so you should > be safe. > > For q35, it is not clear to me. > > If the trace don't show new names, I will just try: > - migrate a i440fx machine from binary without your patch to one with > your patch > - the same for q35. > > And depending on the result, we can go from there. > Thanks for the pointers, Juan! I took some inspiration and created four migration files, {pc,q35}-{before,after}.mig by running `qemu-system-x86_64 -M {pc,q35} -S` with qemu built from master and from my branch. Then I basically ran `./scripts/analyze-migration.py -d desc -f *.mig > *.json` on the four files and compared the diffs. Both diffs were empty. AFAIU this proves that there is no binary change, right? Best regards, Bernhard > > > Later, Juan. > > --000000000000cd8bd605f41da7a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Feb 6, 2023 at 11:06 AM Juan = Quintela <quintela@redhat.com= > wrote:
Phil= ippe Mathieu-Daud=C3=A9 <philmd@linaro.org> wrote:
> On 4/2/23 16:10, Bernhard Beschow wrote:
>> Treat the smram MemoryRegion analoguous to other memory regions su= ch as
>> ram, pci, io, ... , making the used memory regions more explicit w= hen
>> instantiating q35 or i440fx.
>> Note that the q35 device uses these memory regions only during the=
>> realize phase which suggests that it shouldn't be the owner of= smram.
>
> Few years ago I tried something similar and it wasn't accepted bec= ause
> the MR owner name is used in the migration stream, so this was breakin= g
> migrating from older machines.

I don't remember the details O:-)

Migration code, really depends on RAMBlocks names, not memory region
names.=C2=A0 But as far as I remember, that don't matter too much becau= se the
memory region names ends tangled quite a bit with the RAMBlock name, right?=

> Adding David/Juan for double-checking that.

=C2=A0 =C2=A0 trace_vmstate_save(se->idstr, se->vmsd ? se->vmsd-&g= t;name : "(old)");

You can try to enable this trace and see that every section has the same name with and without your change (i.e. that memory region name is not
seen by the migration stream).

But that is the only help that I can came with.

The code that you are changing (smram) is something that I don't know about to give you more help.

Looking at the patch, it looks that the name was before and now the
"sram", so perhaps it could help.=C2=A0 But I don't know.

In the i440fx you say that you only use it until realize, so you should
be safe.

For q35, it is not clear to me.

If the trace don't show new names, I will just try:
- migrate a i440fx machine from binary without your patch to one with
=C2=A0 your patch
- the same for q35.

And depending on the result, we can go from there.
Thanks for the pointers, Juan!

I took some = inspiration and created four migration files, {pc,q35}-{before,after}.mig b= y running `qemu-system-x86_64 -M {pc,q35} -S` with qemu built from master a= nd from my branch. Then I basically ran =C2=A0`./scripts/analyze-migration.= py -d desc -f *.mig > *.json` on the four files and compared the diffs. = Both diffs were empty. AFAIU this proves that there is no binary change, ri= ght?

Best regards,
Bernhard

Later, Juan.

--000000000000cd8bd605f41da7a5--