From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v2 7/9] xen: arm: correctly handle sysreg accesses from userspace Date: Thu, 19 Feb 2015 12:23:45 +0000 Message-ID: <1424348625.30924.59.camel@citrix.com> References: <1423542956.5851.9.camel@citrix.com> <1423543523-8010-7-git-send-email-ian.campbell@citrix.com> <54E35D5C.9090500@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54E35D5C.9090500@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Tue, 2015-02-17 at 15:25 +0000, Julien Grall wrote: > Hi Ian, > > On 10/02/15 04:45, Ian Campbell wrote: > > Previously we implemented all registers as RAZ/WI even if they > > shouldn't be accessible to userspace. > > > > Accesses to the *_EL1 registers from EL0 are trapped to EL1 by the > > hardware, so add a BUG_ON. Likewise accesses from 32-bit EL1 cannot > > happen. > > > > PMUSERENR_EL0 and MDCCSR_EL0 are R/O to EL0. > > > > Other PM*_EL0 registers are accessible at EL0 only if > > PMUSERENR_EL0.EN is set, since we emulate that as RAZ/WI we know that > > bit cannot be set. > > You assume that PMUSERENR_EL0.EN is always set to 0 during Xen boot. > Actually it's not the case and from the spec, it may be possible to have > it in an unkwnown state. The real PMUSERENR_EL0 is never seen/touched by EL1/EL0 since we trap all accesses (via MDCR_EL2.TPM) and emulate as RAZ, so the value of the real PMUSERENR_EL0 is never used (since MDCR_EL2 trumps it). Ian.