From: Wei Yang <richardw.yang@linux.intel.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: peter.maydell@linaro.org, mst@redhat.com, qemu-devel@nongnu.org,
Wei Yang <richard.weiyang@gmail.com>,
shannon.zhaosl@gmail.com, qemu-arm@nongnu.org,
Wei Yang <richardw.yang@linux.intel.com>
Subject: Re: [Qemu-arm] [Qemu-devel] [RFC PATCH 3/3] hw/acpi: Extract build_mcfg
Date: Tue, 2 Apr 2019 11:53:43 +0800 [thread overview]
Message-ID: <20190402035343.GA6527@richard> (raw)
In-Reply-To: <20190313170943.5384f5cf@redhat.com>
On Wed, Mar 13, 2019 at 05:09:43PM +0100, Igor Mammedov wrote:
>On Wed, 13 Mar 2019 13:33:59 +0000
>Wei Yang <richard.weiyang@gmail.com> wrote:
>
>>
>> I am lost at this place.
>>
>> sig is a part of ACPI table header, you mean the sig is not necessary to
>> be set in ACPI table header?
>>
>> "skip table generation" means remove build_header() in build_mcfg()?
>I mean do not call build_mcfg() at all when you don't have to.
>
>And when you need to keep table_blob the same size (for old machines)
>using acpi_data_push() to reserve space instead of build_mcfg(sig="QEMU")
>might just work as well. it's still hack but it can live in x86 specific
>acpi_build() keeping build_mcfg() generic.
>
>As for defining what to use as criteria to decide when we need to keep
>table_blob size the same, I don't remember history of it, so I'd suggest
>to look at commit a1666142, study history of acpi_ram_update() and
>legacy_acpi_table_size to figure out since which machine type one doesn't
>have to keep table_blob size the same.
>
Hi, Igor
It took me sometime to go through the migration infrastructure.
Before continuing, I'd like to talk about what I understand to make sure my
direction is correct.
ACPI has a structure named AcpiBuildState, which contains all related
information. During migration, those data in AcpiBuildState should be
transferred to destination, e.g. table_mr, rsdp_mr and link_mr.
In the case related to mcfg, the problem lies in table_mr. And the reason
breaking migration is the size of table_mr is different between source and
destination.(This reason is a guess from those change logs and mails.)
The migration infrastructure has several SaveStateEntry to help migrate
different elements. The one with name "ram" take charge of RAMBlock. So this
SaveStateEntry and its ops is the next step for me to investigate. And from
this to see the effect of different size MemoryRegion during migration.
Is this sounds correct?
--
Wei Yang
Help you, Help me
WARNING: multiple messages have this Message-ID (diff)
From: Wei Yang <richardw.yang@linux.intel.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Wei Yang <richard.weiyang@gmail.com>,
Wei Yang <richardw.yang@linux.intel.com>,
peter.maydell@linaro.org, mst@redhat.com, qemu-devel@nongnu.org,
shannon.zhaosl@gmail.com, qemu-arm@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH 3/3] hw/acpi: Extract build_mcfg
Date: Tue, 2 Apr 2019 11:53:43 +0800 [thread overview]
Message-ID: <20190402035343.GA6527@richard> (raw)
In-Reply-To: <20190313170943.5384f5cf@redhat.com>
On Wed, Mar 13, 2019 at 05:09:43PM +0100, Igor Mammedov wrote:
>On Wed, 13 Mar 2019 13:33:59 +0000
>Wei Yang <richard.weiyang@gmail.com> wrote:
>
>>
>> I am lost at this place.
>>
>> sig is a part of ACPI table header, you mean the sig is not necessary to
>> be set in ACPI table header?
>>
>> "skip table generation" means remove build_header() in build_mcfg()?
>I mean do not call build_mcfg() at all when you don't have to.
>
>And when you need to keep table_blob the same size (for old machines)
>using acpi_data_push() to reserve space instead of build_mcfg(sig="QEMU")
>might just work as well. it's still hack but it can live in x86 specific
>acpi_build() keeping build_mcfg() generic.
>
>As for defining what to use as criteria to decide when we need to keep
>table_blob size the same, I don't remember history of it, so I'd suggest
>to look at commit a1666142, study history of acpi_ram_update() and
>legacy_acpi_table_size to figure out since which machine type one doesn't
>have to keep table_blob size the same.
>
Hi, Igor
It took me sometime to go through the migration infrastructure.
Before continuing, I'd like to talk about what I understand to make sure my
direction is correct.
ACPI has a structure named AcpiBuildState, which contains all related
information. During migration, those data in AcpiBuildState should be
transferred to destination, e.g. table_mr, rsdp_mr and link_mr.
In the case related to mcfg, the problem lies in table_mr. And the reason
breaking migration is the size of table_mr is different between source and
destination.(This reason is a guess from those change logs and mails.)
The migration infrastructure has several SaveStateEntry to help migrate
different elements. The one with name "ram" take charge of RAMBlock. So this
SaveStateEntry and its ops is the next step for me to investigate. And from
this to see the effect of different size MemoryRegion during migration.
Is this sounds correct?
--
Wei Yang
Help you, Help me
next prev parent reply other threads:[~2019-04-02 3:55 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-13 4:42 [Qemu-devel] [RFC PATCH 0/3] Extract build_mcfg Wei Yang
2019-03-13 4:42 ` [Qemu-devel] [RFC PATCH 1/3] hw/arm/virt-acpi-build: use acpi_get_mcfg() to calculate bus number Wei Yang
2019-03-13 12:00 ` [Qemu-arm] " Igor Mammedov
2019-03-13 13:26 ` [Qemu-devel] " Wei Yang
2019-03-13 4:42 ` [Qemu-arm] [RFC PATCH 2/3] hw/arm/virt-acpi-build: remove unnecessary variable mcfg_start Wei Yang
2019-03-13 12:06 ` Igor Mammedov
2019-03-13 4:42 ` [Qemu-devel] [RFC PATCH 3/3] hw/acpi: Extract build_mcfg Wei Yang
2019-03-13 12:23 ` [Qemu-arm] " Igor Mammedov
2019-03-13 13:33 ` [Qemu-devel] " Wei Yang
2019-03-13 16:09 ` [Qemu-arm] " Igor Mammedov
2019-03-13 21:31 ` Wei Yang
2019-03-14 9:18 ` Igor Mammedov
2019-03-14 11:54 ` [Qemu-arm] " Wei Yang
2019-03-16 10:31 ` Wei Yang
2019-03-20 13:40 ` Wei Yang
2019-04-02 3:53 ` Wei Yang [this message]
2019-04-02 3:53 ` Wei Yang
2019-04-02 6:15 ` [Qemu-arm] " Igor Mammedov
2019-04-02 6:15 ` Igor Mammedov
2019-04-05 8:55 ` [Qemu-arm] " Wei Yang
2019-04-05 8:55 ` Wei Yang
2019-04-05 8:55 ` Wei Yang
2019-04-09 14:54 ` [Qemu-arm] " Igor Mammedov
2019-04-09 14:54 ` Igor Mammedov
2019-04-12 5:44 ` [Qemu-arm] " Wei Yang
2019-04-12 5:44 ` Wei Yang
2019-04-12 5:44 ` Wei Yang
2019-04-12 8:14 ` [Qemu-arm] " Igor Mammedov
2019-04-12 8:14 ` Igor Mammedov
2019-03-13 12:30 ` [Qemu-arm] [Qemu-devel] [RFC PATCH 0/3] " Igor Mammedov
2019-03-13 13:24 ` Wei Yang
2019-03-13 16:17 ` [Qemu-arm] " Igor Mammedov
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=20190402035343.GA6527@richard \
--to=richardw.yang@linux.intel.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.weiyang@gmail.com \
--cc=shannon.zhaosl@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.