On Tue, Oct 18, 2016 at 02:36:10PM +0200, Igor Mammedov wrote:
> On Tue, 18 Oct 2016 08:56:28 -0200
> Eduardo Habkost <ehabk...@redhat.com> wrote:
> 
> > On Thu, Oct 13, 2016 at 11:52:40AM +0200, Igor Mammedov wrote:
> > > ACPI ID is 32 bit wide on CPUs with x2APIC support.
> > > Extend 'id' property to support it.
> > > 
> > > Signed-off-by: Igor Mammedov <imamm...@redhat.com>
> > > ---
> > > v3:
> > >    keep original behaviour where 'id' is readonly after
> > >    object is realized (pbonzini)
> > > ---  
> > [...]
> > > diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
> > > index 8d01c9c..30f2af0 100644
> > > --- a/hw/intc/apic_common.c
> > > +++ b/hw/intc/apic_common.c
> > > @@ -428,7 +429,6 @@ static const VMStateDescription vmstate_apic_common = 
> > > {
> > >  };
> > >  
> > >  static Property apic_properties_common[] = {
> > > -    DEFINE_PROP_UINT8("id", APICCommonState, id, -1),
> > >      DEFINE_PROP_UINT8("version", APICCommonState, version, 0x14),
> > >      DEFINE_PROP_BIT("vapic", APICCommonState, vapic_control, 
> > > VAPIC_ENABLE_BIT,
> > >                      true),
> > > @@ -437,6 +437,49 @@ static Property apic_properties_common[] = {
> > >      DEFINE_PROP_END_OF_LIST(),
> > >  };
> > >  
> > > +static void apic_common_get_id(Object *obj, Visitor *v, const char *name,
> > > +                               void *opaque, Error **errp)
> > > +{
> > > +    APICCommonState *s = APIC_COMMON(obj);
> > > +    int64_t value;
> > > +
> > > +    value = s->apicbase & MSR_IA32_APICBASE_EXTD ? s->initial_apic_id : 
> > > s->id;
> > > +    visit_type_int(v, name, &value, errp);
> > > +}  
> > 
> > Who exactly is going to read this property and require this logic
> > to be in the property getter?
> As it's set/read only from CPU we don't actually have to expose it
> as property.
> However, I've kept it as read/write property because it has already
> been this way and been exposed to external users as some magic property.
> Not sure is anyone cares.
> 
> 
> > Do we really need to expose this to the outside as a magic
> > property that changes depending on hardware state? Returning
> > initial_apic_id sounds much simpler.
> Well that's what it is now, so I've kept current behavior.
> If we decide to change property behavior or drop it altogether
> I can do it on top.
> 

I agree to make them static properties as follow-up patch. This
way, if the change breaks anything we can revert only that patch.

-- 
Eduardo

Reply via email to