[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BYAPR21MB16882FAEDEFAED59208ED9E0D700A@BYAPR21MB1688.namprd21.prod.outlook.com>
Date: Wed, 26 Jul 2023 03:44:02 +0000
From: "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To: Tianyu Lan <ltykernel@...il.com>,
KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
Dexuan Cui <decui@...rosoft.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
"arnd@...db.de" <arnd@...db.de>
CC: Tianyu Lan <Tianyu.Lan@...rosoft.com>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"vkuznets@...hat.com" <vkuznets@...hat.com>
Subject: RE: [PATCH V3 5/9] x86/hyperv: Use vmmcall to implement Hyper-V
hypercall in sev-snp enlightened guest
From: Tianyu Lan <ltykernel@...il.com> Sent: Monday, July 17, 2023 8:23 PM
>
> In sev-snp enlightened guest, Hyper-V hypercall needs
> to use vmmcall to trigger vmexit and notify hypervisor
> to handle hypercall request.
>
> Signed-off-by: Tianyu Lan <tiala@...rosoft.com>
> ---
> arch/x86/include/asm/mshyperv.h | 27 ++++++++++++++-------------
> 1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index 2fa38e9f6207..025eda129d99 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -64,12 +64,12 @@ static inline u64 hv_do_hypercall(u64 control, void *input, void *output)
> if (!hv_hypercall_pg)
> return U64_MAX;
>
> - __asm__ __volatile__("mov %4, %%r8\n"
> - CALL_NOSPEC
> + __asm__ __volatile__("mov %[output], %%r8\n"
> + ALTERNATIVE("vmmcall", CALL_NOSPEC, X86_FEATURE_SEV_ES)
Since this code is for SEV-SNP, what's the thinking behind using
X86_FEATURE_SEV_ES in the ALTERNATIVE statements? Don't you need
to use X86_FEATURE_SEV_SNP (which is being added in another patch set that
Boris Petkov pointed out).
Also, does this patch depend on Peter Zijlstra's patch to support nested
ALTERNATIVE statements? If so, that needs to be called out, probably in
the cover letter. Peter's patch doesn't yet appear in linux-next.
Michael
> : "=a" (hv_status), ASM_CALL_CONSTRAINT,
> - "+c" (control), "+d" (input_address)
> - : "r" (output_address),
> - THUNK_TARGET(hv_hypercall_pg)
> + "+c" (control), "+d" (input_address)
> + : [output] "r" (output_address),
> + THUNK_TARGET(hv_hypercall_pg)
> : "cc", "memory", "r8", "r9", "r10", "r11");
> #else
> u32 input_address_hi = upper_32_bits(input_address);
> @@ -105,7 +105,8 @@ static inline u64 _hv_do_fast_hypercall8(u64 control, u64 input1)
>
> #ifdef CONFIG_X86_64
> {
> - __asm__ __volatile__(CALL_NOSPEC
> + __asm__ __volatile__("mov %[thunk_target], %%r8\n"
> + ALTERNATIVE("vmmcall", CALL_NOSPEC, X86_FEATURE_SEV_ES)
> : "=a" (hv_status), ASM_CALL_CONSTRAINT,
> "+c" (control), "+d" (input1)
> : THUNK_TARGET(hv_hypercall_pg)
> @@ -150,13 +151,13 @@ static inline u64 _hv_do_fast_hypercall16(u64 control, u64 input1, u64 input2)
>
> #ifdef CONFIG_X86_64
> {
> - __asm__ __volatile__("mov %4, %%r8\n"
> - CALL_NOSPEC
> - : "=a" (hv_status), ASM_CALL_CONSTRAINT,
> - "+c" (control), "+d" (input1)
> - : "r" (input2),
> - THUNK_TARGET(hv_hypercall_pg)
> - : "cc", "r8", "r9", "r10", "r11");
> + __asm__ __volatile__("mov %[output], %%r8\n"
> + ALTERNATIVE("vmmcall", CALL_NOSPEC, X86_FEATURE_SEV_ES)
> + : "=a" (hv_status), ASM_CALL_CONSTRAINT,
> + "+c" (control), "+d" (input1)
> + : [output] "r" (input2),
> + THUNK_TARGET(hv_hypercall_pg)
> + : "cc", "r8", "r9", "r10", "r11");
> }
> #else
> {
> --
> 2.25.1
Powered by blists - more mailing lists