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 >
