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

[Alexander Graf]

On 24.10.2011, at 10:25, Alexander Graf wrote:

> 
> On 23.10.2011, at 22:29, David Gibson wrote:
> 
>> On Thu, Oct 20, 2011 at 11:49:40PM -0700, Alexander Graf wrote:
>>> 
>>> On 20.10.2011, at 22:06, David Gibson wrote:
>>> 
>>>> On Thu, Oct 20, 2011 at 07:40:00PM -0700, Alexander Graf wrote:
>>>>> On 20.10.2011, at 17:41, David Gibson <address@hidden> wrote:
>>>>>> On Thu, Oct 20, 2011 at 10:12:51AM -0700, Alexander Graf wrote:
>>>>>>> On 17.10.2011, at 21:15, David Gibson wrote:
>>>> [snip]
>>>>>> So, I really don't follow what the logic you want is.  It sounds more
>>>>>> like what I have already, so I'm not sure how -cpu host comes into
>>>>>> this.
>>>>> 
>>>>> Well, I want something very simple, layered:
>>>>> 
>>>>> -cpu host only searches for pvr matches and selects a different CPU
>>>>> -type based on this
>>>> 
>>>> Hrm, ok, well I can do this if you like, but note that this is quite
>>>> different from how -cpu host behaves on x86.  There it builds the CPU
>>>> spec from scratch based on querying the host cpuid, rather than
>>>> selecting from an existing list of cpus.  I selected from the existing
>>>> table based on host PVR because that was the easiest source for some
>>>> of the info in the cpu_spec, but my intention was that anything we
>>>> _can_ query directly from the host would override the table.
>>>> 
>>>> It seems to be your approach is giving up on the possibility of
>>>> allowing -cpu host to work (and give you full access to the host
>>>> features) when qemu doesn't recognize the precise PVR of the host cpu.
>>> 
>>> I disagree :). This is what x86 does:
>>> 
>>> * -cpu host fetches CPUID info from host, puts it into vcpu
>>> * vcpu CPUID info gets ANDed with KVM capability CPUIDs
>>> 
>>> I want basically the same thing. I want to have 2 different layers
>>> for 2 different semantics. One for what the host CPU would be able
>>> to do and one for what we can emulate, and two different steps to
>>> ensure control over them.
>>> 
>>> The thing I think I'm apparently not bringing over yet is that I'm
>>> more than happy to get rid of the PVR searching step for -cpu host
>>> and instead use a full host capability inquiry mechanism. But that
>>> inquiry should indicate what the host CPU can do. It has nothing to
>>> do with KVM yet. The masking with KVM capabilities should be the
>>> next separate step.
>>> 
>>> My goal is really to separate different layers into actual different
>>> layers :).
>> 
>> Hrm.  I think I see what you're getting at.  Although nothing in that
>> patch is about kvm capabilities - it's all about working out what the
>> host's cpu can do.
> 
> 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?


Alex