Re: [PATCH v1 2/4] x86/vmware: Add the vmware_record_panic_msg sysctl

On Thu, Sep 10, 2026 at 7:44 AM Zack Rusin [off-list ref] wrote:

On Thu, Sep 10, 2026 at 4:32 AM Joel Granados [off-list ref] wrote:

quoted

On Tue, Sep 08, 2026 at 02:07:14PM -0400, Zack Rusin wrote:

quoted

Full panic text is useful on ordinary guests. Encrypted guests should
export it only when an administrator opts in. Reporting a crash does not
require transferring the log.

Enable panic recording by default for ordinary VMware guests and disable
it when guest memory encryption is active. Expose the policy as the
boolean kernel.vmware_record_panic_msg sysctl and document that it
controls only the vmware.log transfer.

Register the sysctl only after the panic buffer and dumper are ready, and
only when sysctl support is built. A registration failure leaves the
internal default in force.

Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
---
 Documentation/admin-guide/sysctl/kernel.rst | 14 +++++++++++++
 arch/x86/kernel/cpu/vmware.c                | 23 +++++++++++++++++++++
 2 files changed, 37 insertions(+)

diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index b6328cd0f43e..4577e935ddcf 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst

@@ -1690,6 +1690,20 @@ entry will default to 2 instead of 0.
 = =============================================================


+vmware_record_panic_msg
+=======================
+
+Controls whether panic kmsg data is written to the host's ``vmware.log``.
+This setting does not control the separate VMware guest-crash event.
+
+= ==============================================================
+0 Do not write panic kmsg data to ``vmware.log``. This is the
+  default for encrypted guests.
+1 Write panic kmsg data to ``vmware.log``. This is the default for
+  ordinary guests.
+= ==============================================================

This seems like it can be represented in a boolean value. Any reason why
you did not use proc_dobool for your handler? Would it make sense to
have vmware_record_panic_msg as a boolean?

Thank you for taking a look! This follows the existing Hyper-V
implementation of hyperv_record_panic_msg, which uses an int and
proc_dointvec_minmax with 0/1 bounds. I thought that consistency
across the codebase was more important even though I agree that bool
and proc_dobool() would be a better fit.

I've been thinking about it and the more I look at this code the more
I feel like respinning v2 and changing vmware_record_panic_msg to
bool. Because kernel.hyperv.record_panic_msg is already in, I'm
worried that if I'll do someone might object based on the fact that
the same option for hyperv behaves differenty introducing a subtle
inconsistency. Any strong opinions on that before I go ahead and make
that change?

z