Re: [PATCH 16/34] target/i386/mshv: migrate LAPIC state

[Magnus Kulke <magnuskulke@linux.microsoft.com>]

On Fri, Apr 17, 2026 at 01:54:48PM +0200, Mohamed Mediouni wrote:
> 
> 
> > On 17. Apr 2026, at 12:56, Magnus Kulke <magnuskulke@linux.microsoft.com> wrote:
> > 
> > This change implements loading and storing the hyperv lapic state as
> > part of the load/store routines for a vcpu.
> > 
> > The HyperV LAPIC is similar to the the split-irqchip in KVM, it will
> > only handle MSI/X interrupts. PIC and IOAPIC have to be handled in
> > userland.
> > 
> > An opaque blob is added to the APICCommonState, guarded behind a flag,
> > hence it will be covered by a migration, as we declare VMSTATE_BUFFER
> > for the hv_lapic_state field.
> > 
> > In the future we might want to introduce a dedicated class for MSHV, that
> > would require us to wire up an IOAPIC delivery path to QEMU's userland
> > emulation.
> > 
> > Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
> 
> Hi,
> 
> Is there a way to make this not opaque in a way that retains the ability to
> Save-restore between KVM and MSHV? 
> 
> Or is that not a wanted goal?
> 

as we discussed offline: there is mapping code in the mshv-ioctls
crate and some prior art in WHPX that we can use as a reference. So
we are to able to roundtrip the lapic state using generic field on
APICCommonState and a few additional mshv-specific fields. This seems
to work reliably in my migration tests.

I'll update this in the next iteration of this series. A KVM <=> MSHV
migration path remains a non-goal, but it'll be a bit nicer to have the
state transparent in the migration stream.

best,

magnus