Re: [Qemu-devel] [PATCH RFC qom-cpu-next] apic: QOM'ify APICCommonState casts

[Jan Kiszka]

On 2013-04-28 15:53, Andreas Färber wrote:
> Am 28.04.2013 15:03, schrieb Jan Kiszka:
>> On 2013-04-28 13:22, Andreas Färber wrote:
>>> Necessary to change the name of ICCDevice's parent object field.
>>>
>>> Signed-off-by: Andreas Färber <address@hidden> --- Could any of
>>> the APIC experts please review whether I'm touching any hot
>>> path? Not sure if this was a mix of pre- and post-QOM code or
>>> intentional... Thanks.
> 
>> How "hot" does it have to be before we notice the type check
>> overhead? Did anyone already measure this, given that they are
>> getting very common now?
> 
> Heh, if I had a conclusive benchmark I wouldn't ask. ;)

Do object_class_dynamic_cast & friends show up higher in profiling
results when using your patch with an emulated APIC?

> 
> In general init, reset and MMIO were considered cold paths in this
> regard. Timer and interrupt code paths by contrast I've usually tried
> to spare.

...but not in this patch. There are things like "deliver",
"get_interupt", "accept", and the APIC MMIO handlers are stressed at
least once per IRQ as well (EOI). When emulating in userspace.

> 
>> But none of the touched functions are used during normal operation
>> when the KVM APIC is active. With emulated APIC, they are
>> frequently used, of course.
> 
> Where in doubt, we could just use (APICCommonState *) or a macro
> hiding that.

Actually, I would prefer making the typical type check (class up- and
down-casts) so light-weight that we do not have to worry. Something that
ideally boils down to comparing two magic numbers inline.

Jan

signature.asc
Description: OpenPGP digital signature