On 27/10/2024 15:16, Michael Kelley wrote: > [...] >> crash_kexec_post_notifiers >> - Run kdump after running panic-notifiers and dumping >> - kmsg. This only for the users who doubt kdump always >> - succeeds in any situation. >> - Note that this also increases risks of kdump failure, >> - because some panic notifiers can make the crashed >> - kernel more unstable. >> + Only jump to kdump kernel after running the panic >> + notifiers and dumping kmsg. This option increases >> + the risks of a kdump failure, since some panic >> + notifiers can make the crashed kernel more unstable. >> + In configurations where kdump may not be reliable, >> + running the panic notifiers could allow collecting >> + more data on dmesg, like stack traces from other CPUS >> + or extra data dumped by panic_print. Note that some >> + configurations enable this option unconditionally, >> + like Hyper-V, PowerPC (fadump) and AMD SEV. > > This last line should be more specific and use "AMD SEV-SNP" instead of > just "AMD SEV". Commit 8ef979584ea8 that you mentioned above is > specific to SEV-SNP. > > There have been three versions of SEV functionality in AMD processors: > * SEV: the original guest VM encryption > * SEV-ES: SEV enhanced to cover register state as well > * SEV-SNP: SEV-ES plus Secure Nested Paging, which provides > functionality to address the Confidential Computing VM threat model > described in the Linux CoCo VM documentation. SEV-SNP processors are > AMD's product that is widely deployed for CoCo VMs in large public clouds. > > Just using "SEV" is somewhat ambiguous because it's not clear whether > it refers to the family of three SEV levels, or just the original guest VM > encryption. Since this case is clearly SEV-SNP only, being specific removes > the ambiguity. > > Michael Thanks a lot Michael, for the clarification. I've just sent a V4 updating that. Cheers, Guilherme
