qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]