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

[Zack Rusin]

On Thu, Sep 10, 2026 at 4:32 AM Joel Granados <joel.granados@xxxxxxxxxx> 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 <zack.rusin@xxxxxxxxxxxx>
> > ---
> >  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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature