1. 25 Sep, 2017 3 commits
  2. 24 Sep, 2017 1 commit
  3. 23 Sep, 2017 15 commits
  4. 13 Sep, 2017 1 commit
  5. 30 Aug, 2017 1 commit
  6. 24 Aug, 2017 1 commit
  7. 23 Aug, 2017 10 commits
  8. 22 Aug, 2017 7 commits
    • Thomas Huth's avatar
      hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device · 1f98e553
      Thomas Huth authored
      
      
      QEMU currently aborts unexpectedly when the user tries to add and
      remove a "spapr-tce-table" device:
      
      $ qemu-system-ppc64 -nographic -S -nodefaults -monitor stdio
      QEMU 2.9.92 monitor - type 'help' for more information
      (qemu) device_add spapr-tce-table,id=x
      (qemu) device_del x
      **
      ERROR:qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl)
      Aborted (core dumped)
      
      The device should not be accessable for the users at all, it's just
      used internally, so mark it with user_creatable = false.
      Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      1f98e553
    • Thomas Huth's avatar
      hw/ppc/spapr_rtc: Mark the RTC device with user_creatable = false · 8ccccff9
      Thomas Huth authored
      
      
      QEMU currently aborts unexpectedly when a user tries to do something
      like this:
      
      $ qemu-system-ppc64 -nographic -S -nodefaults -monitor stdio
      QEMU 2.9.92 monitor - type 'help' for more information
      (qemu) device_add spapr-rtc,id=spapr-rtc
      (qemu) device_del spapr-rtc
      **
      ERROR:qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl)
      Aborted (core dumped)
      
      The RTC device is not meant to be hot-pluggable - it's an internal
      device only and it even should not be possible to create it a
      second time with the "-device" parameter, so let's mark this
      with "user_creatable = false".
      Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      8ccccff9
    • Thomas Huth's avatar
      hw/ppc/spapr: Fix segfault when instantiating a 'pc-dimm' without 'memdev' · 04790978
      Thomas Huth authored
      
      
      QEMU currently crashes when trying to use a 'pc-dimm' on the pseries
      machine without specifying its 'memdev' property. This happens because
      pc_dimm_get_memory_region() does not check whether the 'memdev' property
      has properly been set by the user. Looking closer at this function, it's
      also obvious that it is using &error_abort to call another function - and
      this is bad in a function that is used in the hot-plugging calling chain
      since this can also cause QEMU to exit unexpectedly.
      
      So let's fix these issues in a proper way now: Add a "Error **errp"
      parameter to pc_dimm_get_memory_region() which we use in case the 'memdev'
      property has not been set by the user, and which we can use instead of
      the &error_abort, and change the callers of get_memory_region() to make
      use of this "errp" parameter for proper error checking.
      Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      Reviewed-by: default avatarIgor Mammedov <imammedo@redhat.com>
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      04790978
    • Bharata B Rao's avatar
      spapr: Allow configure-connector to be called multiple times · 188bfe1b
      Bharata B Rao authored
      In case of in-kernel memory hot unplug, when the guest is not able
      to remove all the LMBs that are requested for removal, it will add back
      any LMBs that have been successfully removed. The DR Connectors of
      these LMBs wouldn't have been unconfigured and hence the addition of
      these LMBs will result in configure-connector call being issued on
      LMB DR connectors that are already in configured state. Such
      configure-connector calls will fail resulting in a DIMM which is
      partially unplugged.
      
      This however worked till recently before we overhauled the DRC
      implementation in QEMU. Commit 9d4c0f4f
      
      : "spapr: Consolidate
      DRC state variables" is the first commit where this problem shows up
      as per git bisect.
      
      Ideally guest shouldn't be issuing configure-connector call on an
      already configured DR connector. However for now, work around this in
      QEMU by allowing configure-connector to be called multiple times for
      all types of DR connectors.
      Signed-off-by: default avatarBharata B Rao <bharata@linux.vnet.ibm.com>
      [dwg: Corrected buglet that would have initialized fdt pointers ready
       for reading on a device not present at reset]
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      188bfe1b
    • Greg Kurz's avatar
      ppc: fix ppc_set_compat() with KVM PR · 5dfaa532
      Greg Kurz authored
      When running in KVM PR mode, kvmppc_set_compat() always fail because the
      current PR implementation doesn't handle KVM_REG_PPC_ARCH_COMPAT. Now that
      the machine code inconditionally calls ppc_set_compat_all() at reset time
      to restore the compat mode default value (commit 66d5c492), it is
      impossible to start a guest with PR:
      
      qemu-system-ppc64: Unable to set CPU compatibility mode in KVM:
       Invalid argument
      
      A tentative patch [1] was recently sent by Suraj to address the issue, but
      it would prevent the compat mode to be turned off on reset. And we really
      don't want to explicitely check for KVM PR. During the patch's review,
      David suggested that we should only call the KVM ioctl() if the compat
      PVR changes. This allows at least to run with KVM PR, provided no compat
      mode is requested from the command line (which should be the case when
      running PR nested). This is what this patch does.
      
      While here, we also fix the side effect where KVM would fail but we would
      change the CPU state in QEMU anyway.
      
      [1] http://patchwork.ozlabs.org/patch/782039/
      
      Signed-off-by: default avatarGreg Kurz <groug@kaod.org>
      Reviewed-by: default avatarSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      5dfaa532
    • Daniel Henrique Barboza's avatar
      target/ppc: 'PVR != host PVR' in KVM_SET_SREGS workaround · c363a37a
      Daniel Henrique Barboza authored
      Commit d5fc133e ("ppc: Rework CPU compatibility testing
      across migration") changed the way cpu_post_load behaves with
      the PVR setting, causing an unexpected bug in KVM-HV migrations
      between hosts that are compatible (POWER8 and POWER8E, for example).
      Even with pvr_match() returning true, the guest freezes right after
      cpu_post_load. The reason is that the guest kernel can't handle a
      different PVR value other that the running host in KVM_SET_SREGS.
      
      In [1] it was discussed the possibility of a new KVM capability
      that would indicate that the guest kernel can handle a different
      PVR in KVM_SET_SREGS. Even if such feature is implemented, there is
      still the problem with older kernels that will not have this capability
      and will fail to migrate.
      
      This patch implements a workaround for that scenario. If running
      with KVM, check if the guest kernel does not have the capability
      (named here as 'cap_ppc_pvr_compat'). If it doesn't, calls
      kvmppc_is_pr() to see if the guest is running in KVM-HV. If all this
      happens, set env->spr[SPR_PVR] to the same value as the current
      host PVR. This ensures that we allow migrations with 'close enough'
      PVRs to still work in KVM-HV but also makes the code ready for
      this new KVM capability when it is done.
      
      A new function called 'kvmppc_pvr_workaround_required' was created
      to encapsulate the conditions said above and to avoid calling too
      many kvm.c internals inside cpu_post_load.
      
      [1] https://lists.gnu.org/archive/html/qemu-ppc/2017-06/msg00503.html
      
      Signed-off-by: default avatarDaniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
      [dwg: Fix for the case of using TCG on a PPC host]
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      c363a37a
    • Cornelia Huck's avatar
      boot-serial-test: prefer tcg accelerator · b96919d7
      Cornelia Huck authored
      Prefer to use the tcg accelarator if it is available: This is our only
      real smoke test for tcg, and fast enough to use it for that.
      
      Fixes: 480bc11e
      
       ("boot-serial-test: fallback to kvm accelerator")
      Reported-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      Signed-off-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      b96919d7
  9. 15 Aug, 2017 1 commit