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

[Anthony Liguori]

Andreas Färber <address@hidden> writes:

> 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. ;)

That's pretty gross, but yes, we should have:

qemu -device Xeon-E5-4610,id=sock0 -device Xeon-E5-4610,id=sock1

Which effectively does:

qemu -cpu SandyBridge -smp cores=6,threads=2,sockets=2

By today's standards.

I think this applies equally well to other architecture.  Model hardware
more closely.

Regards,

Anthony Liguori

>
> 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