From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH 09/12] xen: arm: correctly handle sysreg accesses from userspace Date: Wed, 25 Mar 2015 19:22:22 +0000 Message-ID: <55130AEE.70406@linaro.org> References: <1427293339.10784.83.camel@citrix.com> <1427293356-5714-9-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1427293356-5714-9-git-send-email-ian.campbell@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 , xen-devel@lists.xen.org Cc: tim@xen.org, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org Hi Ian, On 25/03/15 14:22, 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. It's not true on all *_EL1 registers. See PMINTENSET_EL1 for instance. > PMUSERENR_EL0 and MDCCSR_EL0 are R/O to EL0. Might be worth to explain that we forgot to implement MDCCSR_EL0 before. > > 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. The ARMv8 spec is confusing on this point Let's take PMCR_EL0 for instance. The PMUSERENR_EL0.EN trapping is not explained. Although, PMCR is trapped when PMUSERENR_EL0.EN == 0. Do you have a paragraph on the spec which clearly explain the behavior? Regards, -- Julien Grall