From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36480) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIUZu-0000y0-TB for qemu-devel@nongnu.org; Mon, 24 Oct 2011 20:09:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIUZt-000631-Ch for qemu-devel@nongnu.org; Mon, 24 Oct 2011 20:09:14 -0400 Date: Tue, 25 Oct 2011 11:09:00 +1100 From: David Gibson Message-ID: <20111025000900.GF4191@truffala.fritz.box> References: <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> <20111024230847.GB4191@truffala.fritz.box> 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" On Mon, Oct 24, 2011 at 04:43:18PM -0700, Alexander Graf wrote: > > On 24.10.2011, at 16:08, David Gibson wrote: > > > [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. > > Oh you can disable it in firmware? Then we should take it from the > dt if available, yes. I think so. I'm not 100% sure on the details. But I believe there's a thing designed for partition migration which essentially goes "don't use this processor feature, because I want to be able to migrate you to an earlier processor sometime". > > 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. > > Yeah, for fuzzy matching we want it. I agree. > > >> 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. > > Thanks :). > > > Alex > > -- 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