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:55, Alexander Graf wrote:

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

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?

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.


Alex