On Wed, Jul 13, 2016 at 05:46:25PM +0200, Igor Mammedov wrote: > On Wed, 13 Jul 2016 17:26:18 +0200 > Igor Mammedov <imamm...@redhat.com> wrote: > > > On Wed, 13 Jul 2016 12:04:44 -0300 > > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > > > On Wed, Jul 06, 2016 at 08:20:53AM +0200, Igor Mammedov wrote: > > > > Signed-off-by: Igor Mammedov <imamm...@redhat.com> > > > > --- > > > > target-i386/cpu.c | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/target-i386/cpu.c b/target-i386/cpu.c > > > > index 04c0b79..2fa445d 100644 > > > > --- a/target-i386/cpu.c > > > > +++ b/target-i386/cpu.c > > > > @@ -2765,6 +2765,7 @@ static void x86_cpu_apic_create(X86CPU *cpu, > > > > Error **errp) > > > > > > > > object_property_add_child(OBJECT(cpu), "lapic", > > > > OBJECT(cpu->apic_state), &error_abort); > > > > + object_unref(OBJECT(cpu->apic_state)); > > > > > > What kind of event can trigger object_unparent() or > > > object_del_property() on "lapic"? Can we guarantee that the child > > > property will never be deleted by any other code, only by > > > x86_cpu_unrealizefn() and object_finalize(cpu)? > > code path that triggers unparent of lapic implicitly is > > cpu instance removal when it deletes all children. > > > > So unless someone adds explicit lapic removal somewhere in target-i386/cpu.c > Well, I've wrote nonsense here as I do remove child explicitly > in x86_cpu_unrealizefn(), so it's fine to set cpu->apic_state to NULL > as you suggest in 18/19. > > The other way around might be call only apic_state->unrealize() explicitly > from x86_cpu_unrealizefn() and let QOM do unparenting/finalizing > automatically for us. I'd even prefer this one over the former. > Which one would you prefer?
I'd prefer to delete the object on unrealize, because it is created on realize. > > > I don't see how it could be deleted by other code path. > That point still stands. I don't see it, either, but I was not 100% sure it was not possible to trigger property removal from other code paths (e.g. QMP commands). If you are sure it can't be triggered: Reviewed-by: Eduardo Habkost <ehabk...@redhat.com> -- Eduardo
