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 <[email protected]>
>>
>> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
