qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: fanhuang <FangSheng.Huang@amd.com>,
	qemu-devel@nongnu.org, Zhigang.Luo@amd.com, Lianjie.Shi@amd.com
Subject: Re: [PATCH] numa: add 'spm' option for special purpose memory
Date: Thu, 2 Oct 2025 16:59:36 +0200	[thread overview]
Message-ID: <20251002165936.490718f5@fedora> (raw)
In-Reply-To: <aa461a43-0db8-482a-aabc-897cfa619dee@redhat.com>

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.
Question is: does it have to be boot memory, and why?

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



  reply	other threads:[~2025-10-02 15:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-24 10:33 [PATCH] numa: add 'spm' option for special purpose memory fanhuang
2025-09-24 10:33 ` fanhuang
2025-09-24 17:03 ` David Hildenbrand
2025-09-25  7:39   ` Huang, FangSheng (Jerry)
2025-09-25 11:11     ` Huang, FangSheng (Jerry)
2025-10-02 14:11 ` Igor Mammedov
2025-10-02 14:19   ` David Hildenbrand
2025-10-02 14:59     ` Igor Mammedov [this message]
2025-10-02 15:51       ` David Hildenbrand

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=20251002165936.490718f5@fedora \
    --to=imammedo@redhat.com \
    --cc=FangSheng.Huang@amd.com \
    --cc=Lianjie.Shi@amd.com \
    --cc=Zhigang.Luo@amd.com \
    --cc=david@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).