Re: [BUG] [KVM/VMX] Level triggered interrupts mishandled on Windows w/ nested virt(Credential Guard) when using split irqchip

[Khushit Shah]

Thank you for the pointers, Vitaly!

> On 8 Sep 2025, at 5:12 PM, Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> wrote:
> 
>> Thanks you for the comments Vitaly!
>> 
>>> On 8 Sep 2025, at 2:35 PM, Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> wrote:
>>> 
>>> Is there a specific reason to not enable any Hyper-V enlightenments for
>>> your guest? For nested cases, features like Enightended VMCS
>>> ('hv-evmcs'), 'hv-vapic', 'hv-apicv', ... can change Windows's behavior
>>> a lot. I'd even suggest you start with 'hv-passthrough' to see if the
>>> slowness goes away and if yes, then try to find the required set of
>>> options you can use in your setup.
>> 
>> 
>> Actually in production we use an extensive set of cpu features exposed to the guest, still the issue persists, 
>> With the following hv-* options also the issue is present:
>>       hypervisor=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x2000,hv-vpindex=on,hv-runtime=on,hv-synic=on, 
>>       hv-stimer=on,hv-tlbflush=on,hv-ipi=on,hv-evmcs=on
>> 
> 
> Try adding 'hv-apicv' (AKA 'hv-avic') to the list too (not to be
> confused with 'hv-vapic’)


I tried with hv-apicv=on, the issue still persists. 

> Oh, this is next level) Do you know if the issue reproduces with newer
> Windows, e.g. 2025?

The latest I can try on is Win11 24H2, I will try and update here.

> Also, I've just recalled I fixed (well, 'workarounded') an issue similar
> to yours a while ago in QEMU:
> 
> commit 958a01dab8e02fc49f4fd619fad8c82a1108afdb
> Author: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
> Date:   Tue Apr 2 10:02:15 2019 +0200
> 
>    ioapic: allow buggy guests mishandling level-triggered interrupts to make progress
> 
> maybe something has changed and it doesn't work anymore?

This is really interesting, we are facing a very similar issue, but the interrupt storm only occurs when using split-irqchip. 
Using kernel-irqchip, we do not even see consecutive level triggered interrupts of the same vector. From the logs it is 
clear that somehow with kernel-irqchip, L1 passes the interrupt to L2 to service, but with split-irqchip, L1 EOI’s without 
servicing the interrupt. As it is working properly on kernel-irqchip, we can’t really point it as an Hyper-V issue. AFAIK, 
kernel-irqchip setting should be transparent to the guest, can you think of anything that can change this?

Regards,
Khushit