On Wed, Dec 09, 2009 at 08:00:41PM +0100, Jan Kiszka wrote: > Glauber Costa wrote: > > On Wed, Dec 09, 2009 at 03:46:54PM -0200, 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); > >> + > > But by doing this, the system-wide reset will re-reset the apic, possibly losing > > some other information. > > > > Also, system_reset happens before we signal system_ready (or at least should). > > This means the vcpus should not be running and producing anything useful yet. > > So how does it happen, in the first place? > > There is > > kvm_arch_load_regs(env); > > before qemu_cond_wait in ap_main_loop. Probably part of the reason. Why > is it there? Hum ... see how qemu_kvm_load_lapic depends on kvm_vcpu_inited. kvm_vcpu_ioctl_set_lapic -> kvm_apic_post_state_restore relies on proper apicbase set (maybe other reasons too). -- 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
