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"); -- 2.52.0
