Hi all,

This is v7 of the SPM (Specific Purpose Memory) patch. Thank you
David for the Acked-by, and Gregory for the Reviewed-by and for
catching the hardcoded address bug.

Changes in v7:
- Fixed pc_update_numa_memory_types() to use x86ms->above_4g_mem_start
  instead of hardcoded 0x100000000ULL (4 GiB). On AMD hosts with IOMMU,
  above_4g_mem_start is relocated to above 1 TB, so the hardcode would
  produce wrong guest physical addresses. (spotted by Gregory Price)

Changes in v6:
- Added validation: memmap-type now requires memdev to be specified,
  to avoid misconfiguration on memory-less NUMA nodes
- Simplified pc_update_numa_memory_types() by replacing switch/goto
  with a direct conditional expression
- Reserved memory nodes are now excluded from SRAT memory affinity
  entries, since E820 already marks them as reserved and SRAT should
  not report them as enabled memory affinity

Use case:
This feature allows marking NUMA node memory as Specific Purpose Memory
(SPM) or reserved in the E820 table. SPM serves as a hint to the guest
that this memory might be managed by device drivers based on guest policy

Example usage:
  -object memory-backend-ram,size=8G,id=m0
  -object memory-backend-memfd,size=8G,id=m1
  -numa node,nodeid=0,memdev=m0
  -numa node,nodeid=1,memdev=m1,memmap-type=spm

Supported memmap-type values:
  - normal:   Regular system RAM (E820 type 1, default)
  - spm:      Specific Purpose Memory (E820 type 0xEFFFFFFF), a hint
              that this memory might be managed by device drivers
  - reserved: Reserved memory (E820 type 2), not usable as RAM

Please review. Thanks!

Best regards,
Jerry Huang

fanhuang (1):
  numa: add 'memmap-type' option for memory type configuration

 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(-)

-- 
2.34.1

On 3/6/2026 4:27 PM, fanhuang wrote:
> Hi all,
> 
> This is v7 of the SPM (Specific Purpose Memory) patch. Thank you
> David for the Acked-by, and Gregory for the Reviewed-by and for
> catching the hardcoded address bug.
> 
> Changes in v7:
> - Fixed pc_update_numa_memory_types() to use x86ms->above_4g_mem_start
>    instead of hardcoded 0x100000000ULL (4 GiB). On AMD hosts with IOMMU,
>    above_4g_mem_start is relocated to above 1 TB, so the hardcode would
>    produce wrong guest physical addresses. (spotted by Gregory Price)
> 
> Changes in v6:
> - Added validation: memmap-type now requires memdev to be specified,
>    to avoid misconfiguration on memory-less NUMA nodes
> - Simplified pc_update_numa_memory_types() by replacing switch/goto
>    with a direct conditional expression
> - Reserved memory nodes are now excluded from SRAT memory affinity
>    entries, since E820 already marks them as reserved and SRAT should
>    not report them as enabled memory affinity
> 
> Use case:
> This feature allows marking NUMA node memory as Specific Purpose Memory
> (SPM) or reserved in the E820 table. SPM serves as a hint to the guest
> that this memory might be managed by device drivers based on guest policy
> 
> Example usage:
>    -object memory-backend-ram,size=8G,id=m0
>    -object memory-backend-memfd,size=8G,id=m1
>    -numa node,nodeid=0,memdev=m0
>    -numa node,nodeid=1,memdev=m1,memmap-type=spm
> 
> Supported memmap-type values:
>    - normal:   Regular system RAM (E820 type 1, default)
>    - spm:      Specific Purpose Memory (E820 type 0xEFFFFFFF), a hint
>                that this memory might be managed by device drivers
>    - reserved: Reserved memory (E820 type 2), not usable as RAM
> 
> Please review. Thanks!
> 
> Best regards,
> Jerry Huang
> 
> fanhuang (1):
>    numa: add 'memmap-type' option for memory type configuration
> 
>   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(-)
> 
Hi Gregory,

