From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v2 7/9] xen: arm: correctly handle sysreg accesses from userspace Date: Thu, 19 Feb 2015 14:55:59 +0000 Message-ID: <54E5F97F.5080709@linaro.org> References: <1423542956.5851.9.camel@citrix.com> <1423543523-8010-7-git-send-email-ian.campbell@citrix.com> <54E35D5C.9090500@linaro.org> <1424348625.30924.59.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1424348625.30924.59.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 19/02/15 12:23, Ian Campbell wrote: > 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). Hmmm... right sorry for the noise. Regards, -- Julien Grall