On Thu, Sep 10, 2026 at 4:32 AM Joel Granados <[email protected]> wrote: > > On Tue, Sep 08, 2026 at 02:07:14PM -0400, Zack Rusin wrote: > > 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 <[email protected]> > > --- > > 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. z
smime.p7s
Description: S/MIME Cryptographic Signature
