1. 18 Dec, 2017 1 commit
  2. 15 Dec, 2017 3 commits
    • Laurent Vivier's avatar
      spapr: don't initialize PATB entry if max-cpu-compat < power9 · b7d059b9
      Laurent Vivier authored
      
      
      if KVM is enabled and KVM capabilities MMU radix is available,
      the partition table entry (patb_entry) for the radix mode is
      initialized by default in ppc_spapr_reset().
      
      It's a problem if we want to migrate the guest to a POWER8 host
      while the kernel is not started to set the value to the one
      expected for a POWER8 CPU.
      
      The "-machine max-cpu-compat=power8" should allow to migrate
      a POWER9 KVM host to a POWER8 KVM host, but because patb_entry
      is set, the destination QEMU tries to enable radix mode on the
      POWER8 host. This fails and cancels the migration:
      
          Process table config unsupported by the host
          error while loading state for instance 0x0 of device 'spapr'
          load of migration failed: Invalid argument
      
      This patch doesn't set the PATB entry if the user provides
      a CPU compatibility mode that doesn't support radix mode.
      Signed-off-by: Laurent Vivier's avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      (cherry picked from commit 1481fe5f
      
      )
      Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      b7d059b9
    • Suraj Jitindar Singh's avatar
      target/ppc: Update setting of cpu features to account for compat modes · 2f3e3890
      Suraj Jitindar Singh authored
      
      
      The device tree nodes ibm,arch-vec-5-platform-support and ibm,pa-features
      are used to communicate features of the cpu to the guest operating
      system. The properties of each of these are determined based on the
      selected cpu model and the availability of hypervisor features.
      Currently the compatibility mode of the cpu is not taken into account.
      
      The ibm,arch-vec-5-platform-support node is used to communicate the
      level of support for various ISAv3 processor features to the guest
      before CAS to inform the guests' request. The available mmu mode should
      only be hash unless the cpu is a POWER9 which is not in a prePOWER9
      compat mode, in which case the available modes depend on the
      accelerator and the hypervisor capabilities.
      
      The ibm,pa-featues node is used to communicate the level of cpu support
      for various features to the guest os. This should only contain features
      relevant to the operating mode of the processor, that is the selected
      cpu model taking into account any compat mode. This means that the
      compat mode should be taken into account when choosing the properties of
      ibm,pa-features and they should match the compat mode selected, or the
      cpu model selected if no compat mode.
      
      Update the setting of these cpu features in the device tree as described
      above to properly take into account any compat mode. We use the
      ppc_check_compat function which takes into account the current processor
      model and the cpu compat mode.
      Signed-off-by: default avatarSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      (cherry picked from commit 7abd43ba
      
      )
      Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      2f3e3890
    • Alex Williamson's avatar
      vfio: Fix vfio-kvm group registration · 26c1b49d
      Alex Williamson authored
      Commit 8c37faa4 ("vfio-pci, ppc64/spapr: Reorder group-to-container
      attaching") moved registration of groups with the vfio-kvm device from
      vfio_get_group() to vfio_connect_container(), but it missed the case
      where a group is attached to an existing container and takes an early
      exit.  Perhaps this is a less common case on ppc64/spapr, but on x86
      (without viommu) all groups are connected to the same container and
      thus only the first group gets registered with the vfio-kvm device.
      This becomes a problem if we then hot-unplug the devices associated
      with that first group and we end up with KVM being misinformed about
      any vfio connections that might remain.  Fix by including the call to
      vfio_kvm_device_add_group() in this early exit path.
      
      Fixes: 8c37faa4
      
       ("vfio-pci, ppc64/spapr: Reorder group-to-container attaching")
      Cc: qemu-stable@nongnu.org # qemu-2.10+
      Reviewed-by: Alexey Kardashevskiy's avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Reviewed-by: Peter Xu's avatarPeter Xu <peterx@redhat.com>
      Tested-by: Peter Xu's avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: Eric Auger's avatarEric Auger <eric.auger@redhat.com>
      Tested-by: Eric Auger's avatarEric Auger <eric.auger@redhat.com>
      Signed-off-by: Alex Williamson's avatarAlex Williamson <alex.williamson@redhat.com>
      (cherry picked from commit 2016986a
      
      )
      Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      26c1b49d
  3. 07 Dec, 2017 1 commit
  4. 06 Dec, 2017 28 commits
  5. 05 Dec, 2017 7 commits