[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexander Graf
Subject: Re: [Qemu-ppc] [PATCH] pseries: Correct vmx/dfp handling in both KVM and TCG cases
Date: Mon, 24 Oct 2011 18:20:48 -0700

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]