Re: Odroid XU3 support

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

(CC Stefano)

I forgot the CC stefano on this mail.

On 05/05/16 12:39, Julien Grall wrote:
>
>
> 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