Re: Odroid XU3 support

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

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@arm.com
> <mailto:julien.grall@arm.com>> 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,

-- 
Julien Grall

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