[Qemu-commits] [qemu/qemu] 454590: pseries: fix migration-test and pxe-test

[Peter Maydell]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 454590916caacef2c779351f6c79d1c448bb6f38
      
https://github.com/qemu/qemu/commit/454590916caacef2c779351f6c79d1c448bb6f38
  Author: Laurent Vivier <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M tests/migration-test.c
    M tests/pxe-test.c

  Log Message:
  -----------
  pseries: fix migration-test and pxe-test

Commit 29cb4187497d ("spapr: Set VSMT to smp_threads by default")
has introduced a new default value for VSMT that is not supported
by old kernels (before 4.13 kernel) and this breaks "make check"
on these kernels.

To fix that, explicitly set in the involved tests the value that was
used as the default value before the change.

Cc: Greg Kurz <address@hidden>
Signed-off-by: Laurent Vivier <address@hidden>
Message-Id: <address@hidden>
Acked-by: Thomas Huth <address@hidden>
Reviewed-by: Juan Quintela <address@hidden>
Tested-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 3607715a308d94b8c4797d23620e268a4c5bebf6
      
https://github.com/qemu/qemu/commit/3607715a308d94b8c4797d23620e268a4c5bebf6
  Author: David Gibson <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M accel/kvm/kvm-all.c
    M accel/stubs/kvm-stub.c
    M include/sysemu/kvm.h

  Log Message:
  -----------
  kvm: Introduce KVM irqchip change notifier

Awareness of an in kernel irqchip is usually local to the machine and its
top-level interrupt controller.  However, in a few cases other things need
to know about it.  In particular vfio devices need this in order to
accelerate interrupt delivery.

If interrupt routing is changed, such devices may need to readjust their
connection to the KVM irqchip.  pci_bus_fire_intx_routing_notifier() exists
to do just this.

However, for the pseries machine type we have a situation where the routing
remains constant but the top-level irq chip itself is changed.  This occurs
because of PAPR feature negotiation which allows the guest to decide
between the older XICS and newer XIVE irq chip models (both of which are
paravirtualized).

To allow devices like vfio to adjust to this change, introduce a new
notifier for the purpose kvm_irqchip_change_notify().

Cc: Alex Williamson <address@hidden>
Cc: Alexey Kardashevskiy <address@hidden>

Signed-off-by: David Gibson <address@hidden>
Tested-by: Alex Williamson <address@hidden>
Reviewed-by: Alex Williamson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Acked-by: Alex Williamson <address@hidden>


  Commit: ad54dbd89d7142c00669f8b6f4806c92ab468b45
      
https://github.com/qemu/qemu/commit/ad54dbd89d7142c00669f8b6f4806c92ab468b45
  Author: David Gibson <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M hw/vfio/pci.c

  Log Message:
  -----------
  vfio/pci: Split vfio_intx_update()

This splits the vfio_intx_update() function into one part doing the actual
reconnection with the KVM irqchip (vfio_intx_update(), now taking an
argument with the new routing) and vfio_intx_routing_notifier() which
handles calls to the pci device intx routing notifier and calling
vfio_intx_update() when necessary.  This will make adding support for the
irqchip change notifier easier.

Cc: Alex Williamson <address@hidden>
Cc: Alexey Kardashevskiy <address@hidden>

Signed-off-by: David Gibson <address@hidden>
Tested-by: Alex Williamson <address@hidden>
Reviewed-by: Alex Williamson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Acked-by: Alex Williamson <address@hidden>


  Commit: c5478fea27ac47ed3b57e0489a49b62f36024763
      
https://github.com/qemu/qemu/commit/c5478fea27ac47ed3b57e0489a49b62f36024763
  Author: David Gibson <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M hw/vfio/pci.c
    M hw/vfio/pci.h

  Log Message:
  -----------
  vfio/pci: Respond to KVM irqchip change notifier

VFIO PCI devices already respond to the pci intx routing notifier, in order
to update kernel irqchip mappings when routing is updated.  However this
won't handle the case where the irqchip itself is replaced by a different
model while retaining the same routing.  This case can happen on
the pseries machine type due to PAPR feature negotiation.

To handle that case, add a handler for the irqchip change notifier, which
does much the same thing as the routing notifier, but is unconditional,
rather than being a no-op when the routing hasn't changed.

Cc: Alex Williamson <address@hidden>
Cc: Alexey Kardashevskiy <address@hidden>

Signed-off-by: David Gibson <address@hidden>
Tested-by: Alex Williamson <address@hidden>
Reviewed-by: Alex Williamson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Acked-by: Alex Williamson <address@hidden>


  Commit: e532e1d93c4bd869b11db6ee0de2057e7d288889
      
https://github.com/qemu/qemu/commit/e532e1d93c4bd869b11db6ee0de2057e7d288889
  Author: David Gibson <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M hw/ppc/spapr_irq.c

  Log Message:
  -----------
  spapr: Handle irq backend changes with VFIO PCI devices

pseries machine type can have one of two different interrupt controllers in
use depending on feature negotiation with the guest.  Usually this is
invisible to devices, because they route to a common set of qemu_irqs which
in turn dispatch to the correct back end.

VFIO passthrough devices, however, wire themselves up directly to the KVM
irqchip for performance, which means they are affected by this change in
interrupt controller.  To get them to adjust correctly for the change in
irqchip, we need to fire the kvm irqchip change notifier.

