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

[Igor Mammedov]

On Fri, Jun 08, 2012 at 11:11:11AM +0200, Andreas Färber wrote:
> Am 08.06.2012 10:20, schrieb Igor Mammedov:
> > On Wed, May 23, 2012 at 05:07:27AM +0200, Andreas Färber wrote:
> 
> This is touching on a core QOM question: Can we link<> during initfn?
> That's what you're trying to do for the APIC and why this may be too
> late in your case. I believe the answer to that question must be no.
Yep, it's more of general question.
Potentially any property could be set in initfn to intialize
defaults and a property setter could create a link causing chicken/egg
conflict.
If making link<> to object is not permited till its initfn is done then
when it is permited to be made?
Maybe object_new() should take parent as parameter or maybe due to limitation
we should revise purpose of link<>s /if they are replacement of ptr properties/?

[...] 
> Another factor that is making this slightly difficult is that there are
> three APIC subclasses. Currently they all have an instance_size of
> sizeof(APICCommonState) so it could be created in-place if it actually
> is a part (child<>) of the CPU wrt hot-plug. Creating objects with
> object_new() in QOM instance_init is forbidden.
Any particular reason why object_new() in intifn is not acceptable?

> 
[...]
> 
> Maybe this CPU hot-plug business would be a good topic for a KVM call?
It's more that I'm unhappy about wrong cpu creation order in pc_new_cpu()
at the present code. For hotplug qdev_device_add makes new object as 
a child<> when it's created and it just needs to be placed before other
properties are set.

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