Re: [PATCH 3/3] KVM: VMX: Rename posted interrupt prefixes from "vmx" to "vt"

Sean Christopherson <[email protected]>
Newsgroups dev.linux.lists.sashiko-reviews,org.kernel.vger.kvm
Message-ID <[email protected]>
On Mon, Aug 17, 2026, Xiaoyao Li wrote:
> On 8/15/2026 1:02 AM, Sean Christopherson wrote:
> > On Fri, Aug 14, 2026,[email protected] wrote:
> > > Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> > > - [Low] The function `vmx_needs_pi_wakeup()` was not renamed to `vt_needs_pi_wakeup()`.
> > > - [Low] The shared inline API `__vmx_deliver_posted_interrupt()` was not renamed to `__vt_deliver_posted_interrupt()`.
> > > - [Low] A comment inside `vt_can_use_vtd_pi()` references the old `vmx_pi_start_bypass()` function name.
> > > --
> > I also missed vmx_handle_nmi() and __vmx_handle_ept_violation().
> 
> So for TDX VMDoS series, I need to rename __vmx_handle_notify() to
> vt_handle_notify() and extract handle_bus_lock_vmexit() from vmx.c to main.c
> as vt_handle_bus_lock_vmexit() or just inline function in common.h?

Yes please.  Though I think it probably makes sense to go with __vt_handle_notify()
to capture that it's an inner helper?  E.g. that's my plan for
__vt_handle_ept_violation().

Regardling handle_bus_lock_vmexit(), put it in main.c.  to_vt() currently lives
in vmx.h, which means it's impossible to inline vt_handle_bus_lock_vmexit() in
common.h because it can't get from "struct kvm_vcpu *vcpu" to "struct vcpu_vt *vt"
to update exit_reason.bus_lock_detected.

v2 of this series will address that (I coded everything up and tested it all last
week, just need to post it), but (a) juggling those dependencies isn't your
responsibility and (b) we don't want to take a dependency on the cleanups for a
fix that is destined for stable@.

Then I'll do one of three things: post a new version of this series to move
vt_handle_bus_lock_vmexit() to common.h, post a standalone patch to do the same,
or simply leave it in main.c (it's going to require a non-inline implementation
for at VMX since it's wired up to a function table, and it should be a rare path
so inlining for performance reasons is a non-goal).

Thanks!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.