Re: [Qemu-devel] [Qemu-ppc] [PATCH] pseries: Correct vmx/dfp handling in both KVM and TCG cases

[David Gibson <david@gibson.dropbear.id.au>]

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