[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

On 18 August 2014 18:47, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Sun, Aug 17, 2014 at 01:06:09AM +0100, Leif Lindholm wrote:
>> On Fri, Aug 15, 2014 at 03:38:04PM +0100, Will Deacon wrote:
>> > On Fri, Aug 15, 2014 at 03:35:55PM +0100, Mark Salter wrote:
>> > > On Fri, 2014-08-15 at 15:28 +0200, Ard Biesheuvel wrote:
>> > > > On 15 August 2014 14:53, Will Deacon <will.deacon at arm.com> wrote:
>> > > > > On Fri, Aug 15, 2014 at 01:07:16PM +0100, Ard Biesheuvel wrote:
>> > > > >> On 15 August 2014 13:57, Will Deacon <will.deacon at arm.com> wrote:
>> > > > >> > I was planning to take all of these for 3.18 as there's no regression here
>> > > > >> > (the fuzzing is a new debug feature and defaults to `n'). Do you think these
>> > > > >> > qualify as -rc1 material?
>> > > > >>
>> > > > >> Considering that TEXT_OFFSET fuzzing is recommended to be turned on
>> > > > >> for distro kernels, I would say this is definitely appropriate for
>> > > > >> 3.17
>> > > > >
>> > > > > Whilst I see that in the commit log, the same recommendation doesn't appear
>> > > > > in the Kconfig text and I'm not sure that it's such a wise thing to say
>> > > > > either. From a distribution's point of view, I think I'd want any kernel
>> > > > > issues to be as reproducible as possible, and fuzzing the text offset seems
>> > > > > to go against that.
>> > > >
>> > > > OK. There is one other real world issue that 3/3 addresses, which are
>> > > > platforms that have memreserves at the base of DRAM containing bits of
>> > > > UEFI itself (this is what got this whole discussion going in the first
>> > > > place). Currently, we cannot boot via UEFI on these platforms, as the
>> > > > EFI stub will only consider base of DRAM + TEXT_OFFSET as an option,
>> > > > and fail the boot if it is not available.
>> > > >
>> > > > If this is something that could wait until 3.18 as well (Mark S?),
>> > > > then it's fine by me.
>> > >
>> > > I don't see a problem with waiting until 3.18.
>> >
>> > Cheers, I've applied the series to our for-next branch and I'll push
>> > everything out at -rc1.
>>
>> Late to the discussion since I was on an 11h flight, and still chiming
>> in since I don't think previous speakers were explicit enough about
>> the implication:
>> Bumping 3/3 to 3.18 means the upstream kernel will not boot on AMD
>> Seattle until at least December. This sounds suboptimal to me.
>
> Not unless they use PSCI. That's already working (the spin-table is
> meant for platforms where PSCI cannot be implemented).
>

No, that is patch #1

#3 allows other base addresses than base of DRAM + TEXT_OFFSET when
booting via UEFI, which is needed by AMD Seattle.
However, #3 breaks booting the secondaries on APM Mustang, hence #1.

-- 
Ard.


> BTW, is Seattle officially supported by the mainline kernel (it was
> barely announced AFAICT)?
>
> --
> Catalin