~paelzer/ubuntu/+source/qemu:bug-1847361-miss-old-so-on-upgrade-UPSTREAM

Last commit made on 2020-03-03
Get this branch:
git clone -b bug-1847361-miss-old-so-on-upgrade-UPSTREAM https://git.launchpad.net/~paelzer/ubuntu/+source/qemu
Only Christian Ehrhardt  can upload to this branch. If you are Christian Ehrhardt  please log in for upload directions.

Branch merges

Branch information

Name:
bug-1847361-miss-old-so-on-upgrade-UPSTREAM
Repository:
lp:~paelzer/ubuntu/+source/qemu

Recent commits

22a0908... by Christian Ehrhardt  on 2020-03-02

modules: fall back to load from versioning /var/run directory

On upgrades the old .so files usually are replaced. But on the other
hand since a qemu process represents a guest instance it is usually kept
around.

That makes late addition of dynamic features e.g. hot-attach of a ceph
disk fail by trying to load a new version of e.f. block-rbd.so into an
old still runnign binary.

Add a versioned directory in the temporary /var/run that qemu can look
into as well providing qemu packages a way to store modules of an
uninstalled/upgraded qemu until the next reboot.

Fixes: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1847361
Signed-off-by: Christian Ehrhardt <email address hidden>

a4c7ed8... by Peter Maydell on 2020-03-02

Merge remote-tracking branch 'remotes/ehabkost/tags/machine-next-pull-request' into staging

Machine queue, 2020-02-28

Cleanups:
* Fix NMI() macro (Philippe Mathieu-Daudé)
* Make MachineClass::is_default boolean, refuse multiple
  default machines (Philippe Mathieu-Daudé)

# gpg: Signature made Fri 28 Feb 2020 21:03:20 GMT
# gpg: using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6
# gpg: issuer "<email address hidden>"
# gpg: Good signature from "Eduardo Habkost <email address hidden>" [full]
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6

* remotes/ehabkost/tags/machine-next-pull-request:
  vl: Abort if multiple machines are registered as default
  hw: Make MachineClass::is_default a boolean type
  hw: Do not initialize MachineClass::is_default to 0
  hw/nmi: Fix the NMI() macro, based on INTERFACE_CHECK()

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

6db1857... by Philippe Mathieu-Daudé on 2020-02-07

vl: Abort if multiple machines are registered as default

It would be confusing to have multiple default machines.
Abort if this ever occurs.

Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
Message-Id: <email address hidden>
Reviewed-by: Marc-André Lureau <email address hidden>
Signed-off-by: Eduardo Habkost <email address hidden>
Reviewed-by: Laurent Vivier <email address hidden>
Tested-by: Laurent Vivier <email address hidden>

ea0ac7f... by Philippe Mathieu-Daudé on 2020-02-07

hw: Make MachineClass::is_default a boolean type

There's no good reason for it to be type int, change it to bool.

Suggested-by: Richard Henderson <email address hidden>
Reviewed-by: Michael S. Tsirkin <email address hidden>
Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
Message-Id: <email address hidden>
Reviewed-by: Marc-André Lureau <email address hidden>
Reviewed-by: Laurent Vivier <email address hidden>
Signed-off-by: Eduardo Habkost <email address hidden>

abcbc4e... by Philippe Mathieu-Daudé on 2020-02-07

hw: Do not initialize MachineClass::is_default to 0

The MachineClass is already zeroed on creation.

Note: The code setting is_default=0 in hw/i386/pc_piix.c is
      different (related to compat options). When adding a
      new versioned machine, we want it to be the new default,
      so we have to mark the previous one as not default.

Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
Message-Id: <email address hidden>
Reviewed-by: Laurent Vivier <email address hidden>
Signed-off-by: Eduardo Habkost <email address hidden>

64bc77e... by Philippe Mathieu-Daudé on 2019-12-07

hw/nmi: Fix the NMI() macro, based on INTERFACE_CHECK()

There is no declaration of the 'NMI' type. INTERFACE_CHECK()
returns an abstract type (see commit aa1b35b975d8). The abstract
type corresponding to the TYPE_NMI interface is 'NMIState'.

Fixes: 9cb805fd267
Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
Message-Id: <email address hidden>
Reviewed-by: Gavin Shan <email address hidden>
Signed-off-by: Eduardo Habkost <email address hidden>

e0175b7... by Peter Maydell on 2020-02-28

Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200228' into staging

target-arm queue:
 * hw/arm: Use TYPE_PL011 to create serial port
 * target/arm: Set ID_MMFR4.HPDS for aarch64_max_initfn
 * hw/arm/integratorcp: Map the audio codec controller
 * GICv2: Correctly implement the limited number of priority bits
 * target/arm: refactoring of VFP related feature checks and decode
 * xilinx_zynq: Fix USB port instantiation
 * acceptance tests for n800, n810, integratorcp
 * Implement v8.3-RCPC, v8.4-RCPC, v8.3-CCIDX
 * arm_gic_kvm: Don't assume kernel can provide a GICv2
   (provide better error message for user error)

# gpg: Signature made Fri 28 Feb 2020 16:38:04 GMT
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "<email address hidden>"
# gpg: Good signature from "Peter Maydell <email address hidden>" [ultimate]
# gpg: aka "Peter Maydell <email address hidden>" [ultimate]
# gpg: aka "Peter Maydell <email address hidden>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE

