qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name
Date: Mon, 22 Jul 2013 14:33:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7

Am 22.07.2013 13:34, schrieb Peter Maydell:
> On 22 July 2013 12:17, Andreas Färber <address@hidden> wrote:
>> Am 22.07.2013 12:40, schrieb Peter Maydell:
>>> In any case we should be
>>> consistent across target architectures about what we allow.
>>
>> alpha allows both
[...]
>> It didn't have -cpu ? before QOM, so we decided to print the type names
>> there.
> 
> Looking at all of the '-cpu help' output, alpha seems to be
> the odd one out here: none of the others list valid CPUs
> with "-$arch-cpu" suffixes.

Right, because all others had implemented -cpu ? before we introduced
that naming scheme and I tried to keep output compatibility for them.
Focus for alpha was therefore on -cpu foo compatibility only.

Anthony had clearly stated on a KVM call that using full type names for
future CPU hot-add was the right thing to do and possibly even composite
convenience types like 4core-xeonblabla-x86_64-cpu; how that relates to
-cpu and new targets was never clearly defined though. ;)

For VMSD we decided to deviate for new migratable targets from legacy
CPUs in favor of consistency with devices, for instance.

>> Stripping -alpha-cpu off typenames would surely be possible.
> 
> I think that that would be better in the name of consistency.

> Also regarding consistency, not all targets react very well
> to being asked for a nonexistent cpu via "-cpu xyzzy":
>  alpha and s390x just plough on without an error

s390x does not have models yet. This will get fixed once we have agreed
on model names and their implementation.

>  lm32 and unicore32 segfault
> 
> (some of this may be default board model bugs rather than
> target-* bugs).

Yeah, for one sh4 board where I noticed it while refactoring I already
applied an error check. I guess cpu_init() / cpu_*_init() is not
NULL-checked in more machines. Not sure if trying invalid arguments
would be applicable for a qtest?

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]