[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH] target-ppc: Register CPU class per family o
Re: [Qemu-devel] [RFC PATCH] target-ppc: Register CPU class per family only when needed
Mon, 16 Mar 2015 11:40:29 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
Am 16.03.2015 um 05:58 schrieb Alexey Kardashevskiy:
> On 03/06/2015 12:17 AM, Alexander Graf wrote:
>> On 05.03.15 02:56, Alexey Kardashevskiy wrote:
>>> At the moment when running in KVM mode, QEMU registers "host" class to
>>> match the current CPU PVR value. It also registers another CPU class
>>> with a CPU family name os if we run QEMU on POWER7 machine, "host" and
>>> "POWER7" classes are created, this way we can always use "-cpu POWER7"
>>> on the actual POWER7 machine.
>>> The existing code uses DeviceClass::desc field of the CPU class as
>>> a source for the class name; it was pointed out that it is wrong to use
>>> user-visible string as a type name.
>>> This adds a common CPU class name into PowerPCCPUClass struct.
>>> This makes registration of a CPU named after the family conditional -
>>> PowerPCCPUClass::common_cpu_name has to be non-zero. Only POWER7/POWER8
>>> families have this field initialized by now.
>>> Signed-off-by: Alexey Kardashevskiy <address@hidden>
>> LGTM. Andreas, do you agree?
No, I don't agree. Inventing a new class field just to distinguish
POWER7/POWER8 here seems like a weird idea, and the code placement is
not fixed either.
I gathered that you want -cpu POWER7 and -cpu POWER8 to work on POWER8
hardware and -cpu POWER7 on POWER7, for migration purposes, correct?
What exact PVRs have you tested on and why does it not work without
those types despite the PVR masking? To investigate I need a test case.
Is this just a question of the generic family type being abstract and
needing an updated PVR value? Which other fields are actually used?
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)