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 documents the slightly odd behaviour of PTW writes to
RO memslot, which do not result in a KVM_MMIO exit. 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 v6.1-rc2.
I plan to take this in as a fix shortly.
M.
* From v1:
- Added the documentation patch
- Dropped the AF micro-optimisation, as it was creating more
confusion, was hard to test, and was of dubious value
- Collected RBs, with thanks
Marc Zyngier (3):
KVM: arm64: Fix S1PTW handling on RO memslots
KVM: arm64: Document the behaviour of S1PTW faults on RO memslots
KVM: arm64: Convert FSC_* over to ESR_ELx_FSC_*
Documentation/virt/kvm/api.rst | 8 +++++
arch/arm64/include/asm/esr.h | 9 ++++++
arch/arm64/include/asm/kvm_arm.h | 15 ---------
arch/arm64/include/asm/kvm_emulate.h | 42 ++++++++++++++++++-------
arch/arm64/kvm/hyp/include/hyp/fault.h | 2 +-
arch/arm64/kvm/hyp/include/hyp/switch.h | 2 +-
arch/arm64/kvm/mmu.c | 21 +++++++------
7 files changed, 61 insertions(+), 38 deletions(-)
--
2.34.1
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
