Skip to content
  1. Feb 24, 2018
  2. Feb 21, 2018
  3. Feb 16, 2018
    • Arnd Bergmann's avatar
      ARM: kvm: fix building with gcc-8 · 67870eb1
      Arnd Bergmann authored
      In banked-sr.c, we use a top-level '__asm__(".arch_extension virt")'
      statement to allow compilation of a multi-CPU kernel for ARMv6
      and older ARMv7-A that don't normally support access to the banked
      registers.
      
      This is considered to be a programming error by the gcc developers
      and will no longer work in gcc-8, where we now get a build error:
      
      /tmp/cc4Qy7GR.s:34: Error: Banked registers are not available with this architecture. -- `mrs r3,SP_usr'
      /tmp/cc4Qy7GR.s:41: Error: Banked registers are not available with this architecture. -- `mrs r3,ELR_hyp'
      /tmp/cc4Qy7GR.s:55: Error: Banked registers are not available with this architecture. -- `mrs r3,SP_svc'
      /tmp/cc4Qy7GR.s:62: Error: Banked registers are not available with this architecture. -- `mrs r3,LR_svc'
      /tmp/cc4Qy7GR.s:69: Error: Banked registers are not available with this architecture. -- `mrs r3,SPSR_svc'
      /tmp/cc4Qy7GR.s:76: Error: Banked registers are not available with this architecture. -- `mrs r3,SP_abt'
      
      Passign the '-march-armv7ve' flag to gcc works, and is ok here, because
      we know the functions won't ever be called on pre-ARMv7VE machines.
      Unfortunately, older compiler versions (4.8 and earlier) do not understand
      that flag, so we still need to keep the asm around.
      
      Backporting to stable kernels (4.6+) is needed to allow those to be built
      with future compilers as well.
      
      Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84129
      Fixes: 33280b4c
      
       ("ARM: KVM: Add banked registers save/restore")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      67870eb1
    • Christoffer Dall's avatar
      KVM: arm/arm64: Fix arch timers with userspace irqchips · d60d8b64
      Christoffer Dall authored
      
      
      When introducing support for irqchip in userspace we needed a way to
      mask the timer signal to prevent the guest continuously exiting due to a
      screaming timer.
      
      We did this by disabling the corresponding percpu interrupt on the
      host interrupt controller, because we cannot rely on the host system
      having a GIC, and therefore cannot make any assumptions about having an
      active state to hide the timer signal.
      
      Unfortunately, when introducing this feature, it became entirely
      possible that a VCPU which belongs to a VM that has a userspace irqchip
      can disable the vtimer irq on the host on some physical CPU, and then go
      away without ever enabling the vtimer irq on that physical CPU again.
      
      This means that using irqchips in userspace on a system that also
      supports running VMs with an in-kernel GIC can prevent forward progress
      from in-kernel GIC VMs.
      
      Later on, when we started taking virtual timer interrupts in the arch
      timer code, we would also leave this timer state active for userspace
      irqchip VMs, because we leave it up to a VGIC-enabled guest to
      deactivate the hardware IRQ using the HW bit in the LR.
      
      Both issues are solved by only using the enable/disable trick on systems
      that do not have a host GIC which supports the active state, because all
      VMs on such systems must use irqchips in userspace.  Systems that have a
      working GIC with support for an active state use the active state to
      mask the timer signal for both userspace and in-kernel irqchips.
      
      Cc: Alexander Graf <agraf@suse.de>
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Cc: <stable@vger.kernel.org> # v4.12+
      Fixes: d9e13977
      
       ("KVM: arm/arm64: Support arch timers with a userspace gic")
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      d60d8b64
  4. Feb 15, 2018
  5. Feb 14, 2018