kernel/git/stable/linux.git/arch/arm/kvm, branch linux-3.14.y

arm/arm64: KVM: Enforce Break-Before-Make on Stage-2 page tables

2016-06-01T19:12:46+00:00

commit d4b9e0790aa764c0b01e18d4e8d33e93ba36d51f upstream. The ARM architecture mandates that when changing a page table entry from a valid entry to another valid entry, an invalid entry is first written, TLB invalidated, and only then the new entry being written. The current code doesn't respect this, directly writing the new entry and only then invalidating TLBs. Let's fix it up. Reported-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Greg Kroah-Hartman

arm64: KVM: Do not use pgd_index to index stage-2 pgd

2015-07-10T17:38:00+00:00

commit 04b8dc85bf4a64517e3cf20e409eeaa503b15cc1 upstream. [Since we don't backport commit c647355 (KVM: arm: Add initial dirty page locking support) for linux-3.14.y, there is no stage2_wp_range in arch/arm/kvm/mmu.c. So ignore the change in stage2_wp_range introduced by this patch.] The kernel's pgd_index macro is designed to index a normal, page sized array. KVM is a bit diffferent, as we can use concatenated pages to have a bigger address space (for example 40bit IPA with 4kB pages gives us an 8kB PGD. In the above case, the use of pgd_index will always return an index inside the first 4kB, which makes a guest that has memory above 0x8000000000 rather unhappy, as it spins forever in a page fault, whist the host happilly corrupts the lower pgd. The obvious fix is to get our own kvm_pgd_index that does the right thing(tm). Tested on X-Gene with a hacked kvmtool that put memory at a stupidly high address. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: Require in-kernel vgic for the arch timers

2015-07-10T17:38:00+00:00

commit 05971120fca43e0357789a14b3386bb56eef2201 upstream. [Note this patch is a bit different from the original one as the names of vgic_initialized and kvm_vgic_init are different.] It is curently possible to run a VM with architected timers support without creating an in-kernel VGIC, which will result in interrupts from the virtual timer going nowhere. To address this issue, move the architected timers initialization to the time when we run a VCPU for the first time, and then only initialize (and enable) the architected timers if we have a properly created and initialized in-kernel VGIC. When injecting interrupts from the virtual timer to the vgic, the current setup should ensure that this never calls an on-demand init of the VGIC, which is the only call path that could return an error from kvm_vgic_inject_irq(), so capture the return value and raise a warning if there's an error there. We also change the kvm_timer_init() function from returning an int to be a void function, since the function always succeeds. Reviewed-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

arm: KVM: force execution of HCPTR access on VM exit

2015-07-10T17:37:58+00:00

commit 85e84ba31039595995dae80b277378213602891b upstream. On VM entry, we disable access to the VFP registers in order to perform a lazy save/restore of these registers. On VM exit, we restore access, test if we did enable them before, and save/restore the guest/host registers if necessary. In this sequence, the FPEXC register is always accessed, irrespective of the trapping configuration. If the guest didn't touch the VFP registers, then the HCPTR access has now enabled such access, but we're missing a barrier to ensure architectural execution of the new HCPTR configuration. If the HCPTR access has been delayed/reordered, the subsequent access to FPEXC will cause a trap, which we aren't prepared to handle at all. The same condition exists when trapping to enable VFP for the guest. The fix is to introduce a barrier after enabling VFP access. In the vmexit case, it can be relaxed to only takes place if the guest hasn't accessed its view of the VFP registers, making the access to FPEXC safe. The set_hcptr macro is modified to deal with both vmenter/vmexit and vmtrap operations, and now takes an optional label that is branched to when the guest hasn't touched the VFP registers. Reported-by: Vikram Sethi Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: Don't allow creating VCPUs after vgic_initialized

2015-07-04T02:49:07+00:00

commit 716139df2517fbc3f2306dbe8eba0fa88dca0189 upstream. When the vgic initializes its internal state it does so based on the number of VCPUs available at the time. If we allow KVM to create more VCPUs after the VGIC has been initialized, we are likely to error out in unfortunate ways later, perform buffer overflows etc. Acked-by: Marc Zyngier Reviewed-by: Eric Auger Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: Introduce stage2_unmap_vm

2015-07-04T02:49:07+00:00

commit 957db105c99792ae8ef61ffc9ae77d910f6471da upstream. Introduce a new function to unmap user RAM regions in the stage2 page tables. This is needed on reboot (or when the guest turns off the MMU) to ensure we fault in pages again and make the dcache, RAM, and icache coherent. Using unmap_stage2_range for the whole guest physical range does not work, because that unmaps IO regions (such as the GIC) which will not be recreated or in the best case faulted in on a page-by-page basis. Call this function on secondary and subsequent calls to the KVM_ARM_VCPU_INIT ioctl so that a reset VCPU will detect the guest Stage-1 MMU is off when faulting in pages and make the caches coherent. Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: Reset the HCR on each vcpu when resetting the vcpu

2015-07-04T02:49:06+00:00

commit b856a59141b1066d3c896a0d0231f84dabd040af upstream. When userspace resets the vcpu using KVM_ARM_VCPU_INIT, we should also reset the HCR, because we now modify the HCR dynamically to enable/disable trapping of guest accesses to the VM registers. This is crucial for reboot of VMs working since otherwise we will not be doing the necessary cache maintenance operations when faulting in pages with the guest MMU off. Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: Correct KVM_ARM_VCPU_INIT power off option

2015-07-04T02:49:06+00:00

commit 3ad8b3de526a76fbe9466b366059e4958957b88f upstream. The implementation of KVM_ARM_VCPU_INIT is currently not doing what userspace expects, namely making sure that a vcpu which may have been turned off using PSCI is returned to its initial state, which would be powered on if userspace does not set the KVM_ARM_VCPU_POWER_OFF flag. Implement the expected functionality and clarify the ABI. Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: Don't clear the VCPU_POWER_OFF flag

2015-07-04T02:49:06+00:00

commit 03f1d4c17edb31b41b14ca3a749ae38d2dd6639d upstream. If a VCPU was originally started with power off (typically to be brought up by PSCI in SMP configurations), there is no need to clear the POWER_OFF flag in the kernel, as this flag is only tested during the init ioctl itself. Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

arm/arm64: kvm: drop inappropriate use of kvm_is_mmio_pfn()

2015-07-04T02:49:06+00:00

commit 07a9748c78cfc39b54f06125a216b67b9c8f09ed upstream. Instead of using kvm_is_mmio_pfn() to decide whether a host region should be stage 2 mapped with device attributes, add a new static function kvm_is_device_pfn() that disregards RAM pages with the reserved bit set, as those should usually not be mapped as device memory. Signed-off-by: Ard Biesheuvel Signed-off-by: Marc Zyngier Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman