qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] smbios: make memory device size configurable per Machine


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH] smbios: make memory device size configurable per Machine
Date: Tue, 4 Feb 2025 22:46:28 +0100
User-agent: Mozilla Thunderbird

On 11/7/24 10:42, Igor Mammedov wrote:
On Thu, 11 Jul 2024 10:19:27 +0200
Philippe Mathieu-Daudé <philmd@linaro.org> wrote:

Hi Igor,

On 11/7/24 09:48, Igor Mammedov wrote:
Currently SMBIOS maximum memory device chunk is capped at 16Gb,
which is fine for the most cases (QEMU uses it to describe initial
RAM (type 17 SMBIOS table entries)).
However when starting guest with terabytes of RAM this leads to
too many memory device structures, which eventually upsets linux
kernel as it reserves only 64K for these entries and when that
border is crossed out it runs out of reserved memory.

Instead of partitioning initial RAM on 16Gb chunks, use maximum
possible chunk size that SMBIOS spec allows[1]. Which lets
encode RAM in Mb units in uint32_t-1 field (upto 2047Tb).
As result initial RAM will generate only one type 17 structure
until host/guest reach ability to use more RAM in the future.

Compat changes:
We can't unconditionally change chunk size as it will break
QEMU<->guest ABI (and migration). Thus introduce a new machine class
field that would let older versioned machines to use 16Gb chunks
while new machine type could use maximum possible chunk size.

While it might seem to be risky to rise max entry size this much
(much beyond of what current physical RAM modules support),
I'd not expect it causing much issues, modulo uncovering bugs
in software running within guest. And those should be fixed
on guest side to handle SMBIOS spec properly, especially if
guest is expected to support so huge RAM configs.
In worst case, QEMU can reduce chunk size later if we would
care enough about introducing a workaround for some 'unfixable'
guest OS, either by fixing up the next machine type or
giving users a CLI option to customize it.

1) SMBIOS 3.1.0 7.18.5 Memory Device — Extended Size

PS:
* tested on 8Tb host with RHEL6 guest, which seems to parse
    type 17 SMBIOS table entries correctly (according to 'dmidecode').

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
---
   include/hw/boards.h |  4 ++++
   hw/arm/virt.c       |  1 +
   hw/core/machine.c   |  1 +
   hw/i386/pc_piix.c   |  1 +
   hw/i386/pc_q35.c    |  1 +
   hw/smbios/smbios.c  | 11 ++++++-----
   6 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index ef6f18f2c1..48ff6d8b93 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -237,6 +237,9 @@ typedef struct {
    *    purposes only.
    *    Applies only to default memory backend, i.e., explicit memory backend
    *    wasn't used.
+ * @smbios_memory_device_size:
+ *    Default size of memory device,
+ *    SMBIOS 3.1.0 "7.18 Memory Device (Type 17)"
    */
   struct MachineClass {
       /*< private >*/
@@ -304,6 +307,7 @@ struct MachineClass {
       const CPUArchIdList *(*possible_cpu_arch_ids)(MachineState *machine);
       int64_t (*get_default_cpu_node_id)(const MachineState *ms, int idx);
       ram_addr_t (*fixup_ram_size)(ram_addr_t size);
+    uint64_t smbios_memory_device_size;

Quick notes since I'm on holidays (not meant to block this patch):

- How will evolve this machine class property in the context of
    a heterogeneous machine (i.e. x86_64 cores and 1 riscv32 one)?

I'm not aware of a SMBIOS spec (3.x) that cares about that heterogeneous
setup yet. Are there anything in that area exists yet?

Not yet.


- Should this become a SmbiosProviderInterface later?
if/when SMBIOS does get there (heterogeneous machines), introducing
an interface might make a sense.

OK.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]