On 2026-01-05 01:02, Uros Bizjak wrote: > Unlike CALL instruction, VMMCALL does not push to the stack, so it's > OK to allow the compiler to insert it before the frame pointer gets > set up by the containing function. ASM_CALL_CONSTRAINT is for CALLs > that must be inserted after the frame pointer is set up, so it is > over-constraining here and can be removed. > > Signed-off-by: Uros Bizjak <[email protected]> > Tested-by: Michael Kelley <[email protected]> > Cc: "K. Y. Srinivasan" <[email protected]> > Cc: Haiyang Zhang <[email protected]> > Cc: Wei Liu <[email protected]> > Cc: Dexuan Cui <[email protected]> > Cc: Thomas Gleixner <[email protected]> > Cc: Ingo Molnar <[email protected]> > Cc: Borislav Petkov <[email protected]> > Cc: Dave Hansen <[email protected]> > Cc: "H. Peter Anvin" <[email protected]> > --- > v2: Expand commit message and include ASM_CALL_CONSTRAINT explanation > --- > arch/x86/hyperv/ivm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c > index 7365d8f43181..be7fad43a88d 100644 > --- a/arch/x86/hyperv/ivm.c > +++ b/arch/x86/hyperv/ivm.c > @@ -392,7 +392,7 @@ u64 hv_snp_hypercall(u64 control, u64 param1, u64 param2) > > register u64 __r8 asm("r8") = param2; > asm volatile("vmmcall" > - : "=a" (hv_status), ASM_CALL_CONSTRAINT, > + : "=a" (hv_status), > "+c" (control), "+d" (param1), "+r" (__r8) > : : "cc", "memory", "r9", "r10", "r11"); >
Looks good to me; I'm not familiar directly with HyperV, but vmmcall is a system call-type instruction which doesn't use the stack. Acked-by: H. Peter Anvin (Intel) <[email protected]>
