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

[Alexander Graf]

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 gets further complicated in the case of the w-i-p patch I have to
>>> properly advertise page sizes, where it's not just presence or absence
>>> of a feature, but the specific SLB and HPTE encodings must be
>>> advertised to the guest.
>> 
>> Yup, so we'd read out the host dt to find the host possible
>> encodings (probably a bad idea, but that's a different story)
> 
> Um, a different story perhaps, but one I kind of need an answer to in
> the near future...  I can query the host cpu's page sizes easily
> enough, but I'm really not sure where this should be stashed before
> filtering as suggested below.

Page sizes are usually powers of 2, so we should be ok with just having a 
bitmap there with each bit meaning 1 << (n + 12).


Alex