qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] b96919: boot-serial-test: prefer tcg accelera


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] b96919: boot-serial-test: prefer tcg accelerator
Date: Wed, 23 Aug 2017 04:22:24 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: b96919d765a65f5e0f140479f7da0b94521263c6
      
https://github.com/qemu/qemu/commit/b96919d765a65f5e0f140479f7da0b94521263c6
  Author: Cornelia Huck <address@hidden>
  Date:   2017-08-22 (Tue, 22 Aug 2017)

  Changed paths:
    M tests/boot-serial-test.c

  Log Message:
  -----------
  boot-serial-test: prefer tcg accelerator

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: 480bc11e6 ("boot-serial-test: fallback to kvm accelerator")
Reported-by: Richard Henderson <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: c363a37a450f925df76b88a87dc733bad75cc452
      
https://github.com/qemu/qemu/commit/c363a37a450f925df76b88a87dc733bad75cc452
  Author: Daniel Henrique Barboza <address@hidden>
  Date:   2017-08-22 (Tue, 22 Aug 2017)

  Changed paths:
    M target/ppc/kvm.c
    M target/ppc/kvm_ppc.h
    M target/ppc/machine.c

  Log Message:
  -----------
  target/ppc: 'PVR != host PVR' in KVM_SET_SREGS workaround

Commit d5fc133eed ("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: Daniel Henrique Barboza <address@hidden>
[dwg: Fix for the case of using TCG on a PPC host]
Signed-off-by: David Gibson <address@hidden>


  Commit: 5dfaa532e0010c2dea50385c87683b0d756aa12f
      
https://github.com/qemu/qemu/commit/5dfaa532e0010c2dea50385c87683b0d756aa12f
  Author: Greg Kurz <address@hidden>
  Date:   2017-08-22 (Tue, 22 Aug 2017)

  Changed paths:
    M target/ppc/compat.c

  Log Message:
  -----------
  ppc: fix ppc_set_compat() with KVM PR

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 66d5c492dd3a9), 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: Greg Kurz <address@hidden>
Reviewed-by: Suraj Jitindar Singh <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 188bfe1b00360657c701cda2f97ce276add7e255
      
https://github.com/qemu/qemu/commit/188bfe1b00360657c701cda2f97ce276add7e255
  Author: Bharata B Rao <address@hidden>
  Date:   2017-08-22 (Tue, 22 Aug 2017)

  Changed paths:
    M hw/ppc/spapr_drc.c

  Log Message:
  -----------
  spapr: Allow configure-connector to be called multiple times

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 9d4c0f4f0a71e: "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: Bharata B Rao <address@hidden>
[dwg: Corrected buglet that would have initialized fdt pointers ready
 for reading on a device not present at reset]
Signed-off-by: David Gibson <address@hidden>


  Commit: 0479097859372a760843ad1b9c6ed3705c6423ca
      
https://github.com/qemu/qemu/commit/0479097859372a760843ad1b9c6ed3705c6423ca
  Author: Thomas Huth <address@hidden>
  Date:   2017-08-22 (Tue, 22 Aug 2017)

  Changed paths:
    M hw/i386/pc.c
    M hw/mem/nvdimm.c
    M hw/mem/pc-dimm.c
    M hw/ppc/spapr.c
    M include/hw/mem/pc-dimm.h

  Log Message:
  -----------
  hw/ppc/spapr: Fix segfault when instantiating a 'pc-dimm' without 'memdev'

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: Thomas Huth <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 8ccccff9dd7ba24c7a78861172e8dc6b07f1c392
      
https://github.com/qemu/qemu/commit/8ccccff9dd7ba24c7a78861172e8dc6b07f1c392
  Author: Thomas Huth <address@hidden>
  Date:   2017-08-22 (Tue, 22 Aug 2017)

  Changed paths:
    M hw/ppc/spapr_rtc.c

  Log Message:
  -----------
  hw/ppc/spapr_rtc: Mark the RTC device with user_creatable = false

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: Thomas Huth <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 1f98e55385d11da1dc0de6440e66f19d191d2a1b
      
https://github.com/qemu/qemu/commit/1f98e55385d11da1dc0de6440e66f19d191d2a1b
  Author: Thomas Huth <address@hidden>
  Date:   2017-08-22 (Tue, 22 Aug 2017)

  Changed paths:
    M hw/ppc/spapr_iommu.c

  Log Message:
  -----------
  hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device

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: Thomas Huth <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 56d7305db6d7c9b98c2bb44c53e67f1ec8336daa
      
https://github.com/qemu/qemu/commit/56d7305db6d7c9b98c2bb44c53e67f1ec8336daa
  Author: Peter Maydell <address@hidden>
  Date:   2017-08-23 (Wed, 23 Aug 2017)

  Changed paths:
    M hw/i386/pc.c
    M hw/mem/nvdimm.c
    M hw/mem/pc-dimm.c
    M hw/ppc/spapr.c
    M hw/ppc/spapr_drc.c
    M hw/ppc/spapr_iommu.c
    M hw/ppc/spapr_rtc.c
    M include/hw/mem/pc-dimm.h
    M target/ppc/compat.c
    M target/ppc/kvm.c
    M target/ppc/kvm_ppc.h
    M target/ppc/machine.c
    M tests/boot-serial-test.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.10-20170823' 
into staging

ppc patch queue 2017-08-23

This is identical to the pull request from yesterday (20180822),
except that a bug in one patch is fixed so that it doesn't break TCG
on a ppc host.

Last minute ppc related fixes for qemu-2.10.  I'm not sure if these
are critical enough to prompt another rc, but I'm submitting them for
consideration.

First, is Cornelia's fix for 480bc11e6 which meant "make check" would
always fail on a ppc host.  Tracking that down delayed submission of
the rest of these patches, sorry.

The rest are all fairly important bugfixes for qemu crashes or guest
behaviour regression on ppc.  Patches 2-4 specifically are fixes for
regressions from qemu-2.9, caused by the compatibility mode and
hotplug handling cleanups for the pseries machine type.

# gpg: Signature made Wed 23 Aug 2017 01:31:47 BST
# gpg:                using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <address@hidden>"
# gpg:                 aka "David Gibson (Red Hat) <address@hidden>"
# gpg:                 aka "David Gibson (ozlabs.org) <address@hidden>"
# gpg:                 aka "David Gibson (kernel.org) <address@hidden>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-2.10-20170823:
  hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device
  hw/ppc/spapr_rtc: Mark the RTC device with user_creatable = false
  hw/ppc/spapr: Fix segfault when instantiating a 'pc-dimm' without 'memdev'
  spapr: Allow configure-connector to be called multiple times
  ppc: fix ppc_set_compat() with KVM PR
  target/ppc: 'PVR != host PVR' in KVM_SET_SREGS workaround
  boot-serial-test: prefer tcg accelerator

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/1f2967338764...56d7305db6d7

reply via email to

[Prev in Thread] Current Thread [Next in Thread]