Recent developments on the EFI front have resulted in guests that simply won't boot if the page tables are in a read-only memslot and that you're a bit unlucky in the way S2 gets paged in... The core issue is related to the fact that we treat a S1PTW as a write, which is close enough to what needs to be done. Until to get to RO memslots. The first patch fixes this and is definitely a stable candidate. It splits the faulting of page tables in two steps (RO translation fault, followed by a writable permission fault -- should it even happen). The second one is a potential optimisation. I'm not even sure it is worth it. The last patch is totally optional, only tangentially related, and randomly repainting stuff (maybe that's contagious, who knows). The whole thing is on top of Linus' tree as of today. The reason for this very random choice is that there is a patch in v6.1-rc7 that hides the problem, and that patch is reverted in rc8 (see commit 0ba09b1733878afe838fe35c310715fda3d46428). I also wanted to avoid conflicts with kvmarm/next, so here you go. I've tested the series on A55, M1 and M2. The original issue seems to trigger best with 16kB pages, so please test with *other* page sizes! M. Marc Zyngier (3): KVM: arm64: Fix S1PTW handling on RO memslots KVM: arm64: Handle S1PTW translation with TCR_HA set as a write KVM: arm64: Convert FSC_* over to ESR_ELx_FSC_* arch/arm64/include/asm/esr.h | 9 ++++ arch/arm64/include/asm/kvm_arm.h | 15 ------- arch/arm64/include/asm/kvm_emulate.h | 60 ++++++++++++++++++++----- arch/arm64/kvm/hyp/include/hyp/fault.h | 2 +- arch/arm64/kvm/hyp/include/hyp/switch.h | 2 +- arch/arm64/kvm/mmu.c | 21 +++++---- 6 files changed, 71 insertions(+), 38 deletions(-) -- 2.34.1 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
