[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b1c5f80-bbe1-4294-8ede-5e097e8feda1@zytor.com>
Date: Wed, 27 Aug 2025 15:24:58 -0700
From: Xin Li <xin@...or.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
linux-doc@...r.kernel.org, pbonzini@...hat.com, corbet@....net,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
luto@...nel.org, peterz@...radead.org, andrew.cooper3@...rix.com,
chao.gao@...el.com, hch@...radead.org
Subject: Re: [PATCH v6 06/20] KVM: VMX: Set FRED MSR intercepts
On 8/26/2025 3:17 PM, Sean Christopherson wrote:
>> + if (!kvm_cpu_cap_has(X86_FEATURE_SHSTK))
>> + wrmsrns(MSR_IA32_FRED_SSP0, vmx->msr_guest_fred_ssp0);
> FWIW, if we can't get an SDM change, don't bother with RDMSR/WRMSRNS, just
> configure KVM to intercept accesses. Then in kvm_set_msr_common(), pivot on
> X86_FEATURE_SHSTK, e.g.
Intercepting is a solid approach: it ensures the guest value is fully
virtual and does not affect the hardware FRED SSP0 MSR. Of course the code
is also simplified.
>
> case MSR_IA32_U_CET:
> case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP:
> if (!kvm_cpu_cap_has(X86_FEATURE_SHSTK)) {
> WARN_ON_ONCE(msr != MSR_IA32_FRED_SSP0);
> vcpu->arch.fred_rsp0_fallback = data;
> break;
> }
>
> kvm_set_xstate_msr(vcpu, msr_info);
> break;
>
> and
>
> case MSR_IA32_U_CET:
> case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP:
> if (!kvm_cpu_cap_has(X86_FEATURE_SHSTK)) {
> WARN_ON_ONCE(msr_info->index != MSR_IA32_FRED_SSP0);
> vcpu->arch.fred_rsp0_fallback = msr_info->data;
> break;
> }
>
> kvm_get_xstate_msr(vcpu, msr_info);
> break;
Powered by blists - more mailing lists