-next boot failures during KVM setup

[Ard Biesheuvel]

Hi Fuad,

On Fri, 19 Jun 2026, at 17:01, Fuad Tabba wrote:
> 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/
>

Thanks for the report - I'll investigate. I imagine deferring the R/O remap
should help, but I'll try to reproduce locally and see what we can do about
this.