> On 2. Jul 2026, at 13:47, Paolo Bonzini <[email protected]> wrote:
>
>
>
> Il gio 2 lug 2026, 11:49 Magnus Kulke <[email protected]> ha
> scritto:
> On Thu, Jul 02, 2026 at 10:51:35AM +0200, Paolo Bonzini wrote:
>
> > What are the additional fields that aren't covered (i.e. cannot be copied
> > from hv_lapic_state to the struct and back) by the common APIC state?
> >
>
> that would be those:
>
> uint32_t apic_version;
> uint32_t apic_lvt_lint0;
> uint32_t apic_lvt_lint1;
> uint32_t apic_lvt_cmci;
> uint32_t apic_error_status;
> uint32_t apic_counter_value;
> uint32_t apic_remote_read;
>
> Reference struct is this: hv_local_interrupt_controller_state
>
> https://gitlab.com/qemu/qemu/-/blob/master/include/hw/hyperv/hvgdk_mini.h
>
> For anything that's new but part of the standard APIC you can place them in
> common APIC state, just making migration state part of a subsection.
>
> Notably we have to do this for lvt_lint0+1. We cannot use the respective
> fields in the common APIC state, because writing to those has a side effect
> in QEMU: If unmasked, it will trigger a chain of events,
>
> pic_irq_request() => apic_accept_pic_intr() => apic_deliver_pic_intr()
>
> For MSHV (and WHPX afaiu) we're currently not able to trigger legacy
> interrupts from userspace in this fashion.
>
> What is the issue? The interrupt won't be triggered either if you use a
> separate field, or if you use the normal one.
Hi,
For injecting LINT0, it’s possible on modern WHPX when using the hw irqchip
- starting from Server 2022/Windows 11 only - not before that point.
How it’s done is though cancelling the vCPU execution, wait until the vm exits
as a result, set an interrupt window, run the vCPU again and then when it exits
Manually injecting an event…
That’s unlike non-legacy interrupts where the request interrupts path actually
works on Hyper-V.
>
> For LINT1, can you not inject an NMI either?
The request interrupt path works at least to some extent on LINT1/NMIs unlike
LINT0
but didn’t dig deeper to see if it has more issues…
I’m convinced that an Hyper-V specific structure is the wrong idea for this
though...
>
> Thanks,
>
> Paolo
>
> Hence we roundtrip
> lint0/lint1 in a dedicated mshv struct.
>
> best,
>
> magnus
>
