On 8/25/2025 3:12 PM, Peter Zijlstra wrote:
On Mon, Aug 25, 2025 at 11:22:08AM +0530, Naman Jain wrote:
With commit 0e20f1f4c2cb ("x86/hyperv: Clean up hv_do_hypercall()"),
config checks were added to conditionally restrict export
of hv_hypercall_pg symbol at the same time when a usage of that symbol
was added in mshv_vtl_main.c driver. This results in missing symbol
warning when mshv_vtl_main is compiled. Change the logic to
export it unconditionally.
Fixes: 96a1d2495c2f ("Drivers: hv: Introduce mshv_vtl driver")
Signed-off-by: Naman Jain <namj...@linux.microsoft.com>
Oh gawd, that commit is terrible and adds yet another hypercall
interface.
I would argue the proper fix is moving the whole of mshv_vtl_return()
into the kernel proper and doing it like hv_std_hypercall() on x86_64.
Thanks for the review comments.
This is doable, I can move the hypercall part of it to
arch/x86/hyperv/hv_init.c if I understand correctly.
Additionally, how is that function not utterly broken? What happens if
an interrupt or NMI comes in after native_write_cr2() and before the
actual hypercall does VMEXIT and trips a #PF?
mshv_vtl driver is used for OpenHCL paravisor. The interrupts are
disabled, and NMIs aren't sent to the paravisor by the virt stack.
And an rax:rcx return, I though the canonical pair was AX,DX !?!?
Here, the code uses rax and rcx not as a means to return one 128 bit
value. The code uses them in that way as an ABI.
Also, that STACK_FRAME_NON_STANDARD() annotation is broken, this must
not be used for anything that can end up in vmlinux.o -- that is, the
moment you built-in this driver (=y) this comes unstuck.
The reason you're getting warnings is because you're violating the
normal calling convention and scribbling BP, we yelled at the TDX guys
for doing this, now you're getting yelled at. WTF !?!
Please explain how just shutting up objtool makes the unwind work when
the NMI hits your BP scribble?
Returning to a lower VTL treats the base pointer register as a general
purpose one and this VTL transition function makes sure to preserve the
bp register due to which the objtool trips over on the assembly touching
the bp register. We considered this warning harmless and thus we are
using this macro. Moreover NMIs are not an issue here as they won't be
coming as mentioned other. If there are alternate approaches that I
should be using, please suggest.
I now understand that as part of your effort to enable IBT config on
x64, you changed the indirect calls to direct calls in Hyper-V. As of
today, there is no requirement to enable IBT in OpenHCL kernel as this
runs as a paravisor in VTL2 and it does not effect the guest VMs running
in VTL0.
I can disable CONFIG_X86_KERNEL_IBT when CONFIG_MSHV_VTL is enabled in
Kconfig in next version.
All in all, I would suggest fixing this by reverting that patch and
trying again after fixing the calling convention of that hypercall.
Yours grumpy..
Regards,
Naman
