Am 16.08.2013 02:20, schrieb Benjamin Herrenschmidt: > On Thu, 2013-08-15 at 16:47 +0200, Andreas Färber wrote: >> When we instantiate a -cpu POWER9 then having one POWER9_vX.Y around to >> back it doesn't really hurt. Unlike ARM's MIDR there doesn't seem to be >> an encoding of IBM vendor or POWER family in the PVR. The macros and >> their new implementation are not the way they are because I consider >> them the nicest thing in the world but because the name+pvr+svr+family >> combination made them work for the whole zoo of models we carry around >> and started to give us some inheritance through QOM. Making the POWER7 >> family non-abstract would require the same kind of macro "overloading" >> for POWERPC_FAMILY that I'm trying to contain for POWERPC_DEF ATM. So >> what I am still thinking about is how to handle there being multiple >> matches for a PVR - I am considering putting them into a list and >> comparing values for closest match. So that if you have a v2.4 and QEMU >> knows v2.1 and v2.3 we take v2.3 and fill in the v2.4 PVR. > > Another thing to keep in mind is that we will want eventually to support > POWER7 compatibility more on POWER8 with HV KVM. I am not certain what > the "right" way to do it via qemu command line is, whether we would > have a -cpu entry (-cpu POWER7_COMPAT ?) or such...
There is precedence in having a POWER6_5 model for POWER6 in POWER5 mode, but that is not fully implemented. Not saying that's how it needs to be done for POWER8. Question is, when the host is POWER8 in POWER7 mode, should the -cpu host guest be POWER8 in POWER7 mode or POWER7 or possibly even POWER8? That question influences whether a simple mask does the job or whether we need an am-I-compatible-with-this-host callback on the CPUClasses. > Additionally, the trick here is that qemu must be able to change its model > at runtime (a reset is permitted). This is how PAPR defines the > reconfiguration > reboot (for that and other things). > > IE. The guest kernel will call FW early on, while still operating under > OFW (from prom_init) indicating what it supports, and if that doesn't include > P8, we need to reconfigure the CPU model to be P7 compat (we are allowed to > reboot and reload the same kernel, which is generally what pHyp does, but > we'd like to try avoiding it as much as possible). As Anthony indicated, this probably doesn't require to change the model (in terms of QOM type) but to dynamically change what is exposed to the guest by POWER8 through registers/fdt/whatever. A related example in our tree is an ARM CPU model that changes its MIDR (PVR equivalent) on register write, search for ARM_CPUID_TI915T. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
