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

[Alexander Graf]

On 24.10.2011, at 17:09, David Gibson <address@hidden> wrote:

> 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".

Good ;). If that one was to simply omit the vmx property, Linux would take the 
vmx availability from pvr today as well, so we're aligned with what the host OS 
does now.

Alex

> 
>>> 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