qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "Bin Meng" <bmeng.cn@gmail.com>, "Alex Bennée" <alex.bennee@linaro.org>
Cc: Bin Meng <bin.meng@windriver.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH 3/3] tests/acpi: Update virt/SSDT.memhp
Date: Mon, 15 Jan 2024 20:07:41 +0100	[thread overview]
Message-ID: <385fc0d8-2c07-0645-09d5-4f790d5b7dfd@redhat.com> (raw)
In-Reply-To: <CAEUhbmUoyNi=3uSwiFPGdb25_a-0zwQavbni4T+8jMJJFJH01g@mail.gmail.com>

On 1/15/24 15:46, Bin Meng wrote:
> On Mon, Jan 15, 2024 at 7:40 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> Bin Meng <bin.meng@windriver.com> writes:
>>
>>> The Arm dtb changes caused an address change:
>>>
>>>  DefinitionBlock ("", "SSDT", 1, "BOCHS ", "NVDIMM", 0x00000001)
>>>  {
>>>      [ ... ]
>>> -    Name (MEMA, 0x43C80000)
>>> +    Name (MEMA, 0x43D80000)
>>>  }
>>
>> I'm confused by why this changes. Isn't this declaring the size of a
>> NVDIMM region of the memory map? Why does a DTB change affect an ACPI
>> based boot?
>>
> 
> I have no idea too. I suspect that's because the AllocateAlignedPages
> call to allocate a 1 MiB aligned address in the BiosTableTest.c is
> affected by the shrinked DTB now.
> 
> + Laszlo who might know the root cause.

Just speculating:

from "docs/specs/acpi_nvdimm.rst":

Memory:
   QEMU uses BIOS Linker/loader feature to ask BIOS to allocate a memory
   page and dynamically patch its address into an int32 object named "MEMA"
   in ACPI.

Therefore any QEMU-side change that affects memory allocations in the guest may affect the ACPI contents (captured later).

I don't know what the DTB change at hand was, but if (for example) the DTB has grown significantly, that could lead to this. The guest firmware stashes a dynamically allocated copy of the DTB, early on in the PEI phase. Some growth there may change the initial memory map of the DXE phase, which could affect the ACPI linker/loader's allocation operations.

If you can attach the DTB before-after, and the *verbose* firmware log before-after, we might find out finer details.

Laszlo



  reply	other threads:[~2024-01-15 19:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-15  4:34 [PATCH 0/3] hw/arm: Pack the QEMU generated device tree Bin Meng
2024-01-15  4:34 ` [PATCH 1/3] hw/arm: Refactor struct arm_boot_info::get_dtb() Bin Meng
2024-01-15 11:06   ` Philippe Mathieu-Daudé
2024-01-22  3:26   ` Alistair Francis
2024-01-15  4:34 ` [PATCH 2/3] hw/arm: Pack the QEMU generated device tree Bin Meng
2024-01-19 14:17   ` Peter Maydell
2024-01-15  4:34 ` [PATCH 3/3] tests/acpi: Update virt/SSDT.memhp Bin Meng
2024-01-15 11:39   ` Alex Bennée
2024-01-15 14:46     ` Bin Meng
2024-01-15 19:07       ` Laszlo Ersek [this message]
2024-01-19 14:29   ` Peter Maydell
2024-01-19 17:19     ` Laszlo Ersek
2024-01-19 17:46       ` Peter Maydell

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=385fc0d8-2c07-0645-09d5-4f790d5b7dfd@redhat.com \
    --to=lersek@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=bin.meng@windriver.com \
    --cc=bmeng.cn@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /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).