Hello Boris, On 8/29/2024 10:16 AM, Kalra, Ashish wrote: > 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@xxxxxxx> wrote: >>>> From: Ashish Kalra <ashish.kalra@xxxxxxx> >>>> >>>> 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. Are you convinced with Sean's feedback here that this is a required feature to fix ? And it is important to reiterate this again: SNP_DECOMMISSION mainly unbinds the ASID from SNP context and marks the ASID as unusable and then transitions the SNP guest context page to a FW page and SNP_SHUTDOWN_EX transitions all pages associated with the IOMMU to reclaim state which the HV then transitions to hypervisor state, all these page state changes are in the RMP table, so there is no loss of guest data as such and the complete host memory is captured with the crashkernel boot. There are no processes which are being killed and host/guest memory is not being altered or modified in any way. Additionally, i believe that the support staff will absolutely need this kind of support which enables crashkernel/kdump for SNP hosts. Thanks, Ashish
