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? 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
