[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/5] target-i386: call x86_cpu_realize() after A

From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH 3/5] target-i386: call x86_cpu_realize() after APIC is initialized.
Date: Thu, 21 Jun 2012 11:43:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

On 06/20/2012 03:35 PM, Andreas Färber wrote:
Am 20.06.2012 14:59, schrieb Igor Mammedov:
It's not correct to make CPU runnable (i.e. calling x86_cpu_realize())
when not all properties are set (APIC in this case).

Fix it by calling x86_cpu_realize() at board level after APIC is
initialized, right before cpu_reset().

Signed-off-by: Igor Mammedov <address@hidden>
  hw/pc.c              |    1 +
  target-i386/helper.c |    2 --
  2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 8368701..8a662cf 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -948,6 +948,7 @@ static X86CPU *pc_new_cpu(const char *cpu_model)
          env->apic_state = apic_init(env, env->cpuid_apic_id);
      qemu_register_reset(pc_cpu_reset, cpu);
+    x86_cpu_realize(OBJECT(cpu), NULL);
      return cpu;
diff --git a/target-i386/helper.c b/target-i386/helper.c
index c52ec13..b38ea7f 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -1161,8 +1161,6 @@ X86CPU *cpu_x86_init(const char *cpu_model)
          return NULL;

-    x86_cpu_realize(OBJECT(cpu), NULL);
      return cpu;

This will require changes in linux-user and possibly bsd-user. Having a
Why it would require changes in linux-user? So far x86_cpu_realize() does
nothing useful in linux-user,  compiled and tested. It should be harmless
for linux-user not to execute it.
But I haven't compiled/tested bsd-user, do I need BSD for this?

cpu_realize() would probably help with avoiding #ifdef'ery.
Unfortunately deriving CPUState from DeviceState proves a bit difficult
in the meantime (it worked at one point, now there's lots of circular
header dependencies), and realize support for Object got stopped.
I'm in process of untangling this header mayhem (at least to a point
that allows compilation complete when CPU is derived from Device)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]