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

[Alexander Graf]

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.

> 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