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 <a...@ozlabs.ru> >> >> LGTM. Andreas, do you agree? > > > Ping?
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? Regards, Andreas -- 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)
