Re: [PATCH 00/18] Another attempt at HVO support on arm64

[James Houghton]

On Fri, Jul 10, 2026 at 7:23 PM Muchun Song <muchun.song@xxxxxxxxx> wrote:
> > On Jul 10, 2026, at 03:04, James Houghton <jthoughton@xxxxxxxxxx> wrote:
> >
> > On Thu, Jul 9, 2026 at 2:55 AM Muchun Song <muchun.song@xxxxxxxxx> wrote:
> >>> On Jul 9, 2026, at 00:49, James Houghton <jthoughton@xxxxxxxxxx> wrote:
> >>>
> >>> On Wed, Jul 8, 2026 at 1:41 AM Muchun Song <muchun.song@xxxxxxxxx> wrote:
> >>>> Do you mean that the support for AF might vary across different CPUs?
> >>>> I'm not that familiar with arm64, so it seems a bit strange to me that
> >>>> such basic hardware features can differ so much from one CPU to another.
> >>>
> >>> Yes, hardware updates of the Access Flag is a per-CPU feature. It is
> >>> available for a CPU to use if TCR_EL1.HA is set. TCR_EL1 is a system
> >>> register; each CPU has its own. (Linux will always enable HW AF for a
> >>> CPU when it is onlined[1] if support is advertised, so we simply need
> >>> to check if support is advertised to know that it is in fact enabled.)
> >>>
> >>> These days it is not uncommon for a system to have two (or more?)
> >>> different core implementations, like with "fast" cores and "efficient"
> >>> cores.
> >>>
> >>> [1] See the CONFIG_ARM64_HW_AFDBM bits in arch/arm64/mm/proc.S
> >>
> >> Thanks for your detailed explanation. When enabling HVO via the cmdline,
> >> can we simply prevent CPUs that do not support AF from coming online?
> >> Would implementing it this way be much simpler? In practice, developers
> >> definitely know whether the current system is suitable for enabling HVO.
> >> If some CPUs do not support AF, they would just need to evaluate the
> >> trade-off between memory savings and having fewer online CPUs than expected.
> >>
> >> For scenarios where HVO is enabled via sysctl, we simply need to check
> >> if all CPUs support AF. If any do not, the system should return an error.
> >>
> >> Then, we can proceed with the Pre-HVO.
> >
> > I don't think it makes sense to try to implement pre-HVO.
> >
> > We cannot do HVO if any boot CPUs do not support HW AF, as HW AF will
> > be required to free the HugeTLB pages later, which we should continue
> > to support. Pre-HVO (today anyway) happens before all boot CPUs are
> > onlined. IMO it is not okay to prevent boot CPUs from onlining.
> >
> > Let's say for a moment that HVO cannot be toggled at run-time, then
> > the best we can do is:
> > - If a user does not specify hugetlb_free_vmemmap=1, we can always
> > allow onlining of late CPUs
> > - If a user specifies hugetlb_free_vmemmap=1 but not all boot CPUs
> > support HW AF, we can always allow onlining of late CPUs.
> > - If a user specifies hugetlb_free_vmemmap=1 and all boot CPUs support
> > HW AF, we must not allow onlining incompatible late CPUs.
> >
> > HVO compatibility has to be modeled as an Arm system feature. To
> > support conditional onlining of late CPUs based on whether or not "HVO
> > is being used", we still need the extra cpufeature.c logic.
> >
> > So if HVO cannot be toggled at run-time, we can simplify the
> > definition of "is HVO being used?" (for the purposes of determining if
> > late CPUs can be onlined). We can simplify it from what it is now
> > ("are there any optimized pages?") to
> > "vmemmap_optimize_enabled==true?". That allows us to drop patch 15
>
> I believe this conversion logic is sound. If a user proactively enables
> HVO via the command line, it clearly indicates they intend to use it.
> Otherwise, there would be no reason for them to enable it and then leave
> it idle.
>
> > (which then needs a slight change to patch 17), but that's about it.
> > So this is a slight simplification, which is nice.
> >
> > If you (or the Arm folks) feel strongly, I'm happy to write this simplification.
>
> I really like the simplification here. To keep this series as simple as
> possible for the first step, we also could focus strictly on bringing HVO
> support to ARM64 by making it depend entirely on BBML2_NOABORT. This keeps
> the initial scope highly contained, which should make it much easier to review.

Okay I'll do this then. I'll probably still include the BBML2_NOABORT
patches anyway, as I don't have access to any systems that have both
HW AF and BBML2_NOABORT / BBML3 (even with the expanded list[1]). I'll
continue to structure it where the series can be partially applied and
still be useful; i.e., the patches to drop the BBML2_NOABORT
dependency can be ignored.

[1] https://lore.kernel.org/linux-arm-kernel/20260708144331.679816-4-linu.cherian@xxxxxxx/