On Fri, Jul 10, 2026 at 7:23 PM Muchun Song [off-list ref] wrote:

quoted

On Jul 10, 2026, at 03:04, James Houghton [off-list ref] wrote:

On Thu, Jul 9, 2026 at 2:55 AM Muchun Song [off-list ref] wrote:

quoted

quoted

On Jul 9, 2026, at 00:49, James Houghton [off-list ref] wrote:

On Wed, Jul 8, 2026 at 1:41 AM Muchun Song [off-list ref] wrote:

quoted

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.

quoted

(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@arm.com/ (local)