[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9f8007a3-f810-4b60-8942-e721cd6a32c4@linux.microsoft.com>
Date: Mon, 6 Oct 2025 16:20:03 +0530
From: Naman Jain <namjain@...ux.microsoft.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Sean Christopherson <seanjc@...gle.com>,
Paolo Bonzini <pbonzini@...hat.com>, Roman Kisel
<romank@...ux.microsoft.com>, "K . Y . Srinivasan" <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>, Wei Liu <wei.liu@...nel.org>,
Dexuan Cui <decui@...rosoft.com>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H . Peter Anvin" <hpa@...or.com>, linux-hyperv@...r.kernel.org,
linux-kernel@...r.kernel.org, mhklinux@...look.com
Subject: Re: [PATCH] x86/hyperv: Export hv_hypercall_pg unconditionally
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
Powered by blists - more mailing lists