Re: [Qemu-devel] -cpu behavior (was: [PATCH v3 4/4] target-openrisc: Fix cpu_model by name)

Re: [Qemu-devel] -cpu behavior (was: [PATCH v3 4/4] target-openrisc: Fix cpu_model by name)

[Andreas Färber]

Am 22.07.2013 13:34, schrieb Peter Maydell:
> On 22 July 2013 12:17, Andreas Färber <afaerber@suse.de> 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, but -cpu ? just gave me a segfault. :/
> 
> Odd; that works for me:
> cam-vm-266:precise:qemu$ ./build/x86-all/alpha-softmmu/qemu-system-alpha -cpu ?
> Available CPUs:
>   ev4-alpha-cpu
>   ev5-alpha-cpu
>   ev56-alpha-cpu
>   ev6-alpha-cpu
>   ev67-alpha-cpu
>   ev68-alpha-cpu
>   pca56-alpha-cpu

For -cpu ? I got

Program received signal SIGSEGV, Segmentation fault.
0x00005555557323fa in object_class_dynamic_cast (class=0x55555606df20,
    typename=typename@entry=0x55555582b82e "virtio-scsi-common")
    at /home/andreas/QEMU/qemu/qom/object.c:496
496	    if (type->class->interfaces &&

but that might be related to local QOM patches... :/ confirmed, qom-next
is working fine.

For -cpu ev67-alpha-cpu I got:

0x00005555557af890 in access_with_adjusted_size (addr=addr@entry=1021,
    value=value@entry=0x7fffe73bb5e0, size=size@entry=1, access_size_min=1,
    access_size_max=4, access=access@entry=
    0x5555557afb80 <memory_region_read_accessor>, opaque=opaque@entry=
    0x5555560bd3b0) at /home/andreas/QEMU/qemu/memory.c:429
429	    access_size = MAX(MIN(size, access_size_max), access_size_min);

Seems unrelated and is no longer reproducible either. Hmm.

Andreas

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

Re: [Qemu-devel] -cpu behavior (was: [PATCH v3 4/4] target-openrisc: Fix cpu_model by name)

[Andreas Färber]

Am 22.07.2013 17:38, schrieb Peter Maydell:
> On 22 July 2013 16:25, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> Andreas Färber <afaerber@suse.de> writes:
>>> Am 22.07.2013 13:34, schrieb Peter Maydell:
>>>> 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.
> 
> That doesn't really answer the question of "should the argument
> to -cpu be a QOM typename or a human friendly name?" though
> (though I note none of your -cpu or -device argument examples
> are QOM type names, since they're missing the -$arch-cpu suffix).

Depending on how we register those types, they don't necessarily need an
-$arch-cpu suffix iff they are deemed globally unique. In this case
there would be a 32-bit and 64-bit type though, I guess.

But there's no qemu executable either, so we shouldn't take the example
literally. :P

>> I think this applies equally well to other architecture.
>>  Model hardware more closely.
> 
> For ARM this would mean "don't support -cpu at all, it
> is always hardwired by the board model" :-)

No, it means the board creates the equivalent of -device tegra2-soc. :)
Or exynos4210, highbank-soc or whatever. Less code in machine init, more
code in QOM devices reusable with -M none -readconfig foo.

Andreas

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

Re: [Qemu-devel] -cpu behavior (was: [PATCH v3 4/4] target-openrisc: Fix cpu_model by name)

[Michael Mueller]

We are currently working on a first prototype to support models for s390.
The current model list we want to go with is here:

[mimu@p57lp59 qemu]$ qemu-system-s390x -cpu help
s390 z900       IBM zSeries 900 (Type 2064)
s390 z800       IBM zSeries 800 (Type 2066)
s390 z990       IBM zSeries 990 (Type 2084)
s390 z890       IBM zSeries 890 (Type 2086)
s390 z9-ec      IBM System z9 Enterprise Class (Type 2094)
s390 z9         (alias for z9-ec)
s390 z9-bc      IBM System z9 Business Class (Type 2096)
s390 z10-ec     IBM System z10 Enterprise Class (Type 2097)
s390 z10        (alias for z10-ec)
s390 z10-bc     IBM System z10 Business Class (Type 2098)
s390 z196       IBM zEnterprise 196 (Type 2817)
s390 z114       IBM zEnterprise 114 (Type 2818)
s390 zEC12      IBM zEnterprise EC12 (Type 2827)
s390 host       (same cpu as this host)

Michael