Thanks again for the thorough review on v6 and for catching the hardcoded
address issue — v7 has that fixed, now using x86ms->above_4g_mem_start as
you suggested.

Just wanted to follow up and check if your Reviewed-by still applies to v7,
since it's a minimal change from v6 (only the one-line fix you identified).

On a related note, the corresponding OVMF patch for E820 Soft Reserved
support has been merged upstream (edk2 PR #11964), so the firmware side is
now in place. The QEMU patch is the remaining piece to complete the 
pipeline.

Could you also advise on the next steps for getting this merged?
is there a target merge window? Happy to provide anything else that's 
needed.

Thanks,
Jerry Huang

On Fri, Mar 13, 2026 at 04:30:20PM +0800, Huang, FangSheng (Jerry) wrote:
> Hi Gregory,
> 
> Thanks again for the thorough review on v6 and for catching the hardcoded
> address issue — v7 has that fixed, now using x86ms->above_4g_mem_start as
> you suggested.
> 
> Just wanted to follow up and check if your Reviewed-by still applies to v7,
> since it's a minimal change from v6 (only the one-line fix you identified).
> 

Yes sorry, we're good to go

Reviewed-by: Gregory Price <gourry@gourry.net>

Thank you for this, this will be very helpful for testing

Jonathan would be able to answer more questions re: upstream

On Fri, 13 Mar 2026 11:18:18 -0400
Gregory Price <gourry@gourry.net> wrote:

> On Fri, Mar 13, 2026 at 04:30:20PM +0800, Huang, FangSheng (Jerry) wrote:
> > Hi Gregory,
> > 
> > Thanks again for the thorough review on v6 and for catching the hardcoded
> > address issue — v7 has that fixed, now using x86ms->above_4g_mem_start as
> > you suggested.
> > 
> > Just wanted to follow up and check if your Reviewed-by still applies to v7,
> > since it's a minimal change from v6 (only the one-line fix you identified).
> >   
> 
> Yes sorry, we're good to go
> 
> Reviewed-by: Gregory Price <gourry@gourry.net>
> 
> Thank you for this, this will be very helpful for testing
> 
> Jonathan would be able to answer more questions re: upstream

Can provide general details, but specifics of this patch is probably
something for Igor as it's not CXL specific.

Soft freeze for 11.0 has passed, so this will be a 11.1 feature.
https://wiki.qemu.org/Planning/11.0
Is the 11.0 timeline. (11.1 will go up around time of 11.0 release).

Jonathan

On 3/14/2026 12:14 AM, Jonathan Cameron wrote:
> On Fri, 13 Mar 2026 11:18:18 -0400
> Gregory Price <gourry@gourry.net> wrote:
> 
>> On Fri, Mar 13, 2026 at 04:30:20PM +0800, Huang, FangSheng (Jerry) wrote:
>>> Hi Gregory,
>>>
>>> Thanks again for the thorough review on v6 and for catching the hardcoded
>>> address issue — v7 has that fixed, now using x86ms->above_4g_mem_start as
>>> you suggested.
>>>
>>> Just wanted to follow up and check if your Reviewed-by still applies to v7,
>>> since it's a minimal change from v6 (only the one-line fix you identified).
>>>    
>>
>> Yes sorry, we're good to go
>>
>> Reviewed-by: Gregory Price <gourry@gourry.net>
>>
>> Thank you for this, this will be very helpful for testing
>>
>> Jonathan would be able to answer more questions re: upstream
> 
> Can provide general details, but specifics of this patch is probably
> something for Igor as it's not CXL specific.
> 
> Soft freeze for 11.0 has passed, so this will be a 11.1 feature.
> https://wiki.qemu.org/Planning/11.0
> Is the 11.0 timeline. (11.1 will go up around time of 11.0 release).
> 
> Jonathan

Hi Gregory, Jonathan,

Thank you both!

Gregory — much appreciated for the Reviewed-by and your continued
support throughout the review process.

Jonathan — thanks for clarifying the timeline. Understood that this
would target the 11.1 cycle. Will follow up with Igor when the 11.1 
window opens up.

Best regards,
Jerry Huang