From: Zack Rusin <[email protected]> Sent: Tuesday, September 8, 2026 11:07 AM > > A virtual machine may have no guest-local persistent storage or working > userspace after a panic. Preserve the newest kernel log tail in the host > vmware.log, which remains available after the VM terminates. > > Allocate one page during early init and register a panic-only kmsg dumper. > Copy the newest records once, prefix them with "log ", and send one > explicit-length RPC message over the low-bandwidth register path. The page > limit bounds panic-time work and avoids sharing guest memory with the host.
Hyper-V provides a similar capability to push the newest 4 KiB of the kmsg log to the host so it is preserved after the VM terminates. I've used this functionality on many occasions, and it is definitely valuable. The biggest problem is that 4 KiB is often not enough bytes to capture the most relevant part of the stack dump that's created by panic(). If you can expand to 8 KiB, I think you'll find that works much better. For Hyper-V, we're still stuck with the 4 KiB limit because negotiating and staging the expansion with the host hasn't gotten above that team's cut line. Michael > > Keep the source immutable for up to three attempts. Retry only checkpoint > responses, zero-fill a short final word, and close the single RPC channel > on every exit after open. The panic callback allocates nothing, does not > sleep, and emits no printk messages. > > Free the page and leave panic logging disabled if dumper registration > fails, including when CONFIG_PRINTK=n. > > Link: > https://lore.kernel.org/r/[email protected] > Co-developed-by: Bo Gan <[email protected]> > Signed-off-by: Bo Gan <[email protected]> > Co-developed-by: Alexey Makhalov <[email protected]> > Signed-off-by: Alexey Makhalov <[email protected]> > Signed-off-by: Zack Rusin <[email protected]> > --- > arch/x86/include/asm/vmware.h | 1 + > arch/x86/kernel/cpu/vmware.c | 158 ++++++++++++++++++++++++++++++++++ > 2 files changed, 159 insertions(+)
