On 10/6/2025 4:49 PM, Paolo Bonzini wrote:
On Mon, Oct 6, 2025 at 1:10 PM Peter Zijlstra <[email protected]> wrote:

On Mon, Oct 06, 2025 at 04:20:03PM +0530, Naman Jain wrote:

I am facing issues in this approach, after moving the assembly code to a
separate file, using static calls, and making it noinstr.

We need to make a call to STATIC_CALL_TRAMP_STR(hv_hypercall_pg + offset) in
the assembly code. This offset is populated at run time in the driver, so I
have to pass this offset to the assembly function via function parameters or
a shared variable. This leaves noinstr section and results in below warning:

[1]: vmlinux.o: warning: objtool: __mshv_vtl_return_call+0x4f: call to
mshv_vtl_call_addr() leaves .noinstr.text section


To fix this, one of the ways was to avoid making indirect calls. So I used
EXPORT_STATIC_CALL to export the static call *trampoline and key* for the
static call we created in C driver. Then I figured, we could simply call
__SCT__<static_callname> in assembly code and it should work fine. But then
it leads to this error in objtool.

Easiest solution is to create a second static_call and have
hv_set_hypercall_pg() set that to +offset.

Yes, my idea was to add +offset directly in the static_call_update, as
you sketched below. Sorry if that wasn't too clear. I didn't think of
using a static call also for the base of the page, since that's not
what the assembly code needs.

And I think we agree that you absolutely don't want indirect calls, as
that makes register usage much simpler. This way static calls end up
killing multiple birds with a stone.


Actually I was implementing it in the same way by introducing a new static call using hypercall_pg+offset. The problem was using it in asm file. When I tried introducing a wrapper static call earlier, I did not use ASM_CALL_CONSTRAINT, so objtool was asking me to save/restore registers again. Since this was not possible, I thought it may not work.

With something similar to how its done in arch/x86/include/asm/preempt.h, I was able to make it work, and remove dependency on IBT config.

Thanks a lot Peter and Paolo for helping on this.

Regards,
Naman

Also, what's actually in that hypercall page that is so magical and
can't just be an ALTERNATIVE() ?

Do you mean an alternative for VMCALL vs. VMMCALL? If so, that's just
not guaranteed to work: "An attempt to invoke a hypercall by any other
means (for example, copying the code from the hypercall code page to
an alternate location and executing it from there) might result in an
undefined operation (#UD) exception" (or it might not).

Paolo



Reply via email to