Re: [Xen-devel] [PATCH 0/4] unsafe big.LITTLE support

2018-02-16 Thread Stefano Stabellini
On Fri, 16 Feb 2018, Julien Grall wrote:
> On 15/02/18 23:16, Stefano Stabellini wrote:
> > Hi all,
> 
> Hi Stefano,
> 
> > This series changes the initialization of two virtual registers to make
> > sure they match the value of the underlying physical cpu.
> > 
> > It also disables cpus different from the boot cpu, unless a newly
> > introduced command line option is specified. In that case, it explains
> > how to setup the system to avoid corruptions, which involves manually
> > specifying the cpu affinity of all domains, because the scheduler still
> > lacks big.LITTLE support.
> On top of this series, I think we want to rework how we read the size of the
> cacheline. At the moment, we only read it on the boot CPU. But they may be
> different on each CPUs.
> 
> So I would replace that variable by reading the cacheline size everytime from
> system registers. This should quicker than trying to read the memory to know
> the cacheline size.
> 
> Note that I suggested this as a small tasks for Outreachy/GSOC.

The suggestion is very good, I'll do it as part of this series.

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

Re: [Xen-devel] [PATCH 0/4] unsafe big.LITTLE support

2018-02-16 Thread Julien Grall



On 15/02/18 23:16, Stefano Stabellini wrote:

Hi all,


Hi Stefano,


This series changes the initialization of two virtual registers to make
sure they match the value of the underlying physical cpu.

It also disables cpus different from the boot cpu, unless a newly
introduced command line option is specified. In that case, it explains
how to setup the system to avoid corruptions, which involves manually
specifying the cpu affinity of all domains, because the scheduler still
lacks big.LITTLE support.
On top of this series, I think we want to rework how we read the size of 
the cacheline. At the moment, we only read it on the boot CPU. But they 
may be different on each CPUs.


So I would replace that variable by reading the cacheline size everytime 
from system registers. This should quicker than trying to read the 
memory to know the cacheline size.


Note that I suggested this as a small tasks for Outreachy/GSOC.

Cheers,

--
Julien Grall

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