Re: [Qemu-devel] [PATCH 5/5] arm: SoC model for Calxeda Highbank

[Andreas Färber]

Am 07.01.2012 10:55, schrieb Igor Mitsyanko:
> On 06.01.2012 11:11 PM, Andreas Färber wrote:
>> Am 06.01.2012 20:10, schrieb Igor Mitsyanko:
>>> On 01/06/2012 10:45 PM, Peter Maydell wrote:
>>>> On 6 January 2012 18:37, Igor Mitsyanko<address@hidden>   wrote:
>>>>> On 01/06/2012 12:02 AM, Mark Langsdorf wrote:
>>>>>> +    if (!cpu_model) {
>>>>>> +        cpu_model = "cortex-a9";
>>>>>> +    }
>>>>>
>>>>>
>>>>> Google said there is only cortexA9-based Highbank SoC version,
>>>>> maybe you
>>>>> should just hardcode cpu model?
>>>>
>>>> This is just boilerplate code for any random ARM board at the moment:
>>>> it defaults the CPU but lets the user override. We should either make
>>>> a decision to do something else for all boards, or follow the usual
>>>> convention here; I'm happy to do the latter.
>>>>
>>>
>>> Are you saying that it's a mistake that we hardcoded cpu model and
>>> memory size for Exynos boards in our patches?
>>
>> No machine should silently change the user's -cpu to something else.
>> Either error out or warn the user, or let them face the consequences of
>> their parameters themselves.
> 
> Machines do not instantiate cpus, they instantiate SoC models,

Currently, the machine does instantiate both CPU and devices, including
those on the SoC.

> which are
> solid (not modular) devices with explicitly specified (in datasheet or
> elsewhere) cpu core and peripheral devices, and if someone creates
> Highbank SoC instance with Cortex-M4 CPU core then it's no longer a
> Highbank SoC.

I somewhat agree that changing the CPU of an SoC should not be allowed,
if we make it easy enough to derive SoCs with another core. (You will
find further discussions of child<> vs. link<> in the qemu-test thread,
I think.)

Not having SoCs yet, -cpu roughly corresponds to exchanging
device-compatible SoCs on the board. With machine and SoC both called
Highbank here, that's kind of confusing.

One reason to allow -cpu (and -device) is to avoid for us getting
swamped with machines.

>> Not sure how hardcoding the cpu_model would work with CPU features,
>> would they be still included or stripped out before. Peter?
>>
> 
> What do you mean? All features are currently set during
> cpu_reset_model_id() as far as I know, it doesn't matter whether
> cpu_model was specified on command line or hardcoded into initialization
> code.

This again is referring to discussions of upcoming changes elsewhere.

Currently, ARM CPU reset derives CPU features from the CPUID in turn
derived from the CPU name. Peter wants to allow turning ARM CPU features
on and off like for i386, decoupling this from CPUID.

Of course we can always change things back and forth, but I usually
prefer future-proof solutions. :)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg