From: Nikunj A Dadhania <nikunj@amd.com>
To: Sean Christopherson <seanjc@google.com>, Borislav Petkov <bp@alien8.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
<linux-kernel@vger.kernel.org>, <x86@kernel.org>,
<tglx@linutronix.de>, <mingo@redhat.com>,
<dave.hansen@linux.intel.com>, <santosh.shukla@amd.com>
Subject: Re: [PATCH] x86/sev: Improve handling of writes to intercepted GUEST_TSC_FREQ
Date: Tue, 15 Jul 2025 08:37:38 +0000 [thread overview]
Message-ID: <85jz49x31p.fsf@amd.com> (raw)
In-Reply-To: <aHUx9ILdUZJHefjZ@google.com>
Sean Christopherson <seanjc@google.com> writes:
> On Mon, Jul 14, 2025, Borislav Petkov wrote:
>> On Mon, Jul 14, 2025 at 08:17:13AM -0700, Sean Christopherson wrote:
>>
>> The original text in the patch:
>>
>> "Only terminate the guest when reading from intercepted GUEST_TSC_FREQ MSR
>> with Secure TSC enabled, as this indicates an unexpected hypervisor
>> configuration."
>>
>> doesn't make too much sense to me.
>>
>> Maybe you need to explain things in detail as virt and I don't understand each
>> other too much yet.
How about the below changelog:
Currently, when a Secure TSC enabled SNP guest attempts to write to
the intercepted GUEST_TSC_FREQ MSR (a read-only MSR), the guest kernel
#VC handler terminates the SNP guest by returning ES_VMM_ERROR. This
response incorrectly implies a VMM configuration error, when in fact
it's a valid VMM configuration to intercept writes to read-only MSRs,
unless explicitly documented.
Modify the intercepted GUEST_TSC_FREQ MSR #VC handler to ignore writes
instead of terminating the guest. Since GUEST_TSC_FREQ is a guest-only
MSR, ignoring writes directly (rather than forwarding to the VMM and
handling the resulting #GP) eliminates a round trip to the VMM. Add a
WARN_ONCE to log the incident, as well-behaved guest kernels should
never attempt to write to this read-only MSR.
However, continue to terminate the guest(via ES_VMM_ERROR) when
reading from intercepted GUEST_TSC_FREQ MSR with Secure TSC enabled,
as intercepted reads indicate an improper VMM configuration for Secure
TSC enabled SNP guests.
Regards,
Nikunj
next prev parent reply other threads:[~2025-07-15 8:37 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
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 [this message]
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=85jz49x31p.fsf@amd.com \
--to=nikunj@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=santosh.shukla@amd.com \
--cc=seanjc@google.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.