[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <155cb321-a169-4a56-b0ac-940676c1e9ee@amd.com>
Date: Thu, 29 Aug 2024 10:16:39 -0500
From: "Kalra, Ashish" <ashish.kalra@....com>
To: Sean Christopherson <seanjc@...gle.com>, Borislav Petkov <bp@...en8.de>
Cc: pbonzini@...hat.com, dave.hansen@...ux.intel.com, tglx@...utronix.de,
mingo@...hat.com, x86@...nel.org, hpa@...or.com, peterz@...radead.org,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org, thomas.lendacky@....com,
michael.roth@....com, kexec@...ts.infradead.org, linux-coco@...ts.linux.dev
Subject: Re: [PATCH] x86/sev: Fix host kdump support for SNP
On 8/29/2024 9:50 AM, Sean Christopherson wrote:
> On Thu, Aug 29, 2024, Borislav Petkov wrote:
>> On August 27, 2024 10:38:04 PM GMT+02:00, Ashish Kalra <Ashish.Kalra@....com> wrote:
>>> From: Ashish Kalra <ashish.kalra@....com>
>>>
>>> With active SNP VMs, SNP_SHUTDOWN_EX invoked during panic notifiers causes
>>> crashkernel boot failure with the following signature:
>> Why would SNP_SHUTDOWN be allowed *at all* if there are active SNP guests and
>> there's potential to lose guest data in the process?!
> Because if the host is panicking, guests are hosed regardless. Unless I'm
> misreading things, the goal here is to ensure the crashkernel can actually capture
> a kdump.
Yes, that is the main goal here to ensure that crashkernel can boot and capture a kdump on a SNP enabled host regardless of SNP VMs running.
Thanks, Ashish
Powered by blists - more mailing lists