* remotes/pmaydell/tags/pull-target-arm-20200228: (33 commits)
  hw/intc/arm_gic_kvm: Don't assume kernel can provide a GICv2
  target/arm: Implement ARMv8.3-CCIDX
  target/arm: Implement v8.4-RCPC
  target/arm: Implement v8.3-RCPC
  target/arm: Fix wrong use of FIELD_EX32 on ID_AA64DFR0
  tests/acceptance/integratorcp: Verify Tux is displayed on framebuffer
  tests/acceptance: Extract boot_integratorcp() from test_integratorcp()
  tests/acceptance: Add a test for the integratorcp arm machine
  tests/acceptance: Add a test for the N800 and N810 arm machines
  hw/usb/hcd-ehci-sysbus: Remove obsolete xlnx, ps7-usb class
  hw/arm/xilinx_zynq: Fix USB port instantiation
  target/arm: Split VMINMAXNM decode
  target/arm: Split VFM decode
  target/arm: Add formats for some vfp 2 and 3-register insns
  target/arm: Remove ARM_FEATURE_VFP*
  linux-user/arm: Replace ARM_FEATURE_VFP* tests for HWCAP
  target/arm: Move the vfp decodetree calls next to the base isa
  target/arm: Move VLLDM and VLSTM to vfp.decode
  target/arm: Remove ARM_FEATURE_VFP check from disas_vfp_insn
  target/arm: Replace ARM_FEATURE_VFP4 with isar_feature_aa32_simdfmac
  ...

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

1904f9b... by Peter Maydell on 2020-02-25

hw/intc/arm_gic_kvm: Don't assume kernel can provide a GICv2

In our KVM GICv2 realize function, we try to cope with old kernels
that don't provide the device control API (KVM_CAP_DEVICE_CTRL): we
try to use the device control, and if that fails we fall back to
assuming that the kernel has the old style KVM_CREATE_IRQCHIP and
that it will provide a GICv2.

This doesn't cater for the possibility of a kernel and hardware which
only provide a GICv3, which is very common now. On that setup we
will abort() later on in kvm_arm_pmu_set_irq() when we try to wire up
an interrupt to the GIC we failed to create:

qemu-system-aarch64: PMU: KVM_SET_DEVICE_ATTR: Invalid argument
qemu-system-aarch64: failed to set irq for PMU
Aborted

If the kernel advertises KVM_CAP_DEVICE_CTRL we should trust it if it
says it can't create a GICv2, rather than assuming it has one. We
can then produce a more helpful error message including a hint about
the most probable reason for the failure.

If the kernel doesn't advertise KVM_CAP_DEVICE_CTRL then it is truly
ancient by this point but we might as well still fall back to a
KVM_CREATE_IRQCHIP GICv2.

With this patch then the user misconfiguration which previously
caused an abort now prints:
qemu-system-aarch64: Initialization of device kvm-arm-gic failed: error creating in-kernel VGIC: No such device
Perhaps the host CPU does not support GICv2?

Signed-off-by: Peter Maydell <email address hidden>
Reviewed-by: Philippe Mathieu-Daudé <email address hidden>
Reviewed-by: Andrew Jones <email address hidden>
Tested-by: Andrew Jones <email address hidden>
Message-id: <email address hidden>

957e615... by Peter Maydell on 2020-02-24

target/arm: Implement ARMv8.3-CCIDX

The ARMv8.3-CCIDX extension makes the CCSIDR_EL1 system ID registers
have a format that uses the full 64 bit width of the register, and
adds a new CCSIDR2 register so AArch32 can get at the high 32 bits.

QEMU doesn't implement caches, so we just treat these ID registers as
opaque values that are set to the correct constant values for each
CPU. The only thing we need to do is allow 64-bit values in our
cssidr[] array and provide the CCSIDR2 accessors.

We don't set the CCIDX field in our 'max' CPU because the CCSIDR
constant values we use are the same as the ones used by the
Cortex-A57 and they are in the old 32-bit format. This means
that the extra regdef added here is unused currently, but it
means that whenever in the future we add a CPU that does need
the new 64-bit format it will just work when we set the cssidr
values and the ID registers for it.

Signed-off-by: Peter Maydell <email address hidden>
Reviewed-by: Richard Henderson <email address hidden>
Message-id: <email address hidden>

a122910... by Peter Maydell on 2020-02-24

target/arm: Implement v8.4-RCPC

The v8.4-RCPC extension implements some new instructions:
 * LDAPUR, LDAPURB, LDAPURH, LDAPRSB, LDAPRSH, LDAPRSW
 * STLUR, STLURB, STLURH

These are all in a new subgroup of encodings that sits below the
top-level "Loads and Stores" group in the Arm ARM.

The STLUR* instructions have standard store-release semantics; the
LDAPUR* have Load-AcquirePC semantics, but (as with LDAPR*) we choose
to implement them as the slightly stronger Load-Acquire.

Signed-off-by: Peter Maydell <email address hidden>
Reviewed-by: Richard Henderson <email address hidden>
Message-id: <email address hidden>