-next boot failures during KVM setup

[Fuad Tabba]

Hi,

On Wed, 10 Jun 2026 at 11:42, Will Deacon <will at kernel.org> wrote:
>
> On Mon, Jun 08, 2026 at 10:56:12PM +0200, Ard Biesheuvel wrote:
> > Given we're at -rc7, I'd lean towards dropping the whole branch for now, or
> > alternatively, only drop/revert "arm64: mm: Unmap kernel data/bss entirely from the
> > linear map" (and its followup fix "arm64: mm: Defer remap of linear alias of
> > data/bss") so that the region always remains readable via the linear map.
>
> I've reverted those two locally, thanks! I'll push some new branches
> shortly.

I hit an nVHE boot regression on v7.2 while testing Will's kvmtool
protected-VM series [1]. I found this thread while debugging, and
thought this might help. Note that Gemini helped me debug this (it's
pretty good at debugging).

f2ba877 (the read-only mapping you kept) still breaks nVHE, but only with
CONFIG_NVHE_EL2_DEBUG / CONFIG_NVHE_EL2_TRACING:

  Unable to handle kernel write to read-only memory ... (ESR 0x9600004f)
  pc : kvm_apply_hyp_relocations+0x80/0x8c

kvm_apply_hyp_relocations() writes the .hyp.reloc fixups via lm_alias().
Most are in .hyp.rodata (whose alias isn't made read-only until
mark_linear_text_alias_ro(), after the relocs), but five land in .hyp.data
and now fault. They're all debug-only: __kvm_nvhe_selftest_vm/_vcpu
(NVHE_EL2_DEBUG) and __kvm_nvhe_trace_buffer (NVHE_EL2_TRACING). A default
config has none in .hyp.data and boots, which is why this didn't show up
earlier. VHE skips the relocations entirely.

[1] https://lore.kernel.org/all/20260619115415.5475-1-will@kernel.org/

Cheers,
/fuad

> Will
>
>