[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cc44a4a7e7a4cabacad76c875e50cc5ff19c6e23.camel@redhat.com>
Date: Thu, 02 Nov 2023 20:07:20 +0200
From: Maxim Levitsky <mlevitsk@...hat.com>
To: John Allen <john.allen@....com>, kvm@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, pbonzini@...hat.com,
weijiang.yang@...el.com, rick.p.edgecombe@...el.com,
seanjc@...gle.com, x86@...nel.org, thomas.lendacky@....com,
bp@...en8.de
Subject: Re: [PATCH 5/9] KVM: SVM: Save shadow stack host state on VMRUN
On Tue, 2023-10-10 at 20:02 +0000, John Allen wrote:
> When running as an SEV-ES guest, the PL0_SSP, PL1_SSP, PL2_SSP, PL3_SSP,
> and U_CET fields in the VMCB save area are type B, meaning the host
> state is automatically loaded on a VMEXIT, but is not saved on a VMRUN.
> The other shadow stack MSRs, S_CET, SSP, and ISST_ADDR are type A,
> meaning they are loaded on VMEXIT and saved on VMRUN. PL0_SSP, PL1_SSP,
> and PL2_SSP are currently unused. Manually save the other type B host
> MSR values before VMRUN.
>
> Signed-off-by: John Allen <john.allen@....com>
> ---
> arch/x86/kvm/svm/sev.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index b9a0a939d59f..bb4b18baa6f7 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -3098,6 +3098,15 @@ void sev_es_prepare_switch_to_guest(struct sev_es_save_area *hostsa)
> hostsa->dr2_addr_mask = amd_get_dr_addr_mask(2);
> hostsa->dr3_addr_mask = amd_get_dr_addr_mask(3);
> }
> +
> + if (boot_cpu_has(X86_FEATURE_SHSTK)) {
> + /*
> + * MSR_IA32_U_CET and MSR_IA32_PL3_SSP are restored on VMEXIT,
> + * save the current host values.
> + */
> + rdmsrl(MSR_IA32_U_CET, hostsa->u_cet);
> + rdmsrl(MSR_IA32_PL3_SSP, hostsa->pl3_ssp);
> + }
> }
Do we actually need this patch?
Host FPU state is not encrypted, and as far as I understood from the common CET patch series,
that on return to userspace these msrs will be restored.
Best regards,
Maxim Levitsky
PS: AMD's APM is silent on how 'S_CET, SSP, and ISST_ADDR' are saved/restored for non encrypted guests.
Are they also type A?
Can the VMSA table be trusted in general to provide the same swap type as for the non encrypted guests?
>
> void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu *vcpu, u8 vector)
Powered by blists - more mailing lists