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: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name
Date: Mon, 22 Jul 2013 16:38:36 +0100

On 22 July 2013 16:25, Anthony Liguori <address@hidden> wrote:
> Andreas Färber <address@hidden> 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).

> 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" :-)

-- PMM



reply via email to

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