1. 28 Sep, 2020 17 commits
  2. 22 Sep, 2020 5 commits
  3. 20 Sep, 2020 3 commits
  4. 18 Sep, 2020 2 commits
  5. 17 Sep, 2020 3 commits
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Set LPCR[HDICE] before writing HDEC · 35dfb43c
      Paul Mackerras authored
      POWER8 and POWER9 machines have a hardware deviation where generation
      of a hypervisor decrementer exception is suppressed if the HDICE bit
      in the LPCR register is 0 at the time when the HDEC register
      decrements from 0 to -1.  When entering a guest, KVM first writes the
      HDEC register with the time until it wants the CPU to exit the guest,
      and then writes the LPCR with the guest value, which includes
      HDICE = 1.  If HDEC decrements from 0 to -1 during the interval
      between those two events, it is possible that we can enter the guest
      with HDEC already negative but no HDEC exception pending, meaning that
      no HDEC interrupt will occur while the CPU is in the guest, or at
      least not until HDEC wraps around.  Thus it is possible for the CPU to
      keep executing in the guest for a long time; up to about 4 seconds on
      POWER8, or about 4.46 years on POWER9 (except that the host kernel
      hard lockup detector will fire first).
      
      To fix this, we set the LPCR[HDICE] bit before writing HDEC on guest
      entry.
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      35dfb43c
    • Fabiano Rosas's avatar
      KVM: PPC: Book3S HV: Do not allocate HPT for a nested guest · 05e6295d
      Fabiano Rosas authored
      The current nested KVM code does not support HPT guests. This is
      informed/enforced in some ways:
      
      - Hosts < P9 will not be able to enable the nested HV feature;
      
      - The nested hypervisor MMU capabilities will not contain
        KVM_CAP_PPC_MMU_HASH_V3;
      
      - QEMU reflects the MMU capabilities in the
        'ibm,arch-vec-5-platform-support' device-tree property;
      
      - The nested guest, at 'prom_parse_mmu_model' ignores the
        'disable_radix' kernel command line option if HPT is not supported;
      
      - The KVM_PPC_CONFIGURE_V3_MMU ioctl will fail if trying to use HPT.
      
      There is, however, still a way to start a HPT guest by using
      max-compat-cpu=power8 at the QEMU machine options. This leads to the
      guest being set to use hash after QEMU calls the KVM_PPC_ALLOCATE_HTAB
      ioctl.
      
      With the guest set to hash, the nested hypervisor goes through the
      entry path that has no knowledge of nesting (kvmppc_run_vcpu) and
      crashes when it tries to execute an hypervisor-privileged (mtspr
      HDEC) instruction at __kvmppc_vcore_entry:
      
      root@L1:~ $ qemu-system-ppc64 -machine pseries,max-cpu-compat=power8 ...
      
      <snip>
      [  538.543303] CPU: 83 PID: 25185 Comm: CPU 0/KVM Not tainted 5.9.0-rc4 #1
      [  538.543355] NIP:  c00800000753f388 LR: c00800000753f368 CTR: c0000000001e5ec0
      [  538.543417] REGS: c0000013e91e33b0 TRAP: 0700   Not tainted  (5.9.0-rc4)
      [  538.543470] MSR:  8000000002843033 <SF,VEC,VSX,FP,ME,IR,DR,RI,LE>  CR: 22422882  XER: 20040000
      [  538.543546] CFAR: c00800000753f4b0 IRQMASK: 3
                     GPR00: c0080000075397a0 c0000013e91e3640 c00800000755e600 0000000080000000
                     GPR04: 0000000000000000 c0000013eab19800 c000001394de0000 00000043a054db72
                     GPR08: 00000000003b1652 0000000000000000 0000000000000000 c0080000075502e0
                     GPR12: c0000000001e5ec0 c0000007ffa74200 c0000013eab19800 0000000000000008
                     GPR16: 0000000000000000 c00000139676c6c0 c000000001d23948 c0000013e91e38b8
                     GPR20: 0000000000000053 0000000000000000 0000000000000001 0000000000000000
                     GPR24: 0000000000000001 0000000000000001 0000000000000000 0000000000000001
                     GPR28: 0000000000000001 0000000000000053 c0000013eab19800 0000000000000001
      [  538.544067] NIP [c00800000753f388] __kvmppc_vcore_entry+0x90/0x104 [kvm_hv]
      [  538.544121] LR [c00800000753f368] __kvmppc_vcore_entry+0x70/0x104 [kvm_hv]
      [  538.544173] Call Trace:
      [  538.544196] [c0000013e91e3640] [c0000013e91e3680] 0xc0000013e91e3680 (unreliable)
      [  538.544260] [c0000013e91e3820] [c0080000075397a0] kvmppc_run_core+0xbc8/0x19d0 [kvm_hv]
      [  538.544325] [c0000013e91e39e0] [c00800000753d99c] kvmppc_vcpu_run_hv+0x404/0xc00 [kvm_hv]
      [  538.544394] [c0000013e91e3ad0] [c0080000072da4fc] kvmppc_vcpu_run+0x34/0x48 [kvm]
      [  538.544472] [c0000013e91e3af0] [c0080000072d61b8] kvm_arch_vcpu_ioctl_run+0x310/0x420 [kvm]
      [  538.544539] [c0000013e91e3b80] [c0080000072c7450] kvm_vcpu_ioctl+0x298/0x778 [kvm]
      [  538.544605] [c0000013e91e3ce0] [c0000000004b8c2c] sys_ioctl+0x1dc/0xc90
      [  538.544662] [c0000013e91e3dc0] [c00000000002f9a4] system_call_exception+0xe4/0x1c0
      [  538.544726] [c0000013e91e3e20] [c00000000000d140] system_call_common+0xf0/0x27c
      [  538.544787] Instruction dump:
      [  538.544821] f86d1098 60000000 60000000 48000099 e8ad0fe8 e8c500a0 e9264140 75290002
      [  538.544886] 7d1602a6 7cec42a6 40820008 7d0807b4 <7d164ba6> 7d083a14 f90d10a0 480104fd
      [  538.544953] ---[ end trace 74423e2b948c2e0c ]---
      
      This patch makes the KVM_PPC_ALLOCATE_HTAB ioctl fail when running in
      the nested hypervisor, causing QEMU to abort.
      Reported-by: default avatarSatheesh Rajendran <sathnaga@linux.vnet.ibm.com>
      Signed-off-by: default avatarFabiano Rosas <farosas@linux.ibm.com>
      Reviewed-by: default avatarGreg Kurz <groug@kaod.org>
      Reviewed-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      05e6295d
    • Greg Kurz's avatar
      KVM: PPC: Don't return -ENOTSUPP to userspace in ioctls · 4e1b2ab7
      Greg Kurz authored
      ENOTSUPP is a linux only thingy, the value of which is unknown to
      userspace, not to be confused with ENOTSUP which linux maps to
      EOPNOTSUPP, as permitted by POSIX [1]:
      
      [EOPNOTSUPP]
      Operation not supported on socket. The type of socket (address family
      or protocol) does not support the requested operation. A conforming
      implementation may assign the same values for [EOPNOTSUPP] and [ENOTSUP].
      
      Return -EOPNOTSUPP instead of -ENOTSUPP for the following ioctls:
      - KVM_GET_FPU for Book3s and BookE
      - KVM_SET_FPU for Book3s and BookE
      - KVM_GET_DIRTY_LOG for BookE
      
      This doesn't affect QEMU which doesn't call the KVM_GET_FPU and
      KVM_SET_FPU ioctls on POWER anyway since they are not supported,
      and _buggily_ ignores anything but -EPERM for KVM_GET_DIRTY_LOG.
      
      [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.htmlSigned-off-by: default avatarGreg Kurz <groug@kaod.org>
      Acked-by: default avatarThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      4e1b2ab7
  6. 14 Sep, 2020 1 commit
  7. 12 Sep, 2020 8 commits
  8. 11 Sep, 2020 1 commit