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

[Anthony Liguori]

Peter Maydell <address@hidden> writes:

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

They shouldn't be different things IMHO.

> 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'm not sure the rationale of $arch-cpu but I think having a forced
suffix is a bad idea.

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

Is that a bad thing?

I really hate the -cpu option.  I hope it dies a horrible bitrotten
death over time once -device can be used to replace it.

Regards,

Anthony Liguori

>
> -- PMM