Peter Xu <pet...@redhat.com> wrote: > Migration is silently broken now with x2apic config like this: > > -smp 200,maxcpus=288,sockets=2,cores=72,threads=2 \ > -device intel-iommu,intremap=on,eim=on > > After migration, the guest kernel could hang at anything, due to > x2apic bit not migrated correctly in IA32_APIC_BASE on some vcpus, so > any operations related to x2apic could be broken then (e.g., RDMSR on > x2apic MSRs could fail because KVM would think that the vcpu hasn't > enabled x2apic at all). > > The issue is that the x2apic bit was never applied correctly for vcpus > whose ID > 255 when migrate completes, and that's because when we > migrate APIC we use the APICCommonState.id as instance ID of the > migration stream, while that's too short for x2apic. > > Let's use the newly introduced initial_apic_id for that. > > Signed-off-by: Peter Xu <pet...@redhat.com> > --- > hw/intc/apic_common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c > index aafd8e0e33..6024a3e06a 100644 > --- a/hw/intc/apic_common.c > +++ b/hw/intc/apic_common.c > @@ -315,7 +315,7 @@ static void apic_common_realize(DeviceState *dev, Error > **errp) > APICCommonState *s = APIC_COMMON(dev); > APICCommonClass *info; > static DeviceState *vapic; > - int instance_id = s->id; > + int64_t instance_id = s->initial_apic_id;
int is ok here. But damn thing, initial_apic_id is uint32_t. Sniff. Later, Juan.
