Re: [PATCH v6 1/1] numa: add 'memmap-type' option for memory type configuration

[David Hildenbrand <david@kernel.org>]

On 3/2/26 10:01, Huang, FangSheng (Jerry) wrote:
> 
> 
> 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 <FangSheng.Huang@amd.com>
>>> ---
>>>   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?

Not from my side, so

Acked-by: David Hildenbrand <david@kernel.org>

on the core bits.

-- 
Cheers,

David