[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b7cbc2f4-6fef-44c2-a0f4-2d6895c0fd74@intel.com>
Date: Thu, 29 Jan 2026 09:39:55 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "Pratik R. Sampat" <prsampat@....com>, Kiryl Shutsemau <kas@...nel.org>
Cc: 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 1/29/26 09:32, Pratik R. Sampat wrote:
> In that case a fall through for TDX (with a comment explaining why) and
> panic for rest may be the way to go?
No. panic() is an absolute last resort. It's almost never the way to go.
What else can we do to ensure we never reach this code if the platform
doesn't support memory un-acceptance?
Powered by blists - more mailing lists