From: Naman Jain <namjain@linux.microsoft.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Peter Zijlstra <peterz@infradead.org>
Cc: Sean Christopherson <seanjc@google.com>,
Roman Kisel <romank@linux.microsoft.com>,
"K . Y . Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
mhklinux@outlook.com
Subject: Re: [PATCH] x86/hyperv: Export hv_hypercall_pg unconditionally
Date: Mon, 6 Oct 2025 19:57:09 +0530 [thread overview]
Message-ID: <9a816666-9d5b-46a4-b35f-2f18c4587ab5@linux.microsoft.com> (raw)
In-Reply-To: <CABgObfZFgHY_ybfSnyzEF1dFr5c1s=_r+tAnHa6Q7rzFUUdt3g@mail.gmail.com>
On 10/6/2025 4:49 PM, Paolo Bonzini wrote:
> On Mon, Oct 6, 2025 at 1:10 PM Peter Zijlstra <peterz@infradead.org> 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
>
next prev parent reply other threads:[~2025-10-06 14:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-25 5:52 [PATCH] x86/hyperv: Export hv_hypercall_pg unconditionally Naman Jain
2025-08-25 9:23 ` Christoph Hellwig
2025-08-25 9:42 ` Peter Zijlstra
2025-08-26 11:30 ` Naman Jain
2025-08-26 12:07 ` Peter Zijlstra
2025-08-26 23:04 ` Roman Kisel
2025-09-16 12:48 ` Paolo Bonzini
2025-09-16 14:52 ` Sean Christopherson
2025-09-18 6:03 ` Naman Jain
2025-09-18 6:47 ` Peter Zijlstra
2025-09-18 14:21 ` James Bottomley
2025-10-06 10:50 ` Naman Jain
2025-10-06 11:10 ` Peter Zijlstra
2025-10-06 11:19 ` Paolo Bonzini
2025-10-06 14:27 ` Naman Jain [this message]
2025-09-15 21:46 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9a816666-9d5b-46a4-b35f-2f18c4587ab5@linux.microsoft.com \
--to=namjain@linux.microsoft.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhklinux@outlook.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=romank@linux.microsoft.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=wei.liu@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox