[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC qom-cpu 39/41] target-xtensa: Introduce Xten
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH RFC qom-cpu 39/41] target-xtensa: Introduce XtensaCPU subclasses |
Date: |
Sun, 07 Jul 2013 20:51:26 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 |
Am 06.07.2013 21:54, schrieb Max Filippov:
> On Sat, Jul 6, 2013 at 11:12 PM, Andreas Färber <address@hidden> wrote:
>> Am 06.07.2013 20:39, schrieb Max Filippov:
>>> ...and maybe a stupid question, but why moving configuration pointer away
>>> from env and then changing every place that used to access it?
>>
>> Xtensa is the only target trying to implicitly access an "env" variable
>> through a macro to obtain the number of registers for gdbstub. That's
>> what I'm trying to fix with 40/41 in order to get rid of the #ifdeffery.
>>
>> The number of registers is not accessed by TCG, so it could go into
>> XtensaCPU instead of CPUXtensaState.
>> Further it does not change during vCPU runtime, so it no longer belongs
>> in CPUXtensaState nor XtensaCPU but in XtensaCPUClass, which is shared
>> among CPU cores and can be accessed statically.
>
> I'm concerned about two things here: adding boilerplate code to access
> CPU class and doing more work at runtime than just following a pointer.
> I mean that env->config is almost always used together with env itself,
> could we consider env->config to be a cache for xcc->config?
xtensa_env_get_cpu() after the recent patch in my queue no longer does a
cast, thus it's dirt cheap to switch between CPUXtensaState and
XtensaCPU (and back via ->env).
The ObjectClass is a pointer in Object, just like your XtensaConfig in
CPUXtensaState. Anthony has added a cast cache for v1.5 and Paolo a
configure option to turn cast checks off.
That leaves declaring an extra variable.
But since this is orthogonal to my gdbstub cleanups, v2 just initializes
env->config in XtensaCPU's instance_init, to keep the patch small while
keeping cpu_init() free of non-QOM initializations.
Anything else can be done later in an xtensa-only series.
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