[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <77076b24-c503-40e8-9459-ede808074f0f@zytor.com>
Date: Wed, 27 Aug 2025 15:43:00 -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/27/2025 3:24 PM, Xin Li wrote:
> 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;
Putting fred_rsp0_fallback in struct kvm_vcpu_arch reminds me one thing:
We know AMD will do FRED and follow the FRED spec for bare metal, but
regarding virtualization of FRED, I have no idea how it will be done on
AMD, so I keep the KVM FRED code in VMX files, e.g., msr_guest_fred_rsp0 is
defined in struct vcpu_vmx, and saved/restored in vmx.c.
It is a future task to make common KVM FRED code for Intel and AMD.
Powered by blists - more mailing lists