Re: [Xen-devel] [PATCH] xen/arm: Trap the ACTLR register

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-07-17 at 14:57 +0100, Stefano Stabellini wrote:
> On Wed, 17 Jul 2013, Ian Campbell wrote:
> > On Thu, 2013-07-04 at 16:01 +0100, Julien Grall wrote:
> > > @@ -452,6 +451,12 @@ int vcpu_initialise(struct vcpu *v)
> > >          return rc;
> > >  
> > >      v->arch.sctlr = SCTLR_BASE;
> > > +    v->arch.actlr = READ_SYSREG32(ACTLR_EL1);
> > > +    /* XXX: Handle other than CA15 cpus */
> > > +    if ( v->domain->max_vcpus > 1 )
> > > +        v->arch.actlr |= ACTLR_CA15_SMP;
> > > +    else
> > > +        v->arch.actlr &= ~ACTLR_CA15_SMP;
> > 
> > I'm not 100% sure about this last bit. A CONFIG_SMP=y kernel will want
> > to set this regardless of there only being one processor since the
> > Cortex A15 (and now A7) are both MPCore processors. Granted they don't
> > actually check or panic etc when we ignore them, so maybe it doesn't
> > matter.
> > 
> > I'd be tempted to simply expose the raw underling ACTLR_EL1 to guests
> > (r/o of course), it neatly sidesteps any need to know about specific
> > processors too. Anyone got any other thoughts?
> 
> The only concern would be about migration or big.LITTLE machines, where
> at some point the value of the ACTLR (if it's even present) would
> suddenly change underneath Linux's feet.
> I don't think that would cause problems, but it's worth keeping it in
> mind.

OK. so I've acked + applied this one, we can always redo it later when
we start to investigate these use cases.

It occurs to me now that the behaviour we have (statically configuring
the SMP bit) is no different to the situation where the Secure World
firmware has configured it and not set the NSACR.NS_SMP bit, so its not
unexpected for the kernels attempts to change it to silently be ignored.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel