[RFC PATCH 01/10] KVM: PPC: BOOK3S: PR: Fix PURR and SPURR emulation

[Alexander Graf]

On 31.01.2014, at 23:17, Paul Mackerras <paulus at samba.org> wrote:

> On Fri, Jan 31, 2014 at 11:47:44AM +0100, Alexander Graf wrote:
>> 
>> On 31.01.2014, at 11:38, Aneesh Kumar K.V <aneesh.kumar at linux.vnet.ibm.com> wrote:
>> 
>>> Alexander Graf <agraf at suse.de> writes:
>>> 
>>>> On 01/28/2014 05:44 PM, Aneesh Kumar K.V wrote:
>>>>> We definitely don't need to emulate mtspr, because both the registers
>>>>> are hypervisor resource.
>>>> 
>>>> This patch description doesn't cover what the patch actually does. It 
>>>> changes the implementation from "always tell the guest it uses 100%" to 
>>>> "give the guest an accurate amount of cpu time spent inside guest
>>>> context".
>>> 
>>> Will fix that
>>> 
>>>> 
>>>> Also, I think we either go with full hyp semantics which means we also 
>>>> emulate the offset or we go with no hyp awareness in the guest at all 
>>>> which means we also don't emulate SPURR which is a hyp privileged
>>>> register.
>>> 
>>> Can you clarify this ?
>> 
>> In the 2.06 ISA SPURR is hypervisor privileged. That changed for 2.07 where it became supervisor privileged. So I suppose your patch is ok. When reviewing those patches I only had 2.06 around because power.org was broken.
> 
> It's always been supervisor privilege for reading and hypervisor
> privilege for writing, ever since it was introduced in 2.05, and that
> hasn't changed.  So I think what Aneesh is doing is correct.

This is what ISA 2.06B says:

308	SPURR	hypv		hypv		64	S
309	PURR	hypv		yes		64	S

And this is ISA 2.07:

308	SPURR	hypv		yes		64	S
309	PURR	hypv		yes		64	S

So as you can see, from 2.06 to 2.07 SPURR became supervisor readable. Either the spec is wrong, the respective POWER CPUs don't implement the spec correctly or "hypv" doesn't mean "hypv" but means "may be hypv or yes".

I think in the context of this patch it's perfectly reasonable to treat SPURR as supervisor readable.


Alex