From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v2 15/15] xen/arm: gic-v3: Add support of vGICv2 when available Date: Wed, 1 Jul 2015 09:12:14 +0100 Message-ID: <1435738334.21469.228.camel@citrix.com> References: <1435311269-3189-1-git-send-email-julien.grall@citrix.com> <1435311269-3189-16-git-send-email-julien.grall@citrix.com> <1435670173.21469.152.camel@citrix.com> <5592D1FD.1000103@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAD83-0000Xy-9A for xen-devel@lists.xenproject.org; Wed, 01 Jul 2015 08:12:23 +0000 In-Reply-To: <5592D1FD.1000103@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: Julien Grall Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com List-Id: xen-devel@lists.xenproject.org On Tue, 2015-06-30 at 18:29 +0100, Julien Grall wrote: > > > >> + */ > >> + if ( v->domain->arch.vgic.version == GIC_V2 ) > >> + val &= ~GICC_SRE_EL2_ENEL1; > >> + else > >> + val |= GICC_SRE_EL2_ENEL1; > >> + WRITE_SYSREG32(val, ICC_SRE_EL2); > >> + isb(); > > > > Is the isb strictly needed? I suppose we are already using rather too > > many, perhaps a more complete audit is in order. > > AFAICT no, the ENEL1 doesn't gate any access to EL1 systems register in EL2. > > There is an isb in the caller (gic_restore_state) but I find it > confusing because we rely on the caller doing the right thing for us. > I'm thinking to push the isb within the callee for more clarify. isb's aren't free though. > It can be part of a bigger audit. Indeed, this isn't one for now/. Really there should probably be a single isb at the end of ctxt save/restore and very little otherwise except where there is an absolute need for some sort of ordering between steps. > >> + /* > >> + * When the guest is GICv3, all guest IRQs are Group 1, as Group0 > >> + * would result in a FIQ in the guest, which it wouldn't expect > > > > Unless the guest actually asked for a FIQ (not sure how that works). > > Anyway, I don't think you need to support that case here... > > Well, I don't even think that FIQ has ever working with guest and Xen. Yes, you don't need to anything, I was just idly wondering, sorry for not being clear about that. > So I would expect to see more work than this small change. Absolutely, > > I wonder how one specifies without GICC, given that GICH comes after > > it... Oh well! > > GICv3 doesn't use the GICH to control the GIC hypervisor interface but > the system register. Oh of course, I'd forgotten. > > Despite all the comments I don't think there are any blockers: > > > > Acked-by: Ian Campbell > > Thank you. >