Re: [PATCH] x86/hyperv: Export hv_hypercall_pg unconditionally

[Naman Jain <namjain@linux.microsoft.com>]

On 9/18/2025 12:17 PM, Peter Zijlstra wrote:
> On Thu, Sep 18, 2025 at 11:33:18AM +0530, Naman Jain wrote:
> 
>> Thank you so much Sean and Paolo for your valuable inputs. I will try
>> out these things. Summarizing the suggestions here:
>> * Use noinstr (no instrumentation)
>> * Have separate .S file
>> * Don't use "register asm".
>> * Use static calls for solving IBT problems
>> * RAX:RCX is probably ok to be used, considering ABI. Whether we would still
>> need to use STACK_FRAME_NON_STANDARD, I am not sure, but I will see based on
>> how it goes.
>>
>> I hope this addresses the concerns Peter raised. If there's anything I might
>> have missed, I'm happy to make further adjustments if needed.
> 
> It would be a definite improvement. I'm just *really* sad people still
> create interfaces like this, even though we've known for years how bad
> they are.
> 
> At some point we've really have to push back and say enough is enough.

Hi Peter, Paolo, Sean,
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.

[2]: arch/x86/hyperv/mshv_vtl_asm.o: error: objtool: static_call: can't 
find static_call_key symbol: __SCK__mshv_vtl_return_hypercall

This gets hidden/fixed with X86_KERNEL_IBT config enablement.

If I comment out the objtool check that leads to this warning, I can see 
the same symbols for __SCT__, __SCK__ in final vmlinux with and without 
IBT, and it even works fine on the VM. So it seems to be a matter of 
timing when objtool is checking for this symbol.
My theory is IBT enablement is helping here as it adds ENDBR 
instructions to various static/indirect/direct calls, which may be 
adding the missing symbol to the section before objtool checks for it.

Other ways I tried to fix the initial problem of noinstr was to make the 
exported shared pointer variable as noinstr, but it does not work since 
noinstr can only be applied to functions and not data types. KVM code 
had similar noisntr calls from assembly, but they have actual functions 
which are marked noinstr, not just some address stored in a variable.

I also tried of introducing wrapper functions marked as noinstr, to 
initialize static calls but it does not help.

Adding compilation dependencies in Makefile also does not help.
$(obj)/mshv_vtl_asm.o: $(obj)/hv_vtl.o

This left me with no option, but to enable IBT and add the dependency.

But yes, this is controversial and if there are alternate ways to handle 
this or make it work, I would be more than happy to hear your 
suggestions on it and implement them.

Regards,
Naman