Marcelo Tosatti wrote: > Otherwise a zero apic base is loaded into KVM, which results > in interrupts being lost until a proper apic base with enabled > bit set is loaded. > > Fixes WinXP migration in qemu-kvm origin/next. > > Signed-off-by: Marcelo Tosatti <mtosatti@xxxxxxxxxx> > > diff --git a/hw/apic.c b/hw/apic.c > index 627ff98..45a4d2b 100644 > --- a/hw/apic.c > +++ b/hw/apic.c > @@ -1131,6 +1131,11 @@ int apic_init(CPUState *env) > vmstate_register(s->idx, &vmstate_apic, s); > qemu_register_reset(apic_reset, s); > > + /* apic_reset must be called before the vcpu threads are initialized and load > + * registers, in qemu-kvm. > + */ > + apic_reset(s); > + > local_apics[s->idx] = s; > return 0; > } Heals the issue I saw with Win2003 Server as well. Looks all a bit messy though. Hope we can establish a more regular and less fragile model on the midterm. I wonder if it wouldn't be better to do write-back of the local APIC state along with the register state on vmrun (and only there!). The same would apply to things like mpstate, TSC MSR, or the guest debugging state. The reset/vmloading/hw-emulation code would only declare what kind of write-back it wishes: register state only, partial (excluding everything that touches continuously running timers), full. Well, basically the model I suggested for proper mpstate write-back, just even more generalized. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html