linux-kernel - Re: [linux-sunxi] [PATCH 2/2] ARM: sun6i: Add SMP support for the Allwinner A31

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 08 Nov 2013 10:25:55 +0000
From:	Ian Campbell <ijc@...lion.org.uk>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:	linux-sunxi@...glegroups.com, linux-arm-kernel@...ts.infradead.org,
	Russell King <linux@....linux.org.uk>, kevin.z.m.zh@...il.com,
	sunny@...winnertech.com, shuge@...winnertech.com,
	zhuzhenhua@...winnertech.com, linux-kernel@...r.kernel.org
Subject: Re: [linux-sunxi] [PATCH 2/2] ARM: sun6i: Add SMP support for the
 Allwinner A31

On Fri, 2013-11-08 at 09:40 +0100, Maxime Ripard wrote:
> > I'm trying to work out if we can make this work with the requirement
> > which both Xen and KVM have to enter the kernel in NS-HYP mode.
> > 
> > The way this works on e.g. vexpress is (roughly) that u-boot wakes up
> > the secondary CPUs from the lowlevel firmware and places them into its
> > own holding pen, which has the same wake up protocol as the firmware so
> > the kernel can just use the same code. If u-boot never gets to run on
> > secondary CPUs that isn't going to help much. 
> > 
> > My concern is that the sequence here appears to involve resetting the
> > secondary CPU, which I figure will probably defeat that strategy by
> > kicking the CPU back into the lowlevel firmware in the reset state,
> > meaning it can't be done by a u-boot only change.
> 
> I think this is where we're headed for the A20, Marc was interested in
> doing that,

Marc Zyngier is that?

>  since we already have pretty much this in u-boot already,
> however, this is not the case for the A31.

> As far as I know, the Allwinner's bootloader that we currently use
> isn't bringing up the secondary CPUs, and we don't have any port of
> some sort of u-boot yet that we could work on.

Ah, OK. I'd assumed that A20 and A31 (indeed, most sunxi platforms) were
mostly equivalent as far as u-boot support went.

> So, I guess we don't really have much choice in that case, even though
> eventually I'd like to have this for the A31 too.

Right, I suppose it makes sense to consider what we want to do on the
A20 now and keep in mind that A31 may want to follow in the future.

> > Hrm, what to do ... perhaps a DT driven selection between this mechanism
> > and sev to kick a wfe loop reading the private register?
> 
> We can discuss this whenever we will actually have that choice to
> make, but maybe a kernel parameter would be better?

I don't think so -- u-boot would then have to munge the command line to
say that it had/had not brought up secondaries. DTB seems more natural
to me. e.g. on ARMv8 there is already a requirement to provide a per-CPU
property describing the bringup protocol ("PSCI" and "spintable" are the
options there).

Anyway, once I get to the point of being able to do something I'll
coordinate with Marc etc and figure out what to do. In the meantime I
think having the kernel do the bringup (like this patch does) is
sensible. It's very likely to be what we want to do in the absence of
any instruction to the contrary (DTB or otherwise) in the future anyway.

Thanks,

Ian.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/