- a NV guest wants to trap these instructions: we need to correctly
route them.
- the access falls outside of a memslot, and userspace needs to handle
this.
This last point is of special interest. Instead of going through the
pain of doing all the decoding in the kernel and presenting the VMM
with a fully decoded access (like it is the case for normal MMIO), we
brutally return the ESR+IPA and let userspace deal with the outcome,
hijacking the data structures for KVM_EXIT_ARM_NISV for that purpose.
It has all the information at its disposal through the vcpu ioctl
interface, and can definitely do what's asked. Just not very quickly
I don't think this is a problem, and that approximately 100% of the
VMMs will simply inject an external abort as an indication that they
are not handling this.
This is otherwise pretty uninteresting code.
Marc Zyngier (11):
arm64: Expose ID_AA64ISAR1_EL1.XS to sanitised feature consumers
arm64: Add syndrome information for trapped LD64B/ST64B{,V,V0}
KVM: arm64: Add ACCDATA_EL1 to the sysreg array
KVM: arm64: Add context-switch of ACCDATA_EL1
KVM: arm64: Handle trapping of FEAT_LS64* instructions
KVM: arm64: Add exit to userspace on {LD,ST}64B* outside of memslots
KVM: arm64: Restrict ACCDATA_EL1 undef to FEAT_ST64_ACCDATA being
disabled
KVM: arm64: Conditionnaly enable FEAT_LS64* instructions
KVM: arm64: nv: Expose FEAT_LS64* to a nested guest
arm64: Expose ID_AA64ISAR1_EL1.LS64 to sanitised feature consumers
KVM: arm64: Add documentation for KVM_EXIT_ARM_LDST64B
Documentation/virt/kvm/api.rst | 43 ++++++++++++---
arch/arm64/include/asm/esr.h | 8 ++-
arch/arm64/include/asm/kvm_host.h | 3 +
arch/arm64/kernel/cpufeature.c | 2 +
arch/arm64/kvm/handle_exit.c | 64 ++++++++++++++++++++++
arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 29 ++++++++--
arch/arm64/kvm/mmio.c | 27 ++++++++-
arch/arm64/kvm/nested.c | 5 +-
arch/arm64/kvm/sys_regs.c | 25 ++++++++-
include/uapi/linux/kvm.h | 3 +-
10 files changed, 188 insertions(+), 21 deletions(-)
--
2.39.2
