On 28/04/16 14:26, Suriyan Ramasami wrote:
Hello Julien,
Hello Suriyan,
Thank you for the advice. I do have a follow up question.
On Thu, Apr 28, 2016 at 2:50 AM, Julien Grall <julien.grall@xxxxxxx
<mailto:julien.grall@xxxxxxx>> wrote:
Hello,
On 27/04/16 23:53, Suriyan Ramasami wrote:
How can I check which core is currently active?
Judging by this link on big.LITTLE architecture:
http://forum.odroid.com/viewtopic.php?f=65&t=2580
result of: cat /proc/cpuinfo | grep "CPU part" is
CPU part : 0xc07
which stands for A7.
If you do this in dom0, it will show all of them to be 0xc07.
They are
vCPUs after all.
Which is not a good idea. This means that Linux is not able to
detect potential errata for the underlying cores (in this case the
cortex-A15). Also some userspace may do some runtime optimization
based on the kind of CPUs available in the guest.
Xen is not ready for big.LITTLE, so I would highly recommend you to
disable either all the Cortex-A15 or Cortex-A7.
Ian did recommend that if they were in their own cpu pools it would
avoid mixing them in a guest. I was researching that angle. What is your
take on that?
I have the same idea in mind. The pools are created at boot time by Xen,
physical CPUs will be assigned to a pool depending on the CPU ID.
However this is not enough to get support of big.LITTLE. You will at
least need to modify the domain creation code to set the vMIDR based on
the based where the vCPU will run.
Furthermore Xen is expecting all the CPUs to have the same set of
features, hence the boot CPU data is often used to know what could be
run. This would need some work to get a system wide safe value (see
arch/arm64/kernel/cpufeature.c in Linux).
If Linux is not recognizing it, that is a dom0/domU issue, is it not?
This is a Xen issue. Xen is exposing the wrong CPU ID to the domain and
therefore the kernel may not apply properly errata or apply wrong
optimization.
Regards,
