From: Kiryl Shutsemau <kas@kernel.org>
To: "Pratik R. Sampat" <prsampat@amd.com>
Cc: "David Hildenbrand (arm)" <david@kernel.org>,
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: Thu, 5 Feb 2026 10:48:20 +0000 [thread overview]
Message-ID: <aYR0vqwyFPo3EKAi@thinkstation> (raw)
In-Reply-To: <70be936e-e49d-4485-8d1e-416fdf8f40a4@amd.com>
On Wed, Feb 04, 2026 at 09:50:09PM -0600, Pratik R. Sampat wrote:
>
>
> On 2/4/26 2:00 PM, David Hildenbrand (arm) wrote:
> >> #endif
> >> static inline bool pfn_is_unaccepted_memory(unsigned long pfn)
> >> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> >> index a63ec679d861..549ccfd190ee 100644
> >> --- a/mm/memory_hotplug.c
> >> +++ b/mm/memory_hotplug.c
> >> @@ -1567,6 +1567,8 @@ int add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags)
> >> if (!strcmp(res->name, "System RAM"))
> >> firmware_map_add_hotplug(start, start + size, "System RAM");
> >> + accept_hotplug_memory(start, size);
> >> +
> >> /* device_online() will take the lock when calling online_pages() */
> >> mem_hotplug_done();
> >>
> >
> > I really hate that accepting (and un-accepting) hotplugged memory is different to accepting ordinary boot memory.
> >
> > Is there really no way we can get a reasonable implementation where we just call a generic accept_memory() and it will know what to do?
> >
>
> Sure, that shouldn't be impossible.
>
> The only reason I initially kept them separate is because we accept and update
> the bitmap unconditionally. This mainly applies to cold-plugged memory since
> their bitmap state after remove shouldn't matter. However, as we are now
> correctly setting the bits in the hot-remove path we should be fine accepting
> from the for_each_set_bitrange_from() logic within accept_memory(), I think.
>
> Something like so?
>
> diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/efi/unaccepted_memory.c
> index d11e7836200a..e56adfd382f8 100644
> --- a/drivers/firmware/efi/unaccepted_memory.c
> +++ b/drivers/firmware/efi/unaccepted_memory.c
> @@ -36,6 +36,7 @@ void accept_memory(phys_addr_t start, unsigned long size)
> unsigned long range_start, range_end;
> struct accept_range range, *entry;
> phys_addr_t end = start + size;
> + phys_addr_t bitmap_end;
> unsigned long flags;
> u64 unit_size;
>
> @@ -44,6 +45,21 @@ void accept_memory(phys_addr_t start, unsigned long size)
> return;
>
> unit_size = unaccepted->unit_size;
> + bitmap_end = unaccepted->phys_base + unaccepted->size * unit_size * BITS_PER_BYTE;
> +
> + /* Memory completely beyond bitmap: hotplug memory, accept unconditionally */
> + if (start >= bitmap_end) {
> + arch_accept_memory(start, end);
> + return;
> + }
> +
> + /* Memory partially beyond bitmap */
> + if (end > bitmap_end) {
> + arch_accept_memory(bitmap_end, end);
> + end = bitmap_end;
> + }
You are calling arch_accept_memory() on every memory allocation if the
memory is not represented in the bitmap. Hard NAK.
>
> /*
> * Only care for the part of the range that is represented
>
> unaccept_hotplug_memory() truly doesn't do anything special for hotplug so I
> could just re-name it unaccept_memory().
>
> Thanks!
>
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2026-02-05 10:48 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 [this message]
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
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=aYR0vqwyFPo3EKAi@thinkstation \
--to=kas@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@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=prsampat@amd.com \
--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 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.