[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

Hello Peng,

On 21/09/16 09:38, Peng Fan wrote:
On Tue, Sep 20, 2016 at 01:17:04PM -0700, Stefano Stabellini wrote:
On Tue, 20 Sep 2016, Julien Grall wrote:
On 20/09/2016 20:09, Stefano Stabellini wrote:
On Tue, 20 Sep 2016, Julien Grall wrote:
On 20/09/2016 12:27, George Dunlap wrote:
On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan <van.freenix@xxxxxxxxx>
On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote:
On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:
On Tue, 20 Sep 2016, Dario Faggioli wrote:
It is harder to figure out which one is supposed to be
big and which one LITTLE. Regardless, we could default to using the
first cluster (usually big), which is also the cluster of the boot cpu,
and utilize the second cluster only when the user demands it.

Why do you think the boot CPU will usually be a big one? In the case of Juno
platform it is configurable, and the boot CPU is a little core on r2 by

In any case, what we care about is differentiate between two set of CPUs. I
don't think Xen should care about migrating a guest vCPU between big and
LITTLE cpus. So I am not sure why we would want to know that.

No, it is not about migrating (at least yet). It is about giving useful
information to the user. It would be nice if the user had to choose
between "big" and "LITTLE" rather than "class 0x1" and "class 0x100", or
even "A7" or "A15".

As Dario mentioned in previous email,
for dom0 provide like this:

dom0_vcpus_big = 4
dom0_vcpus_little = 2

to dom0.

If these two no provided, we could let dom0 runs on big pcpus or big.little.
Anyway this is not the important point for dom0 only big or big.little.

For domU, provide "vcpus.big" and "vcpus.little" in xl configuration file.
Such as:

vcpus.big = 2
vcpus.litle = 4

According to George's comments,
Then, I think we could use affinity to restrict little vcpus be scheduled on 
little vcpus,
and restrict big vcpus on big vcpus. Seems no need to consider soft affinity, 
use hard
affinity is to handle this.

We may need to provide some interface to let xl can get the information such as
big.little or smp. if it is big.little, which is big and which is little.

For how to differentiate cpus, I am looking the linaro eas cpu topology code,
The code has not been upstreamed (:, but merged into google android kernel.
I only plan to take some necessary code, such as device tree parse and
cpu topology build, because we only need to know the computing capacity of each 

Some doc about eas piece, including dts node examples:

I am reluctant to take any non-upstreamed bindings in Xen. There is a similar series going on the lklm [1].

But it sounds like it is a lot of works for little benefits (i.e giving a better name to the set of CPUs). The naming will also not fit if in the future hardware will have more than 2 kind of CPUs.


I am not sure, but we may also need to handle mpidr for ARM, because big and 
little vcpus are supported.

I am not sure to understand what you mean here.


[1] https://lwn.net/Articles/699569/

Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.