Re: [Xen-devel] Arndale secondary CPU boot issue Was Re: [xen-unstable test] 60076: regressions - FAIL

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-07-29 at 19:18 +0100, Julien Grall wrote:

As an aside from the issue you are seeing:

> The old implementation of spinlock is sending an event (via the assembly
> instruction SEV) to the other physical CPUs. This will wake up the
> others CPUs waiting on the assembly instruction WFE (Wait For Event).

Uh, I didn't notice this about the new implementation, sorry I should have
done.

IMHO we should investigate (probably with some urgency) inserting a WFE and
SEV pair into the lock/unlock paths, else power consumption will suck.

I think that probably means using something new to replace the cpu_relax()
calls in the spinlocks with a WFE on ARM (we don't just want to change
relax) and to add a arch specific hook for the SEV on the release path.

If it is too late for 4.6 (which would depend on the eventual complexity of
the actual fix) then we should fix this ASAP in 4.7 and backport for 4.6.1.

> It appears to be required on the Arndale to boot secondaries CPUs.
> Although, depending on where I put the sev I don't have the same 
> behavior:
>       - sev in smp_init callback: the CPU is not coming up
>       - sev before or after arch_cpu_up: the CPU is booting but not in 
> HYP
> mode [2]
> 
> I haven't yet figured out where the "sev" should be placed in order to
> get the CPU boot correctly.

Does the arndale end up using 
.cpu_up = cpu_up_send_sgi,
or
.cpu_up = exynos5_cpu_up,
?

> What I don't understand is how the placement of "sev" would affect the
> secondary processor to boot in HYP mode or Kernel mode or nothing at all
> 
> This platform seems very picky and I don't remember having a
> documentation about how the SMP boot works for this platform. Linux
> seems to avoid the SEV for this platform.

32-bit Linux has some in common code paths IIRC, which are not always
apparent at first glance.

Ian.

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