Re: [PATCH 17/18] arm64: Permit onlining of HVO-incompatible late CPUs if HVO is not in use

[James Houghton]

On Wed, Aug 19, 2026 at 3:11 AM Catalin Marinas <catalin.marinas@xxxxxxx> wrote:
>
> On Wed, Jul 08, 2026 at 03:11:27AM +0000, James Houghton wrote:
> > First, HVO must have ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU so that
> > incompatible CPUs can be onlined if HVO is not in use. The
> > late_cpu_enable() callback is used to check if HVO is truly in use.
> >
> > If the late CPU is incompatible with HVO and HVO is *not* in use, HVO
> > becomes permanently disabled.
> >
> > If the late CPU is incompatible with HVO and HVO *is* in use, the CPU
> > is not onlined.
>
> I haven't looked in detail at the logic here but do we actually care
> about this? We still need to solve the BBML2 requirement around patches
> 12 and 13. BBML2 won't be an optionally late feature for other reasons,
> so such CPUs won't be allowed. This leaves us with HW AF. In mainline,
> the check is done on the sanitised regs but IIRC these can still be
> overridden on late CPU onlining with a warning. We only use this check
> as an optimisation, so not an issue in mainline but can be come
> problematic with HVO.

I just tried reading through cpufeature.c again, and I think, because
`ID_AA64MMFR1_EL1_HAFDBS` is marked as `FTR_STRICT`, we will indeed
get a taint if there is a mismatch for HAFDBS. When this happens, the
sanitized register value should be set to the lowest value. This value
should indeed be safe to use.

ARM64_HW_DBM implies that it's expected for CPUs to have mismatched
support for HAFDBS (indeed, this was the impression I was under as
well), so it seems like a bug that HAFDBS is labeled `FTR_STRICT`.
What do you think?

I still need to work out exactly how cpufeature.c is going to learn
about whether or not HVO has been enabled on the command line
(hugetlb_free_vmemmap=1) for the purposes of preventing incompatible
CPUs getting onlined; I'll figure something out.

> If we don't have a strong use-case for mismatched HAFDBS support, I'd
> drop these last patches for now.

I'll drop these last few patches (14-18).

The only caveat is that by doing this, I don't see a way to keep HVO
runtime-enableable. In other words, if the user booted without
specifying `hugetlb_free_vmemmap=1` (assuming
HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON=n), they cannot dynamically
turn it on after the fact. This is not a problem for me.