Re: [PATCH] numa: add 'spm' option for special purpose memory

[David Hildenbrand <david@redhat.com>]

On 02.10.25 16:59, Igor Mammedov wrote:
> On Thu, 2 Oct 2025 16:19:00 +0200
> David Hildenbrand <david@redhat.com> wrote:
> 
>> On 02.10.25 16:11, Igor Mammedov wrote:
>>> On Wed, 24 Sep 2025 18:33:23 +0800
>>> fanhuang <FangSheng.Huang@amd.com> wrote:
>>>    
>>>> Hi David,
>>>>
>>>> I hope this email finds you well. It's been several months since Zhigang last discussion about the Special Purpose Memory (SPM) implementation in QEMU with you, and I wanted to provide some background context before presenting the new patch based on your valuable suggestions.
>>>>
>>>> Previous Discussion Summary
>>>> ===========================
>>>> Back in December 2024, we had an extensive discussion regarding my original patch that added the `hmem` option to `memory-backend-file`. During that conversation, you raised several important concerns about the design approach:
>>>>
>>>> Original Approach (December 2024)
>>>> ----------------------------------
>>>> - Zhigang's patch: Added `hmem=on` option to `memory-backend-file`
>>>> - QEMU cmdline example:
>>>>     -object memory-backend-file,size=16G,id=m1,mem-path=/dev/dax0.0,prealloc=on,align=1G,hmem=on
>>>>     -numa node,nodeid=1,memdev=m1
>>>>
>>>> Your Concerns and Suggestions
>>>> -----------------------------
>>>> You correctly identified some issues with the original approach:
>>>> - Configuration Safety: Users could create problematic configurations like:
>>>>      -object memory-backend-file,size=16G,id=unused,mem-path=whatever,hmem=on
>>>>
>>>> - Your Recommendation: You proposed a cleaner approach using NUMA node configuration:
>>>>      -numa node,nodeid=1,memdev=m1,spm=on
>>>
>>> that seems to me a bit backwards,
>>> aka it's just a particular case where node would have SPM memory only,
>>> which (spm) is not a property of numa node, but rather of memory device attached to it.
>>
>> The problem is that boot memory is not modeled as a memory device.
> 
> That's historical abomination we currently have.

Right, and that's what the memdev= parameter for the node is all about.

> Question is: does it have to be boot memory, and why?

I wondered the same in my reply: I'm afraid it cannot be a DIMM/NVDIMM, 
these ranges are only described in E820 as "hotplug area".

I think it must be something that's present in the memory map right from 
the start, where the OS would identify it as SP and treat it accordingly.

> 
> Also that's why I've asked for use-cases / devices example that would make use of this feature
> (VFIO was mentioned here).

Yes, good point.

-- 
Cheers

David / dhildenb