user/sven/linux.git, branch v3.14.43

Linux 3.14.43

2015-05-17T16:54:01Z

kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform

2015-05-17T16:53:52Z

commit 63afbe7a0ac184ef8485dac4914e87b211b5bfaa upstream. If the physical address of GICV isn't page-aligned, then we end up creating a stage-2 mapping of the page containing it, which causes us to map neighbouring memory locations directly into the guest. As an example, consider a platform with GICV at physical 0x2c02f000 running a 64k-page host kernel. If qemu maps this into the guest at 0x80010000, then guest physical addresses 0x80010000 - 0x8001efff will map host physical region 0x2c020000 - 0x2c02efff. Accesses to these physical regions may cause UNPREDICTABLE behaviour, for example, on the Juno platform this will cause an SError exception to EL3, which brings down the entire physical CPU resulting in RCU stalls / HYP panics / host crashing / wasted weeks of debugging. SBSA recommends that systems alias the 4k GICV across the bounding 64k region, in which case GICV physical could be described as 0x2c020000 in the above scenario. This patch fixes the problem by failing the vgic probe if the physical base address or the size of GICV aren't page-aligned. Note that this generated a warning in dmesg about freeing enabled IRQs, so I had to move the IRQ enabling later in the probe. Cc: Christoffer Dall Cc: Marc Zyngier Cc: Gleb Natapov Cc: Paolo Bonzini Cc: Joel Schopp Cc: Don Dutile Acked-by: Peter Maydell Acked-by: Joel Schopp Acked-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Christoffer Dall Cc: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

arm64: kvm: use inner-shareable barriers for inner-shareable maintenance

2015-05-17T16:53:52Z

commit ee9e101c11478680d579bd20bb38a4d3e2514fe3 upstream. In order to ensure completion of inner-shareable maintenance instructions (cache and TLB) on AArch64, we can use the -ish suffix to the dsb instruction. This patch relaxes our dsb sy instructions to dsb ish where possible. Acked-by: Catalin Marinas Acked-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Cc: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

KVM: ARM: vgic: Fix the overlap check action about setting the GICD & GICC base address.

2015-05-17T16:53:52Z

commit 30c2117085bc4e05d091cee6eba79f069b41a9cd upstream. Currently below check in vgic_ioaddr_overlap will always succeed, because the vgic dist base and vgic cpu base are still kept UNDEF after initialization. The code as follows will be return forever. if (IS_VGIC_ADDR_UNDEF(dist) || IS_VGIC_ADDR_UNDEF(cpu)) return 0; So, before invoking the vgic_ioaddr_overlap, it needs to set the corresponding base address firstly. Signed-off-by: Haibin Wang Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Cc: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

KVM: arm/arm64: vgic: fix GICD_ICFGR register accesses

2015-05-17T16:53:52Z

commit f2ae85b2ab3776b9e4e42e5b6fa090f40d396794 upstream. Since KVM internally represents the ICFGR registers by stuffing two of them into one word, the offset for accessing the internal representation and the one for the MMIO based access are different. So keep the original offset around, but adjust the internal array offset by one bit. Reported-by: Haibin Wang Signed-off-by: Andre Przywara Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall Cc: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

ARM: KVM: trap VM system registers until MMU and caches are ON

2015-05-17T16:53:52Z

commit 8034699a42d68043b495c7e0cfafccd920707ec8 upstream. In order to be able to detect the point where the guest enables its MMU and caches, trap all the VM related system registers. Once we see the guest enabling both the MMU and the caches, we can go back to a saner mode of operation, which is to leave these registers in complete control of the guest. Signed-off-by: Marc Zyngier Acked-by: Catalin Marinas Reviewed-by: Christoffer Dall Cc: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

ARM: KVM: add world-switch for AMAIR{0,1}

2015-05-17T16:53:52Z

commit af20814ee927ed888288d98917a766b4179c4fe0 upstream. HCR.TVM traps (among other things) accesses to AMAIR0 and AMAIR1. In order to minimise the amount of surprise a guest could generate by trying to access these registers with caches off, add them to the list of registers we switch/handle. Signed-off-by: Marc Zyngier Reviewed-by: Christoffer Dall Acked-by: Catalin Marinas Cc: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

ARM: KVM: introduce per-vcpu HYP Configuration Register

2015-05-17T16:53:52Z

commit ac30a11e8e92a03dbe236b285c5cbae0bf563141 upstream. So far, KVM/ARM used a fixed HCR configuration per guest, except for the VI/VF/VA bits to control the interrupt in absence of VGIC. With the upcoming need to dynamically reconfigure trapping, it becomes necessary to allow the HCR to be changed on a per-vcpu basis. The fix here is to mimic what KVM/arm64 already does: a per vcpu HCR field, initialized at setup time. Signed-off-by: Marc Zyngier Reviewed-by: Christoffer Dall Acked-by: Catalin Marinas Cc: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

ARM: KVM: fix ordering of 64bit coprocessor accesses

2015-05-17T16:53:52Z

commit 547f781378a22b65c2ab468f235c23001b5924da upstream. Commit 240e99cbd00a (ARM: KVM: Fix 64-bit coprocessor handling) added an ordering dependency for the 64bit registers. The order described is: CRn, CRm, Op1, Op2, 64bit-first. Unfortunately, the implementation is: CRn, 64bit-first, CRm... Move the 64bit test to be last in order to match the documentation. Signed-off-by: Marc Zyngier Reviewed-by: Christoffer Dall Acked-by: Catalin Marinas Cc: Shannon Zhao Signed-off-by: Greg Kroah-Hartman

ARM: KVM: fix handling of trapped 64bit coprocessor accesses

2015-05-17T16:53:52Z

commit 46c214dd595381c880794413facadfa07fba5c95 upstream. Commit 240e99cbd00a (ARM: KVM: Fix 64-bit coprocessor handling) changed the way we match the 64bit coprocessor access from user space, but didn't update the trap handler for the same set of registers. The effect is that a trapped 64bit access is never matched, leading to a fault being injected into the guest. This went unnoticed as we didn't really trap any 64bit register so far. Placing the CRm field of the access into the CRn field of the matching structure fixes the problem. Also update the debug feature to emit the expected string in case of failing match. Signed-off-by: Marc Zyngier Reviewed-by: Christoffer Dall Acked-by: Catalin Marinas Cc: Shannon Zhao Signed-off-by: Greg Kroah-Hartman