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

[Julien Grall <julien.grall@arm.com>]

Hello Peng,

On 19/09/2016 04:08, van.freenix@gmail.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> This patchset is to support XEN run on big.little SoC.
> The idea of the patch is from
> "https://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00465.html"
>
> There are some changes to cpupool and add x86 stub functions to avoid build
> break. Sending The RFC patchset out is to request for comments to see whether
> this implementation is acceptable or not. Patchset have been tested based on
> xen-4.8 unstable on NXP i.MX8.
>
> I use Big/Little CPU and cpupool to explain the idea.
> A pool contains Big CPUs is called Big Pool.
> A pool contains Little CPUs is called Little Pool.
> If a pool does not contains any physical cpus, Little CPUs or Big CPUs
> can be added to the cpupool. But the cpupool can not contain both Little
> and Big CPUs. The CPUs in a cpupool must have the same cpu type(midr value for ARM).
> CPUs can not be added to the cpupool which contains cpus that have different cpu type.
> Little CPUs can not be moved to Big Pool if there are Big CPUs in Big Pool,
> and versa. Domain in Big Pool can not be migrated to Little Pool, and versa.
> When XEN tries to bringup all the CPUs, only add CPUs with the same cpu type(same midr value)
> into cpupool0.

As mentioned in the mail you pointed above, this series is not enough to 
make big.LITTLE working on then. Xen is always using the boot CPU to 
detect the list of features. With big.LITTLE features may not be the same.

And I would prefer to see Xen supporting big.LITTLE correctly before 
beginning to think to expose big.LITTLE to the userspace (via cpupool) 
automatically.

See for instance v->arch.actlr = READ_SYSREG32(ACTLR_EL1).

>
> Thinking an SoC with 4 A53(cpu[0-3]) + 2 A72(cpu[4-5]), cpu0 is the first one
> that boots up. When XEN tries to bringup secondary CPUs, add cpu[0-3] to
> cpupool0 and leave cpu[4-5] not in any cpupool. Then when Dom0 boots up,
> `xl cpupool-list -c` will show cpu[0-3] in Pool-0.
>
> Then use the following script to create a new cpupool and add cpu[4-5] to
> the cpupool.
>  #xl cpupool-create name=\"Pool-A72\" sched=\"credit2\"
>  #xl cpupool-cpu-add Pool-A72 4
>  #xl cpupool-cpu-add Pool-A72 5
>  #xl create -d /root/xen/domu-test pool=\"Pool-A72\"

I am a bit confused with these runes. It means that only the first kind 
of CPUs have pool assigned. Why don't you directly create all the pools 
at boot time?

Also, in which pool a domain will be created if none is specified?

> Now `xl cpupool-list -c` shows:
> Name            CPU list
> Pool-0          0,1,2,3
> Pool-A72        4,5
>
> `xl cpupool-list` shows:
> Name               CPUs   Sched     Active   Domain count
> Pool-0               4    credit       y          1
> Pool-A72             2   credit2       y          1
>
> `xl cpupool-cpu-remove Pool-A72 4`, then `xl cpupool-cpu-add Pool-0 4`
> not success, because Pool-0 contains A53 CPUs, but CPU4 is an A72 CPU.
>
> `xl cpupool-migrate DomU Pool-0` will also fail, because DomU is created
> in Pool-A72 with A72 vcpu, while Pool-0 have A53 physical cpus.
>
> Patch 1/5:
> use "cpumask_weight(cpupool0->cpu_valid);" to replace "num_online_cpus()",
> because num_online_cpus() counts all the online CPUs, but now we only
> need Big or Little CPUs.

So if I understand correctly, if the boot CPU is a little CPU, DOM0 will 
always be able to only use little ones. Is that right?

Regards,

-- 
Julien Grall

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