On 31.01.2014, at 23:17, Paul Mackerras <pau...@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.ku...@linux.vnet.ibm.com> >> wrote: >> >>> Alexander Graf <ag...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