Cc: Alex Williamson <address@hidden>
Cc: Alexey Kardashevskiy <address@hidden>

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
Tested-by: Alex Williamson <address@hidden>
Reviewed-by: Alex Williamson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Acked-by: Alex Williamson <address@hidden>


  Commit: b14848f5d757cbe89dfd1ee68ce701a8277c2f17
      
https://github.com/qemu/qemu/commit/b14848f5d757cbe89dfd1ee68ce701a8277c2f17
  Author: David Gibson <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M hw/ppc/spapr_irq.c

  Log Message:
  -----------
  spapr: Work around spurious warnings from vfio INTx initialization

Traditional PCI INTx for vfio devices can only perform well if using
an in-kernel irqchip.  Therefore, vfio_intx_update() issues a warning
if an in kernel irqchip is not available.

We usually do have an in-kernel irqchip available for pseries machines
on POWER hosts.  However, because the platform allows feature
negotiation of what interrupt controller model to use, we don't
currently initialize it until machine reset.  vfio_intx_update() is
called (first) from vfio_realize() before that, so it can issue a
spurious warning, even if we will have an in kernel irqchip by the
time we need it.

To workaround this, make a call to spapr_irq_update_active_intc() from
spapr_irq_init() which is called at machine realize time, before the
vfio realize.  This call will be pretty much obsoleted by the later
call at reset time, but it serves to suppress the spurious warning
from VFIO.

Cc: Alex Williamson <address@hidden>
Cc: Alexey Kardashevskiy <address@hidden>

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
Tested-by: Alex Williamson <address@hidden>
Reviewed-by: Alex Williamson <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Acked-by: Alex Williamson <address@hidden>


  Commit: 6cf80f90c441e86f2e92c8a07d6b29ca3f1d43e8
      
https://github.com/qemu/qemu/commit/6cf80f90c441e86f2e92c8a07d6b29ca3f1d43e8
  Author: Laurent Vivier <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M hw/misc/mos6522.c

  Log Message:
  -----------
  mos6522: update counters when timer interrupts are off

Even if the interrupts are off, counters must be updated because
they are running anyway and kernel can try to read them
(it's the case with g3beige kernel).

Reported-by: Andrew Randrianasulu <address@hidden>
Signed-off-by: Laurent Vivier <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: 59d0533b85158fdbe43bad696d4f50ec29a04c32
      
https://github.com/qemu/qemu/commit/59d0533b85158fdbe43bad696d4f50ec29a04c32
  Author: PanNengyuan <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M hw/ppc/spapr_events.c

  Log Message:
  -----------
  ppc/spapr_events: fix potential NULL pointer dereference in 
rtas_event_log_dequeue

This fixes coverity issues 68911917:
        360
    CID 68911917: (NULL_RETURNS)
        361. dereference: Dereferencing "source", which is known to be
             "NULL".
        361        if (source->mask & event_mask) {
        362            break;
        363        }

Reported-by: Euler Robot <address@hidden>
Signed-off-by: PanNengyuan <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>


  Commit: a0aaca7e9cd9f31f848c0f0bb204de675ff9b578
      
https://github.com/qemu/qemu/commit/a0aaca7e9cd9f31f848c0f0bb204de675ff9b578
  Author: Peter Maydell <address@hidden>
  Date:   2019-11-26 (Tue, 26 Nov 2019)

  Changed paths:
    M accel/kvm/kvm-all.c
    M accel/stubs/kvm-stub.c
    M hw/misc/mos6522.c
    M hw/ppc/spapr_events.c
    M hw/ppc/spapr_irq.c
    M hw/vfio/pci.c
    M hw/vfio/pci.h
    M include/sysemu/kvm.h
    M tests/migration-test.c
    M tests/pxe-test.c

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

ppc patch queue for 2019-11-26

Here's the first 4.2 hard freeze pull request from me.  This has:

  * A fix for some testcases that cause errors on older host kernels
    (e.g. RHEL7), with our new default configuration of VSMT mode
  * Changes to make VFIO devices interact properly with change of irq
    chip caused by PAPR feature negotiation.  This is more involved
    than I would like, but it's a problem in real use cases and I
    can't see an easier way to handle it.
  * Fix an error with ms6522 counters for the g3beige machine
  * Fix a coverity warning

# gpg: Signature made Tue 26 Nov 2019 05:52:16 GMT
# gpg:                using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
# gpg: Good signature from "David Gibson <address@hidden>" [full]
# gpg:                 aka "David Gibson (Red Hat) <address@hidden>" [full]
# gpg:                 aka "David Gibson (ozlabs.org) <address@hidden>" [full]
# gpg:                 aka "David Gibson (kernel.org) <address@hidden>" 
[unknown]
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E  87DC 6C38 CACA 20D9 B392

* remotes/dgibson/tags/ppc-for-4.2-20191126:
  ppc/spapr_events: fix potential NULL pointer dereference in 
rtas_event_log_dequeue
  mos6522: update counters when timer interrupts are off
  spapr: Work around spurious warnings from vfio INTx initialization
  spapr: Handle irq backend changes with VFIO PCI devices
  vfio/pci: Respond to KVM irqchip change notifier
  vfio/pci: Split vfio_intx_update()
  kvm: Introduce KVM irqchip change notifier
  pseries: fix migration-test and pxe-test

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


Compare: https://github.com/qemu/qemu/compare/3c48f6daeda5...a0aaca7e9cd9