Re: [PATCH v2] x86/sev: Improve handling of writes to intercepted TSC MSRs

[Nikunj A Dadhania <nikunj@amd.com>]

Sean Christopherson <seanjc@google.com> writes:

> On Wed, Jul 16, 2025, Tom Lendacky wrote:
>> On 7/16/25 00:53, Nikunj A Dadhania wrote:
>> > From: Sean Christopherson <seanjc@google.com>
>> > 
>> > 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 response
>> > incorrectly implies a VMM configuration error, when in fact it is the usual
>> > VMM configuration to intercept writes to read-only MSRs, unless explicitly
>> > documented.
>> > 
>> > Modify the intercepted TSC MSR #VC handling:
>> > * Write to GUEST_TSC_FREQ will generate a #GP instead of terminating the
>> >   guest
>> > * Write to MSR_IA32_TSC will generate a #GP instead of silently ignoring it
>> > 
>> > Add a WARN_ONCE to log the incident, as well-behaved SNP guest kernels
>> > should never attempt to write to these MSRs.
>> > 
>> > However, continue to terminate the guest 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.
>> > 
>> > Signed-off-by: Sean Christopherson <seanjc@google.com>
>
> Feel free to drop me as author and just give me a Reported-by or Suggested-by.
> At this point, I ain't doing a whole lot of anything for this patch :-)

Sure

>
>> > +	if (WARN_ON_ONCE(write)) {
>> 
>> Do we want to capture individual WARNs for each MSR? I guess I'm ok with
>> a single WARN for either MSR, but just asking the question.
>
> Or don't WARN at all.  If the caller is doing a bare wrmsrq(), then the kernel
> will WARN in ex_handler_msr().  If the caller is doing wrmsrq_safe(), do we care
> that they're being deliberately weird?

Agree, we can drop the WARN.

Regards,
Nikunj