On 11/11/22 10:15, Peter Zijlstra wrote:
I don't speak virt (but this all sounds disguisting)
Yes, it is. AMD does not need this, they just hold onto the interrupt
until the host has issued both STGI (for NMIs) and STI (for IRQs).
On Intel you can optionally make it hold onto IRQs, but NMIs are always
eaten by the VMEXIT and have to be reinjected manually.
-- but what appears to be the case is you calling into entry code
from regular kernel context, which is odd at best.
Specifically, going by the fact that all this is not noinstr code,
the assumption is that RCU/lockdep/etc.. is all set-up and running.
Indeed it is. This is called long after the noinstr area has been left:
vcpu_enter_guest
...
static_call(kvm_x86_vcpu_run) -> vmx_vcpu_run
vmx_vcpu_enter_exit (noinstr)
guest_state_enter_irqoff
__vmx_vcpu_run
guest_state_exit_irqoff
...
static_call(kvm_x86_handle_exit_irqoff) -> vmx_handle_exit_irqoff
handle_external_interrupt_irqoff
...
Paolo
This means you should not be calling DEFINE_IDTENTRY_*(func)
functions because those will try and set all that up again.
Granted, irqentry_{enter,exit}() do nest, but*yuck*.
