On November 21, 2025 6:14:11 AM PST, Uros Bizjak <[email protected]> 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"); >
I think it would be good to have a comment at the point where ASM_CALL_CONSTRAINT is defined explaining its proper use. Specifically, instructions like syscall, vmcall, vmfunc, vmmcall, int xx and VM-specific escape instructions are not "calls" because they either don't modify the stack or create an exception frame (kernel) or signal frame (user space) which is completely special.
