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

Khushit Shah
2025-09-09T10:34:21Z

Thank you for the pointers, Vitaly!

> On 8 Sep 2025, at 5:12 PM, Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
>
>> Thanks you for the comments Vitaly!
>>
>>> On 8 Sep 2025, at 2:35 PM, Vitaly Kuznetsov <vkuznets@redhat.com> 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@redhat.com>
> 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