From: Sean Christopherson <seanjc@google.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Nikunj A Dadhania <nikunj@amd.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
tglx@linutronix.de, mingo@redhat.com,
dave.hansen@linux.intel.com, thomas.lendacky@amd.com,
santosh.shukla@amd.com
Subject: Re: [PATCH] x86/sev: Improve handling of writes to intercepted GUEST_TSC_FREQ
Date: Mon, 14 Jul 2025 07:24:50 -0700 [thread overview]
Message-ID: <aHUTMiEJ-nd76lxM@google.com> (raw)
In-Reply-To: <20250714104424.GGaHTfiFxI_pf-vhRn@fat_crate.local>
On Mon, Jul 14, 2025, Borislav Petkov wrote:
> On Fri, Jul 11, 2025 at 09:42:00AM +0530, Nikunj A Dadhania wrote:
> > From: Sean Christopherson <seanjc@google.com>
> >
> > For Secure TSC enabled guests, don't panic when a guest writes to
> > intercepted GUEST_TSC_FREQ MSR. Instead, ignore writes to GUEST_TSC_FREQ,
> > similar to MSR_IA32_TSC, and log a warning instead.
>
> Why?
>
> Nothing should poke at the TSC MSR and those who do, deserve what they get.
>
> > Only terminate the guest when reading from intercepted GUEST_TSC_FREQ MSR
> > with Secure TSC enabled, as this indicates an unexpected hypervisor
> > configuration.
>
> Huh, this sounds weird.
>
> What are we "fixing" here?
Returning ES_VMM_ERROR is misleading/wrong, and panicking doesn't match how the
kernel handles every other "bad" WRMSR. How's this for a changelog?
For Secure TSC enabled guests, don't panic if the kernel hits a #VC due
to attempting to write to GUEST_TSC_FREQ, and instead WARN and drop the
write. The kernel should never write GUEST_TSC_FREQ as it's read-only,
but panicking with ES_VMM_ERROR is both misleading (it's entirely
reasonable for a VMM to intercept writes to a read-only MSR), and
unnecessary, e.g. the kernel eats #GPs with a WARN on every other "bad"
WRMSR.
next prev parent reply other threads:[~2025-07-14 14:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-11 4:12 [PATCH] x86/sev: Improve handling of writes to intercepted GUEST_TSC_FREQ Nikunj A Dadhania
2025-07-14 10:44 ` Borislav Petkov
2025-07-14 14:24 ` Sean Christopherson [this message]
2025-07-14 14:59 ` Tom Lendacky
2025-07-14 15:17 ` Sean Christopherson
2025-07-14 16:16 ` Borislav Petkov
2025-07-14 16:36 ` Sean Christopherson
2025-07-15 8:37 ` Nikunj A Dadhania
2025-07-15 8:43 ` Borislav Petkov
2025-07-15 8:58 ` Nikunj A Dadhania
2025-07-15 8:38 ` Borislav Petkov
2025-07-15 9:13 ` Nikunj A Dadhania
2025-07-15 9:44 ` Borislav Petkov
2025-07-15 12:47 ` Tom Lendacky
2025-07-16 6:09 ` Nikunj A Dadhania
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aHUTMiEJ-nd76lxM@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=santosh.shukla@amd.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.