Re: [Qemu-devel] [PATCH qom-next 04/59] pc: Add CPU as /machine/cpu[n]

[Igor Mammedov]

On Fri, Jun 08, 2012 at 12:36:18PM +0200, Andreas Färber wrote:
> Am 08.06.2012 12:21, schrieb Jan Kiszka:
> > On 2012-06-08 11:11, Andreas Färber wrote:
> >> >From what I understand about the x86 modeling, the only case this
> >> matters is if you hot-unplug CPU 0, right? Question is, what happens
> >> with the APIC then? I would guess the remaining n-1 CPUs still want to
> >> access the APIC
> > 
> > APICs are per-CPU, each has its own.
> 
> Uh, seems I'm seriously confusing APIC with something else then...
> 
> Anyway, if each CPU always has its own APIC there's no reason to link<>
> them. It should be a child<> and it should be initialized in-place.
in [5/59] you create a back_link<> from APIC to parent cpu to replace cpu_env
pointer (i.e. something that could be ptr property). And from what I've read
link<> is kind of strong typed replacement for ptr properties, correct me if I 
wrong.
So having link<> there should be ok, except of that CPU should have parent 
before
it will set back_link<> "cpu" in APIC.

> 
> Igor, can you please look into that?
Sure, Could you point to an example of creating a QOMified object in place, 
please?

> 
> In that case the only open issue would be whether to use cpu_index or
> the APIC ID as the property name in this patch.
not only, cpu_x86_init() now represents create/set_props/realize sequence
and making cpu a child after set_props/realize is wrong. But if cpu_x86_init() 
were
replaced by its contents in pc_new_cpu and CPU were made a child right after
object_new(X86CPU) then problem would be avoided. and the rest of properties 
(including APIC)
could be set after that and at the end realizefn() is called.

> 
> Andreas
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>