From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIU85-0002dh-71 for qemu-devel@nongnu.org; Mon, 24 Oct 2011 19:40:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIU83-00021r-84 for qemu-devel@nongnu.org; Mon, 24 Oct 2011 19:40:29 -0400 Date: Tue, 25 Oct 2011 10:08:47 +1100 From: David Gibson Message-ID: <20111024230847.GB4191@truffala.fritz.box> References: <1318911341-10890-1-git-send-email-david@gibson.dropbear.id.au> <4FD80D1B-D83A-4FD6-ABC8-3FEE985B7D57@suse.de> <20111021004114.GB3852@truffala.fritz.box> <2B3B4C66-9DF4-4CB1-876D-AF917D716D42@suse.de> <20111021050614.GA24434@truffala.fritz.box> <4CD82990-0A3D-41E4-B40D-E98607CE276A@suse.de> <20111024052951.GE4157@truffala.fritz.box> <8DEA1BBB-904C-457E-8269-3A4C98092EC3@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] pseries: Correct vmx/dfp handling in both KVM and TCG cases List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-ppc@nongnu.org, "qemu-devel@nongnu.org Developers" [snip] > >> Reading through the patch again I think I see your point now :). Yes, the kvmppc_host_cpu_def function only tries to fetch the host CPU capabilities. > >> > >> So yes, there is basically only the masking part with what we can actually virtualize missing. But for now we can just assume that every feature the host CPU supports is available. > >> > >> I'll apply your patch for now, as it certainly is better than what we had before. > > > > This breaks on 970mp (PowerStation). kvmppc_get_vmx returns -1 because ibm,vmx doesn't exist in the host dt, but the CPU still supports Altivec. > > > > Any alternative way to enumerate VMX availability? > > Thinking about it a bit more ... Why do we need to check the host's > capability to do VMX/VSX/DFP? Shouldn't the PVR already tell us > everything we need to know? Well.. not necessarily. First there's the possibility of a CPU that's theoretically capable of VSX or DFP, but where the administrator has disabled it in firmware. Second, if we add approximate PVR matching (which I'd like to do), then we should trust the host information over the table, because we could actually be dealing with a diffferent revision to the one we got from the table. > We're still missing some way for KVM to tell us what it can > virtualize to the guest, but for now we assume that anything we > throw at it works anyways. Right. I think we'll hneed to do that on a feature by feature basis as we discover things that can't be KVM virtualized. I will send a patch that deals with the masking for features that TCG can't emulate. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson