On Wed, Dec 24, 2025, at 03:26, Jason Gunthorpe wrote:
> On Fri, Dec 19, 2025 at 09:34:33PM +0100, Arnd Bergmann wrote:
>> On Fri, Dec 19, 2025, at 18:14, Jason Gunthorpe wrote:
>> >
>> > This looks great, but do you think there should be a boot time crash
>> > if a VIVT and HIGHMEM are enabled, just incase?
>>
>> Do you mean in the common code or just for Arm?
>>
>> We could use the Arm specific cache_is_vivt() macro, but it feels like
>> the 'dpends on !CPU_CACHE_VIVT' Kconfig check I added is both
>> safer and simpler.
>
> Okay, so maybe I'm asking if !CPU_CACHE_VIVT then the kernel fails to
> boot on vivt systems, maybe it already does?
>
Yes, in two separate ways:
- you can build a kernel for any combination of armv4/v4t/v5 CPUs
(all VIVT), or any combination of armv6/v6k/v7/v7ve/v8 CPUs
(all VIPT or PIPT), but we already enforce that you cannot mix
the two in any way. The two sets are sufficiently different in
terms of instruction set, MMU cache and FPU that trying to boot
the wrong one probably doesn't even get to the point of printing
any output.
- If something changed about the assumption above, any Arm kernel
still needs to enable support for each individual CPU model that
you may want to boot on. Enabling a SoC family will select the
CPUs used in that SoC, and enabling a CPU type selects
the cache features like CPU_CACHE_VIVT. Attempting to boot
on a CPU model that is not enabled in the kernel build makes
it fail in setup_arch() with:
pr_err("CPU%u: configuration botched (ID %08x), CPU halted\n",
smp_processor_id(), midr);
while (1)
;
Arnd
