On Thu, Sep 10, 2026 at 7:44 AM Zack Rusin <[email protected]> wrote: > > 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.
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
smime.p7s
Description: S/MIME Cryptographic Signature
