All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: fanhuang <FangSheng.Huang@amd.com>
Cc: <qemu-devel@nongnu.org>, <david@redhat.com>,
	<imammedo@redhat.com>, <Zhigang.Luo@amd.com>,
	<Lianjie.Shi@amd.com>, Alistair Popple <apopple@nvidia.com>,
	"Bhardwaj, Rajneesh" <Rajneesh.Bhardwaj@amd.com>,
	Paul Blinzer <Paul.Blinzer@amd.com>, <dan.j.williams@intel.com>
Subject: Re: [PATCH v4 1/1] numa: add 'spm' option for Specific Purpose Memory
Date: Tue, 23 Dec 2025 09:56:05 +0000	[thread overview]
Message-ID: <20251223095605.0000065d@huawei.com> (raw)
In-Reply-To: <20251209093841.2250527-2-FangSheng.Huang@amd.com>

On Tue, 9 Dec 2025 17:38:41 +0800
fanhuang <FangSheng.Huang@amd.com> wrote:

> This patch adds support for Specific Purpose Memory (SPM) through the
> NUMA node configuration. When 'spm=on' is specified for a NUMA node,
> the memory region will be reported to the guest as soft reserved,
> allowing device drivers to manage it separately from normal system RAM.
> 
> Note: This option is only supported on x86 platforms. Using spm=on
> on non-x86 machines will result in an error.
> 
> Usage:
>   -numa node,nodeid=0,memdev=m1,spm=on
> 
> Signed-off-by: fanhuang <FangSheng.Huang@amd.com>

Given the discussions at LPC around how to present GPU/HBM memory and
suggestions that reserved might be a better choice. I wonder if this
patch should provide that option as well?  Or maybe as a potential follow
up. The fun their is that you also need to arrange for DSDT entries to
tie the region to the driver that actually wants it.

Anyhow that session reminded me of what SPM was designed for
(you don't want to know how long it took to come up with the name)
and it is a little more subtle than the description in here suggests.

The x86 specific code looks fine to me but I'm more or less totally
unfamiliar with that, so need review from others.

+CC a few folk from that discussion. I wasn't there in person and
it sounded like the discussion moved to the hallway so it may
have come to a totally different conclusion!

https://lpc.events/event/19/contributions/2064/ has links to slides
and youtube video.

> diff --git a/qapi/machine.json b/qapi/machine.json
> index 907cb25f75..cbb19da35c 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -500,6 +500,12 @@
>  # @memdev: memory backend object.  If specified for one node, it must
>  #     be specified for all nodes.
>  #
> +# @spm: if true, mark the memory region of this node as Specific
> +#     Purpose Memory (SPM).  The memory will be reported to the
> +#     guest as soft reserved, allowing device drivers to manage it
> +#     separately from normal system RAM.  Currently only supported
> +#     on x86.  (default: false, since 10.0)

As below. This needs to say something about letting the guest know
that it might want to let a driver manage it separately from normal
system RAM.

> +#
>  # @initiator: defined in ACPI 6.3 Chapter 5.2.27.3 Table 5-145, points
>  #     to the nodeid which has the memory controller responsible for
>  #     this NUMA node.  This field provides additional information as
> @@ -514,6 +520,7 @@
>     '*cpus':   ['uint16'],
>     '*mem':    'size',
>     '*memdev': 'str',
> +   '*spm':    'bool',
>     '*initiator': 'uint16' }}
>  
>  ##
> diff --git a/qemu-options.hx b/qemu-options.hx
> index fca2b7bc74..ffcd1f47cf 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -431,7 +431,7 @@ ERST
>  
>  DEF("numa", HAS_ARG, QEMU_OPTION_numa,
>      "-numa node[,mem=size][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=node]\n"
> -    "-numa node[,memdev=id][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=node]\n"
> +    "-numa node[,memdev=id][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=node][,spm=on|off]\n"
>      "-numa dist,src=source,dst=destination,val=distance\n"
>      "-numa cpu,node-id=node[,socket-id=x][,core-id=y][,thread-id=z]\n"
>      "-numa hmat-lb,initiator=node,target=node,hierarchy=memory|first-level|second-level|third-level,data-type=access-latency|read-latency|write-latency[,latency=lat][,bandwidth=bw]\n"
> @@ -440,7 +440,7 @@ DEF("numa", HAS_ARG, QEMU_OPTION_numa,
>  SRST
>  ``-numa node[,mem=size][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=initiator]``
>    \ 
> -``-numa node[,memdev=id][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=initiator]``
> +``-numa node[,memdev=id][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=initiator][,spm=on|off]``
>    \
>  ``-numa dist,src=source,dst=destination,val=distance``
>    \ 
> @@ -508,6 +508,13 @@ SRST
>      largest bandwidth) to this NUMA node. Note that this option can be
>      set only when the machine property 'hmat' is set to 'on'.
>  
> +    '\ ``spm``\ ' option marks the memory region of this NUMA node as
> +    Specific Purpose Memory (SPM). When enabled, the memory will be
> +    reported to the guest as soft reserved, allowing device drivers to
> +    manage it separately from normal system RAM. This is useful for
> +    device-specific memory that should not be used as general purpose
> +    memory. This option is only supported on x86 platforms.

This wants tweaking.  As came up at the LPC discussion, SPM is for
memory that 'might' be used as general purpose memory if the policy of the
guest is to do so - as Alistair pointed out at LPC, people don't actually
do that very often, but none the less that's why this type exists. It is
a strong hint to the guest that it needs to apply a policy choice to
what happens to this memory.

Reserved is for memory that is only suitable for use other than generic
memory.


  reply	other threads:[~2025-12-23  9:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-09  9:38 [PATCH v4 0/1] numa: add 'spm' option for Specific Purpose Memory fanhuang
2025-12-09  9:38 ` [PATCH v4 1/1] " fanhuang
2025-12-23  9:56   ` Jonathan Cameron via [this message]
2025-12-23 10:01     ` David Hildenbrand (Red Hat)
2025-12-26  7:15       ` Huang, FangSheng (Jerry)
2025-12-26 22:46         ` Alistair Popple
2025-12-30 20:09         ` David Hildenbrand (Red Hat)
2026-01-04 10:43           ` Huang, FangSheng (Jerry)
2025-12-29 18:26 ` [PATCH v4 0/1] " Gregory Price
2025-12-30  2:55   ` Huang, FangSheng (Jerry)
2025-12-30 14:06     ` Gregory Price
2025-12-30 20:15       ` David Hildenbrand (Red Hat)
2025-12-30 23:03         ` Gregory Price
2026-01-02 13:09 ` Igor Mammedov
2026-01-02 16:28   ` Gregory Price
2026-01-02 16:30 ` Gregory Price
2026-01-05 15:29   ` David Hildenbrand (Red Hat)
2026-01-07  9:03     ` Huang, FangSheng (Jerry)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251223095605.0000065d@huawei.com \
    --to=qemu-devel@nongnu.org \
    --cc=FangSheng.Huang@amd.com \
    --cc=Lianjie.Shi@amd.com \
    --cc=Paul.Blinzer@amd.com \
    --cc=Rajneesh.Bhardwaj@amd.com \
    --cc=Zhigang.Luo@amd.com \
    --cc=apopple@nvidia.com \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jonathan.cameron@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.