From: "Pratik R. Sampat" <prsampat@amd.com>
To: Kiryl Shutsemau <kas@kernel.org>,
"David Hildenbrand (Arm)" <david@kernel.org>
Cc: linux-mm@kvack.org, linux-coco@lists.linux.dev, x86@kernel.org,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
ardb@kernel.org, akpm@linux-foundation.org, osalvador@suse.de,
thomas.lendacky@amd.com, michael.roth@amd.com
Subject: Re: [PATCH v4 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
Date: Mon, 16 Feb 2026 08:45:01 -0600 [thread overview]
Message-ID: <fe516b2b-4b63-4da2-ab9d-7d3e71e3091b@amd.com> (raw)
In-Reply-To: <aYXYRf4lxm_iQwjE@thinkstation>
On 2/6/26 6:03 AM, Kiryl Shutsemau wrote:
> On Thu, Feb 05, 2026 at 06:29:08PM +0100, David Hildenbrand (Arm) wrote:
>>> Ideally, we want to know on boot:
>>>
>>> - what memory ranges are unaccepted - we have it;
>>> - what memory range can be removed or added after boot - we don't have it
>>
>> The SRAT describes memory ranges where we can see hotplug memory. Is that
>> too late? We calculate max_possible_pfn based on that.
>
> The cleanest way would be to declare the ranges in EFI memory map, not
> SRAT. It should be doable.
>
Got it. I'm speaking to a few EFI folks on how that would work; if we'd
need a new type to specify this or we could piggyback off an existing
type with either the hotpluggable attribute or create a new one.
Thanks,
Pratik
next prev parent reply other threads:[~2026-02-16 14:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 17:49 [PATCH v4 0/2] SEV-SNP Unaccepted Memory Hotplug Pratik R. Sampat
2026-02-03 17:49 ` [PATCH v4 1/2] mm/memory_hotplug: Add support to accept memory during hot-add Pratik R. Sampat
2026-02-04 11:22 ` Kiryl Shutsemau
2026-02-04 19:59 ` David Hildenbrand (arm)
2026-02-05 3:50 ` Pratik R. Sampat
2026-02-05 10:51 ` Kiryl Shutsemau
2026-02-04 20:00 ` David Hildenbrand (arm)
2026-02-05 3:50 ` Pratik R. Sampat
2026-02-05 10:48 ` Kiryl Shutsemau
2026-02-05 15:48 ` David Hildenbrand (Arm)
2026-02-05 16:08 ` Kiryl Shutsemau
2026-02-05 17:29 ` David Hildenbrand (Arm)
2026-02-06 12:03 ` Kiryl Shutsemau
2026-02-16 14:45 ` Pratik R. Sampat [this message]
2026-02-03 17:49 ` [PATCH v4 2/2] x86/sev: Add support to unaccept memory after hot-remove Pratik R. Sampat
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=fe516b2b-4b63-4da2-ab9d-7d3e71e3091b@amd.com \
--to=prsampat@amd.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=kas@kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=osalvador@suse.de \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.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