[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: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name |
Date: |
Mon, 22 Jul 2013 12:39:31 -0500 |
User-agent: |
Notmuch/0.15.2+202~g0c4b8aa (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) |
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
- Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name, (continued)
- Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name, Jia Liu, 2013/07/22
- Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name, Andreas Färber, 2013/07/22
- Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name, Peter Maydell, 2013/07/22
- Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name, Andreas Färber, 2013/07/22
- Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name, Peter Maydell, 2013/07/22
- Re: [Qemu-devel] -cpu behavior (was: [PATCH v3 4/4] target-openrisc: Fix cpu_model by name), Andreas Färber, 2013/07/22
- Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name, Andreas Färber, 2013/07/22
- Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name, Anthony Liguori, 2013/07/22
- Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name, Peter Maydell, 2013/07/22
- Re: [Qemu-devel] -cpu behavior (was: [PATCH v3 4/4] target-openrisc: Fix cpu_model by name), Andreas Färber, 2013/07/22
- Re: [Qemu-devel] [PATCH v3 4/4] target-openrisc: Fix cpu_model by name,
Anthony Liguori <=