From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uwo8y-0002uJ-Ds for qemu-devel@nongnu.org; Wed, 10 Jul 2013 02:44:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uwo8w-0003kb-On for qemu-devel@nongnu.org; Wed, 10 Jul 2013 02:44:52 -0400 Received: from e23smtp06.au.ibm.com ([202.81.31.148]:57384) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uwo8v-0003Zq-7u for qemu-devel@nongnu.org; Wed, 10 Jul 2013 02:44:50 -0400 Received: from /spool/local by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 10 Jul 2013 16:36:28 +1000 Message-ID: <51DD017F.8010304@linux.vnet.ibm.com> Date: Wed, 10 Jul 2013 12:08:55 +0530 From: Prerna Saxena MIME-Version: 1.0 References: <1373118856-30171-1-git-send-email-aik@ozlabs.ru> <1373118856-30171-19-git-send-email-aik@ozlabs.ru> <20130708010917.GD2696@voom.redhat.com> <51DA8023.20503@suse.de> <51DADF6F.6010006@linux.vnet.ibm.com> <51DAECA7.2090405@suse.de> In-Reply-To: <51DAECA7.2090405@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 18/19] target-ppc: Enhance the CPU node labels for the guest device tree for pseries. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: qemu-ppc , qemu-devel@nongnu.org, Alexander Graf Hi Andreas, Thanks for the response. On 07/08/2013 10:15 PM, Andreas Färber wrote: > Hi, > > Am 08.07.2013 17:49, schrieb Prerna Saxena: >> On 07/08/2013 02:32 PM, Andreas Färber wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Am 08.07.2013 03:09, schrieb David Gibson: >>>> On Sat, Jul 06, 2013 at 11:54:15PM +1000, Alexey Kardashevskiy >>>> wrote: >>>>> @@ -1342,6 +1346,13 @@ static void >>>>> ppc_spapr_init(QEMUMachineInitArgs *args) >>>>> register_savevm_live(NULL, "spapr/htab", -1, 1, >>>>> &savevm_htab_handlers, spapr); >>>>> >>>>> + /* Ensure that cpu_model is correctly reflected for a KVM >>>>> guest */ + if (kvm_enabled() && !strcmp(cpu_model, "host")) { >>>>> + asm ("mfpvr %0" + : "=r"(pvr)); + >>>>> cpu_model = ppc_cpu_alias_by_pvr(pvr); >>>> >>>> This needs to be protected by an ifdef CONFIG_KVM or similar. If >>>> the compiler optimization level is turned down, so that it doesn't >>>> recognize that the kvm_enabled() is always false, then this could >>>> attempt to compile the ppc asm instructions on an x86 (or >>>> whatever) host. >>> >>> This hunk can be completely replaced by QOM mechanisms - just didn't >>> get to replying yet... >> >> Sorry I already sent out a v2, and only then saw your message. Could you >> pls explain how I could use QOM to replace this code block ? > > Well, in short the thing is it has not much to do with KVM. The > KVM-specific host-powerpc64-cpu type is derived from the one you're > looking for and thus you can use object_class_get_parent() to obtain the > parent type and look at its name - stripping "-" TYPE_POWERPC_CPU from > it should be much more efficient but will give you the detailed name > including revision. I was planning to propose an alternative patch for that. This is what my patch does :-) +const char *ppc_cpu_alias_by_pvr(uint32_t pvr) +{ + int i; + const char *cpu_alias; + char *offset, *model; + + cpu_alias = object_class_get_name(OBJECT_CLASS + (ppc_cpu_class_by_pvr(pvr))); + ....[snip] > > Replacing a concrete model name with its simpler alias is a secondary > issue (separate patch) that is not specific to KVM or -cpu host. Compare > -cpu POWER8_v1.0 printing .../POWER8_v1.0@0/... presumably. > Agree that this is not specific to KVM. That is the reason I have set it in a separate function, which can be called otherwise as well. Just to clarify your response, you want the function I coded to be split into 2 different pieces, to cater to the two specific requirements you mention ? That can be done, but not sure if it is too much code bloat. > Further, Alex has already applied a patch of his working around the > alias table being a rather archaic construct, not intended for frequent > use. Instead of adding even more functions that iterate it, we should > turn it into a hashtable for efficient lookup. > Can you / Alexander Graf point me to the fix ? I can rework my patch to consume it ? > (Note that the cpu_model_str field may contain more than just the model > name, it is otherwise unused in softmmu and I was therefore preparing a > patch to ban its use to linux-user solely, so the type name seems the > most reliable indicator we have and as a bonus no PVR needed for it.) > Hmm, maybe obsoleting PVR check is not such a great idea. I'm not sure if my earlier email clearly outlined the use-case this patch was attempting to fix. Here is a detailed explanation : We will still need PVR based lookups for cases such as the one I have described. As an illustration, consider running in a KVM environment where QEMU hasnt been started with a specific CPU type via "-CPU PPC_MODEL". In this case, we will be required to do a PVR_based lookup only -- to make sure the guest gets initialized with the same CPU as host. The notion of _same_cpu_model_ can only be built over a PVR check. Regards, -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India