On 2/28/2026 4:34 AM, David Hildenbrand wrote:
On 2/26/26 11:50, fanhuang wrote:
Add a 'memmap-type' option to NUMA node configuration that allows
specifying the memory type for a NUMA node.

Supported values:
   - normal:   Regular system RAM (E820 type 1, default)
   - spm:      Specific Purpose Memory (E820 type 0xEFFFFFFF)
   - reserved: Reserved memory (E820 type 2)

The 'spm' type indicates Specific Purpose Memory - a hint to the guest
that this memory might be managed by device drivers based on guest policy.
The 'reserved' type marks memory as not usable as RAM.

Note: This option is only supported on x86 platforms.

Usage:
   -numa node,nodeid=1,memdev=m1,memmap-type=spm

Signed-off-by: fanhuang <[email protected]>
---
  hw/core/numa.c               | 24 ++++++++++++
  hw/i386/acpi-build.c         |  8 ++++
  hw/i386/e820_memory_layout.c | 72 ++++++++++++++++++++++++++++++++++++
  hw/i386/e820_memory_layout.h | 12 +++---
  hw/i386/pc.c                 | 48 ++++++++++++++++++++++++
  include/system/numa.h        |  7 ++++
  qapi/machine.json            | 24 ++++++++++++
  qemu-options.hx              | 14 ++++++-
  8 files changed, 202 insertions(+), 7 deletions(-)

I didn't take a look at the x86 implementation bits. The high-level
concept LGTM.

In an ideal world, we'd only indicate the property if actually supported
by the machine. Not sure if that is easy to achieve with the "-numa"
option. So I guess this has to do :)

Hi David,

Thanks for the review and the LGTM on the high-level concept!

Regarding the per-machine property visibility — agreed, it would be
cleaner. Currently we handle it with a runtime error when memmap-type
is used on non-x86 machines, which seems like a reasonable compromise
given the "-numa" option structure.

I was wondering if there's anything else you or the other maintainers
would like me to address in the current v6? If the patch is in
reasonable shape, it would be great if it could be picked up, as I
have a follow-up OVMF patch for soft reserved memory support that
depends on this QEMU change being merged first.

Happy to make further changes if needed — just let me know.

Thanks,
Jerry Huang

Reply via email to