From: Juan Quintela <quintela@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: Bernhard Beschow <shentey@gmail.com>,
qemu-devel@nongnu.org, Thomas Huth <thuth@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
Eduardo Habkost <eduardo@habkost.net>,
qemu-trivial@nongnu.org, BALATON Zoltan <balaton@eik.bme.hu>,
Laurent Vivier <lvivier@redhat.com>,
Sunil Muthuswamy <sunilmut@microsoft.com>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
Ani Sinha <ani@anisinha.ca>,
"Dr. David Alan Gilbert (git)" <dgilbert@redhat.com>
Subject: Re: [PATCH v3 8/9] hw/i386/x86: Make TYPE_X86_MACHINE the owner of smram
Date: Mon, 06 Feb 2023 11:06:40 +0100 [thread overview]
Message-ID: <87h6vzcdlb.fsf@secure.mitica> (raw)
In-Reply-To: <10bf125e-85a4-72cc-07de-0d6206941f62@linaro.org> ("Philippe Mathieu-Daudé"'s message of "Sun, 5 Feb 2023 12:21:45 +0100")
Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> On 4/2/23 16:10, Bernhard Beschow wrote:
>> Treat the smram MemoryRegion analoguous to other memory regions such as
>> 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, right?
> 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.
Later, Juan.
next prev parent reply other threads:[~2023-02-06 10:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-04 15:10 [PATCH v3 0/9] PC cleanups Bernhard Beschow
2023-02-04 15:10 ` [PATCH v3 1/9] hw/pci-host/i440fx: Inline sysbus_add_io() Bernhard Beschow
2023-02-05 11:05 ` Philippe Mathieu-Daudé
2023-02-04 15:10 ` [PATCH v3 2/9] hw/pci-host/q35: " Bernhard Beschow
2023-02-05 11:12 ` Philippe Mathieu-Daudé
2023-02-06 0:15 ` Bernhard Beschow
2023-02-04 15:10 ` [PATCH v3 3/9] hw/i386/pc_q35: Reuse machine parameter Bernhard Beschow
2023-02-05 11:13 ` Philippe Mathieu-Daudé
2023-02-04 15:10 ` [PATCH v3 4/9] hw/i386/pc_{q35, piix}: Reuse MachineClass::desc as SMB product name Bernhard Beschow
2023-02-04 15:10 ` [PATCH v3 5/9] hw/i386/pc_{q35, piix}: Minimize usage of get_system_memory() Bernhard Beschow
2023-02-05 11:13 ` Philippe Mathieu-Daudé
2023-02-04 15:10 ` [PATCH v3 6/9] hw/i386/pc: Initialize ram_memory variable directly Bernhard Beschow
2023-02-04 15:26 ` BALATON Zoltan
2023-02-06 0:07 ` Bernhard Beschow
2023-02-04 15:10 ` [PATCH v3 7/9] hw/pci-host/pam: Make init_pam() usage more readable Bernhard Beschow
2023-02-05 11:16 ` Philippe Mathieu-Daudé
2023-02-04 15:10 ` [PATCH v3 8/9] hw/i386/x86: Make TYPE_X86_MACHINE the owner of smram Bernhard Beschow
2023-02-05 11:21 ` Philippe Mathieu-Daudé
2023-02-06 10:06 ` Juan Quintela [this message]
2023-02-07 15:17 ` Bernhard Beschow
2023-02-07 18:34 ` Juan Quintela
2023-02-07 22:43 ` Bernhard Beschow
2023-02-04 15:10 ` [PATCH v3 9/9] target/i386/tcg/sysemu/tcg-cpu: Avoid own opinion about smram size Bernhard Beschow
2023-02-05 11:26 ` Philippe Mathieu-Daudé
2023-02-07 22:46 ` Bernhard Beschow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6vzcdlb.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=ani@anisinha.ca \
--cc=balaton@eik.bme.hu \
--cc=dgilbert@redhat.com \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=shentey@gmail.com \
--cc=sunilmut@microsoft.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).