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

[David Gibson]

[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