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

Re: [Xen-devel] [PATCH 4/4] xen/arm: update the docs about heterogeneous computing

On 16/02/2018 20:50, Stefano Stabellini wrote:
On Fri, 16 Feb 2018, Julien Grall wrote:
Hi Stefano,

On 15/02/18 23:17, Stefano Stabellini wrote:
Update the documentation of the hmp-unsafe option to explain how to use
it safely, together with the right cpu affinity setting, on big.LITTLE

Also update the warning message to point users to the docs.

Signed-off-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
CC: jbeulich@xxxxxxxx
CC: konrad.wilk@xxxxxxxxxx
CC: tim@xxxxxxx
CC: wei.liu2@xxxxxxxxxx
CC: andrew.cooper3@xxxxxxxxxx
CC: George.Dunlap@xxxxxxxxxxxxx
CC: ian.jackson@xxxxxxxxxxxxx

   docs/misc/xen-command-line.markdown | 10 +++++++++-
   xen/arch/arm/smpboot.c              |  9 +++++----
   2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown
index 2184cb9..a1ebeea 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1007,7 +1007,15 @@ Control Xens use of the APEI Hardware Error Source
Table, should one be found.
     Say yes at your own risk if you want to enable heterogenous computing
   (such as big.LITTLE). This may result to an unstable and insecure
-platform. When the option is disabled (default), CPUs that are not
+platform, unless you manually specify the cpu affinity of all domains so
+that all vcpus are scheduled on the same class of pcpus (big or LITTLE
+but not both). vcpu migration between big cores and LITTLE cores is not
+supported. Thus, if the first 4 pcpus are big and the last 4 are LITTLE,
+all domains need to have either cpus = "0-3" or cpus = "4-7" in their VM
+config. Moreover, dom0_vcpus_pin needs to be passed on the Xen command

In your example here you suggest to have all the vCPUs of a guest to either on
big or LITTLE cores. How about giving an example where the guest can have 2
LITTLE vCPUs and one big vCPU?

I would rather discourage it at the moment, given that it requires more
complex cpu affinity settings, or vcpu pinning. Also, I am afraid that
without matching corresponding topology information on the guest device
tree, guests might not work as expected in such a scenario.

What do you think?

You already know my view on this. I would rather strongly discourage anyone pinning all vCPUs of a domain to big cores. We should avoid to provide shortcuts to use that could have potentially damageable impact on their platform without telling them.

I see. What about:

   See docs/misc/xen-command-line.markdown:hmp-unsafe


   See hmp-unsafe under 

I believe that people looking at big.LITTLE (and really want it) are smart enough to look at the docs or the code themselves. Given how fragile is your solution, I would rather avoid to help people doing bad thing.


Julien Grall

Xen-devel mailing list



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