[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aXs4DTXCbI_c0JPO@thinkstation>
Date: Thu, 29 Jan 2026 10:40:04 +0000
From: Kiryl Shutsemau <kas@...nel.org>
To: Dave Hansen <dave.hansen@...el.com>
Cc: "Pratik R. Sampat" <prsampat@....com>, linux-mm@...ck.org,
linux-coco@...ts.linux.dev, x86@...nel.org, linux-kernel@...r.kernel.org, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com, ardb@...nel.org,
akpm@...ux-foundation.org, david@...nel.org, osalvador@...e.de, thomas.lendacky@....com,
michael.roth@....com
Subject: Re: [PATCH v3 2/2] x86/sev: Add support to unaccept memory after
hot-remove
On Wed, Jan 28, 2026 at 01:15:06PM -0800, Dave Hansen wrote:
> On 1/28/26 12:41, Pratik R. Sampat wrote:
> > +static inline void arch_unaccept_memory(phys_addr_t start, phys_addr_t end)
> > +{
> > + if (cc_platform_has(CC_ATTR_GUEST_SEV_SNP)) {
> > + snp_unaccept_memory(start, end);
> > + } else {
> > + panic("Cannot unaccept memory: unknown platform\n");
> > + }
> > +}
>
> This panic() is pretty nasty.
>
> Can't we just disable memory hotplug up front if it's:
>
> !cc_platform_has(CC_ATTR_GUEST_SEV_SNP)
>
> ?
I don't understand SEV-SNP situation, but I don't think we need to do
anything on unplug for TDX. We should expect the unplugged memory to be
removed from SEPT. If VMM doesn't do this, it is effectively DoS and we
don't protect against DoS in CoCo.
Converting the memory to shared will do no good for us.
--
Kiryl Shutsemau / Kirill A. Shutemov
Powered by blists - more mailing lists