On Fri, 16 Feb 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 15/02/18 23:16, Stefano Stabellini wrote:
> > On big.LITTLE systems not all cores have the same ACTLR. Instead of
> > reading ACTLR and setting v->arch.actlr in vcpu_initialise, which is run
> > always on pcpu 0, do it later on the same pcpu where the vcpu will run.
> 
> While the Hardware domain vCPUs will always be created on pCPU 0, this may not
> be the case for other domain as it is done via an hypercall.

I'll reword


> > 
> > This way, assuming that the vcpu has been created with the right pcpu
> > affinity, the guest will be able to read the right ACTLR value, matching
> > the one of the physical cpu.
> > 
> > Signed-off-by: Stefano Stabellini <sstabell...@kernel.org>
> > ---
> >   xen/arch/arm/domain.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index a010443..532e824 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -314,6 +314,8 @@ static void schedule_tail(struct vcpu *prev)
> >     static void continue_new_vcpu(struct vcpu *prev)
> >   {
> > +    current->arch.actlr = READ_SYSREG32(ACTLR_EL1);
> 
> This is not enough, you also need to move the call of
> processor_vcpu_initialise here. For instance on Cortex-A15, this will
> set/clear the SMP bit in ACTLR.

Right! I'll make the change.


> Also, I just noticed that processor_vcpu_initialize (in arch/arm/processor.c)
> assumes all the processor will be the same.  We probably want to turn the
> variable processor into a per-cpu value.

Good point, I'll add a patch for that


> > +
> >       schedule_tail(prev);
> >         if ( is_idle_vcpu(current) )
> > @@ -540,8 +542,6 @@ int vcpu_initialise(struct vcpu *v)
> >         v->arch.vmpidr = MPIDR_SMP | vcpuid_to_vaffinity(v->vcpu_id);
> >   -    v->arch.actlr = READ_SYSREG32(ACTLR_EL1);
> > -
> >       v->arch.hcr_el2 = get_default_hcr_flags();
> >         processor_vcpu_initialise(v);
> > 
> 
> Cheers,
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to