summaryrefslogtreecommitdiffstats
path: root/arch/arm64/include/asm/kvm_host.h
diff options
context:
space:
mode:
authorMarc Zyngier2016-01-29 16:01:28 +0100
committerMarc Zyngier2016-02-29 19:34:15 +0100
commit57c841f131ef295b583365d2fddd6b0d16e82c10 (patch)
treee015fcf1eccbcc2d01f87762cddb29738e1a3bf8 /arch/arm64/include/asm/kvm_host.h
parentARM: KVM: Remove __kvm_hyp_exit/__kvm_hyp_exit_end (diff)
downloadkernel-qcow2-linux-57c841f131ef295b583365d2fddd6b0d16e82c10.tar.gz
kernel-qcow2-linux-57c841f131ef295b583365d2fddd6b0d16e82c10.tar.xz
kernel-qcow2-linux-57c841f131ef295b583365d2fddd6b0d16e82c10.zip
arm/arm64: KVM: Handle out-of-RAM cache maintenance as a NOP
So far, our handling of cache maintenance by VA has been pretty simple: Either the access is in the guest RAM and generates a S2 fault, which results in the page being mapped RW, or we go down the io_mem_abort() path, and nuke the guest. The first one is fine, but the second one is extremely weird. Treating the CM as an I/O is wrong, and nothing in the ARM ARM indicates that we should generate a fault for something that cannot end-up in the cache anyway (even if the guest maps it, it will keep on faulting at stage-2 for emulation). So let's just skip this instruction, and let the guest get away with it. Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Diffstat (limited to 'arch/arm64/include/asm/kvm_host.h')
0 files changed, 0 insertions, 0 deletions