[Qemu-devel] [PULL 0/7] ppc-for-2.10 queue 20170822

[Qemu-devel] [PULL 0/7] ppc-for-2.10 queue 20170822

[David Gibson]

The following changes since commit 1f296733876434118fd766cfef5eb6f29ecab6a8:

  Update version for v2.10.0-rc3 release (2017-08-15 18:53:31 +0100)

are available in the git repository at:

  git://github.com/dgibson/qemu.git tags/ppc-for-2.10-20170822

for you to fetch changes up to d3234e2851f1630c695c681beac1e87ac0881260:

  hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device (2017-08-22 11:11:30 +1000)

----------------------------------------------------------------
ppc patch queue 2017-08-22

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.

----------------------------------------------------------------
Bharata B Rao (1):
      spapr: Allow configure-connector to be called multiple times

Cornelia Huck (1):
      boot-serial-test: prefer tcg accelerator

Daniel Henrique Barboza (1):
      target/ppc: 'PVR != host PVR' in KVM_SET_SREGS workaround

Greg Kurz (1):
      ppc: fix ppc_set_compat() with KVM PR

Thomas Huth (3):
      hw/ppc/spapr: Fix segfault when instantiating a 'pc-dimm' without 'memdev'
      hw/ppc/spapr_rtc: Mark the RTC device with user_creatable = false
      hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device

 hw/i386/pc.c             | 14 ++++++++++++--
 hw/mem/nvdimm.c          |  2 +-
 hw/mem/pc-dimm.c         | 14 +++++++++++---
 hw/ppc/spapr.c           | 42 ++++++++++++++++++++++++++++++------------
 hw/ppc/spapr_drc.c       | 30 +++++++++++++++++++++++-------
 hw/ppc/spapr_iommu.c     |  2 ++
 hw/ppc/spapr_rtc.c       |  2 ++
 include/hw/mem/pc-dimm.h |  2 +-
 target/ppc/compat.c      |  9 +++++----
 target/ppc/kvm.c         | 34 ++++++++++++++++++++++++++++++++++
 target/ppc/kvm_ppc.h     |  1 +
 target/ppc/machine.c     | 22 ++++++++++++++++++++++
 tests/boot-serial-test.c |  6 +++++-
 13 files changed, 149 insertions(+), 31 deletions(-)

[Qemu-devel] [PULL 1/7] boot-serial-test: prefer tcg accelerator

[David Gibson]

From: Cornelia Huck <cohuck@redhat.com>

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 <richard.henderson@linaro.org>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 tests/boot-serial-test.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
index a8ca877168..b95c5e74ea 100644
--- a/tests/boot-serial-test.c
+++ b/tests/boot-serial-test.c
@@ -78,7 +78,11 @@ static void test_machine(const void *data)
     fd = mkstemp(tmpname);
     g_assert(fd != -1);
 
-    args = g_strdup_printf("-M %s,accel=kvm:tcg "
+    /*
+     * Make sure that this test uses tcg if available: It is used as a
+     * fast-enough smoketest for that.
+     */
+    args = g_strdup_printf("-M %s,accel=tcg:kvm "
                            "-chardev file,id=serial0,path=%s "
                            "-no-shutdown -serial chardev:serial0 %s",
                            test->machine, tmpname, test->extra);
-- 
2.13.5

[Qemu-devel] [PULL 2/7] target/ppc: 'PVR != host PVR' in KVM_SET_SREGS workaround

[David Gibson]

From: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>

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 <danielhb@linux.vnet.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 target/ppc/kvm.c     | 34 ++++++++++++++++++++++++++++++++++
 target/ppc/kvm_ppc.h |  1 +
 target/ppc/machine.c | 22 ++++++++++++++++++++++
 3 files changed, 57 insertions(+)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 85713795de..fb3ee4351a 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -90,6 +90,7 @@ static int cap_htm;             /* Hardware transactional memory support */
 static int cap_mmu_radix;
 static int cap_mmu_hash_v3;
 static int cap_resize_hpt;
+static int cap_ppc_pvr_compat;
 
 static uint32_t debug_inst_opcode;
 
@@ -147,6 +148,13 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
     cap_mmu_radix = kvm_vm_check_extension(s, KVM_CAP_PPC_MMU_RADIX);
     cap_mmu_hash_v3 = kvm_vm_check_extension(s, KVM_CAP_PPC_MMU_HASH_V3);
     cap_resize_hpt = kvm_vm_check_extension(s, KVM_CAP_SPAPR_RESIZE_HPT);
+    /*
+     * Note: setting it to false because there is not such capability
+     * in KVM at this moment.
+     *
+     * TODO: call kvm_vm_check_extension() with the right capability
+     * after the kernel starts implementing it.*/
+    cap_ppc_pvr_compat = false;
 
     if (!cap_interrupt_level) {
         fprintf(stderr, "KVM: Couldn't find level irq capability. Expect the "
@@ -2785,3 +2793,29 @@ void kvmppc_update_sdr1(target_ulong sdr1)
         run_on_cpu(cs, kvmppc_pivot_hpt_cpu, RUN_ON_CPU_TARGET_PTR(sdr1));
     }
 }
+
+/*
+ * This is a helper function to detect a post migration scenario
+ * in which a guest, running as KVM-HV, freezes in cpu_post_load because
+ * the guest kernel can't handle a PVR value other than the actual host
+ * PVR in KVM_SET_SREGS, even if pvr_match() returns true.
+ *
+ * If we don't have cap_ppc_pvr_compat and we're not running in PR
+ * (so, we're HV), return true. The workaround itself is done in
+ * cpu_post_load.
+ *
+ * The order here is important: we'll only check for KVM PR as a
+ * fallback if the guest kernel can't handle the situation itself.
+ * We need to avoid as much as possible querying the running KVM type
+ * in QEMU level.
+ */
+bool kvmppc_pvr_workaround_required(PowerPCCPU *cpu)
+{
+    CPUState *cs = CPU(cpu);
+
+    if (cap_ppc_pvr_compat) {
+        return false;
+    }
+
+    return !kvmppc_is_pr(cs->kvm_state);
+}
diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
index 6bc6fb3e2d..381afe6240 100644
--- a/target/ppc/kvm_ppc.h
+++ b/target/ppc/kvm_ppc.h
@@ -67,6 +67,7 @@ void kvmppc_check_papr_resize_hpt(Error **errp);
 int kvmppc_resize_hpt_prepare(PowerPCCPU *cpu, target_ulong flags, int shift);
 int kvmppc_resize_hpt_commit(PowerPCCPU *cpu, target_ulong flags, int shift);
 void kvmppc_update_sdr1(target_ulong sdr1);
+bool kvmppc_pvr_workaround_required(PowerPCCPU *cpu);
 
 bool kvmppc_is_mem_backend_page_size_ok(const char *obj_path);
 
diff --git a/target/ppc/machine.c b/target/ppc/machine.c
index abe0a1cdf0..e36b7100cb 100644
--- a/target/ppc/machine.c
+++ b/target/ppc/machine.c
@@ -9,6 +9,7 @@
 #include "mmu-hash64.h"
 #include "migration/cpu.h"
 #include "qapi/error.h"
+#include "kvm_ppc.h"
 
 static int cpu_load_old(QEMUFile *f, void *opaque, int version_id)
 {
@@ -249,6 +250,27 @@ static int cpu_post_load(void *opaque, int version_id)
         }
     }
 
+    /*
+     * If we're running with KVM HV, there is a chance that the guest
+     * is running with KVM HV and its kernel does not have the
+     * capability of dealing with a different PVR other than this
+     * exact host PVR in KVM_SET_SREGS. If that happens, the
+     * guest freezes after migration.
+     *
+     * The function kvmppc_pvr_workaround_required does this verification
+     * by first checking if the kernel has the cap, returning true immediately
+     * if that is the case. Otherwise, it checks if we're running in KVM PR.
+     * If the guest kernel does not have the cap and we're not running KVM-PR
+     * (so, it is running KVM-HV), we need to ensure that KVM_SET_SREGS will
+     * receive the PVR it expects as a workaround.
+     *
+     */
+#if defined(CONFIG_KVM)
+    if (kvmppc_pvr_workaround_required(cpu)) {
+        env->spr[SPR_PVR] = env->spr_cb[SPR_PVR].default_value;
+    }
+#endif
+
     env->lr = env->spr[SPR_LR];
     env->ctr = env->spr[SPR_CTR];
     cpu_write_xer(env, env->spr[SPR_XER]);
-- 
2.13.5

[Qemu-devel] [PULL 3/7] ppc: fix ppc_set_compat() with KVM PR

[David Gibson]

From: Greg Kurz <groug@kaod.org>

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 <groug@kaod.org>
Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 target/ppc/compat.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/target/ppc/compat.c b/target/ppc/compat.c
index f1b67faa97..f8729fe46d 100644
--- a/target/ppc/compat.c
+++ b/target/ppc/compat.c
@@ -140,16 +140,17 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp)
 
     cpu_synchronize_state(CPU(cpu));
 
-    cpu->compat_pvr = compat_pvr;
-    env->spr[SPR_PCR] = pcr & pcc->pcr_mask;
-
-    if (kvm_enabled()) {
+    if (kvm_enabled() && cpu->compat_pvr != compat_pvr) {
         int ret = kvmppc_set_compat(cpu, cpu->compat_pvr);
         if (ret < 0) {
             error_setg_errno(errp, -ret,
                              "Unable to set CPU compatibility mode in KVM");
+            return;
         }
     }
+
+    cpu->compat_pvr = compat_pvr;
+    env->spr[SPR_PCR] = pcr & pcc->pcr_mask;
 }
 
 typedef struct {
-- 
2.13.5

[Qemu-devel] [PULL 4/7] spapr: Allow configure-connector to be called multiple times

[David Gibson]

From: Bharata B Rao <bharata@linux.vnet.ibm.com>

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 <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: David Gibson <david@gibson.dropbear.id.au>
---
 hw/ppc/spapr_drc.c | 30 +++++++++++++++++++++++-------
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
index 5260b5d363..605697d8bd 100644
--- a/hw/ppc/spapr_drc.c
+++ b/hw/ppc/spapr_drc.c
@@ -442,12 +442,17 @@ void spapr_drc_reset(sPAPRDRConnector *drc)
     if (drc->dev) {
         /* A device present at reset is ready to go, same as coldplugged */
         drc->state = drck->ready_state;
+        /*
+         * Ensure that we are able to send the FDT fragment again
+         * via configure-connector call if the guest requests.
+         */
+        drc->ccs_offset = drc->fdt_start_offset;
+        drc->ccs_depth = 0;
     } else {
         drc->state = drck->empty_state;
+        drc->ccs_offset = -1;
+        drc->ccs_depth = -1;
     }
-
-    drc->ccs_offset = -1;
-    drc->ccs_depth = -1;
 }
 
 static void drc_reset(void *opaque)
@@ -1071,8 +1076,14 @@ static void rtas_ibm_configure_connector(PowerPCCPU *cpu,
     }
 
     if ((drc->state != SPAPR_DRC_STATE_LOGICAL_UNISOLATE)
-        && (drc->state != SPAPR_DRC_STATE_PHYSICAL_UNISOLATE)) {
-        /* Need to unisolate the device before configuring */
+        && (drc->state != SPAPR_DRC_STATE_PHYSICAL_UNISOLATE)
+        && (drc->state != SPAPR_DRC_STATE_LOGICAL_CONFIGURED)
+        && (drc->state != SPAPR_DRC_STATE_PHYSICAL_CONFIGURED)) {
+        /*
+         * Need to unisolate the device before configuring
+         * or it should already be in configured state to
+         * allow configure-connector be called repeatedly.
+         */
         rc = SPAPR_DR_CC_RESPONSE_NOT_CONFIGURABLE;
         goto out;
     }
@@ -1108,8 +1119,13 @@ static void rtas_ibm_configure_connector(PowerPCCPU *cpu,
                 /* done sending the device tree, move to configured state */
                 trace_spapr_drc_set_configured(drc_index);
                 drc->state = drck->ready_state;
-                drc->ccs_offset = -1;
-                drc->ccs_depth = -1;
+                /*
+                 * Ensure that we are able to send the FDT fragment
+                 * again via configure-connector call if the guest requests.
+                 */
+                drc->ccs_offset = drc->fdt_start_offset;
+                drc->ccs_depth = 0;
+                fdt_offset_next = drc->fdt_start_offset;
                 resp = SPAPR_DR_CC_RESPONSE_SUCCESS;
             } else {
                 resp = SPAPR_DR_CC_RESPONSE_PREV_PARENT;
-- 
2.13.5

[Qemu-devel] [PULL 5/7] hw/ppc/spapr: Fix segfault when instantiating a 'pc-dimm' without 'memdev'

[David Gibson]

From: Thomas Huth <thuth@redhat.com>

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 <thuth@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/i386/pc.c             | 14 ++++++++++++--
 hw/mem/nvdimm.c          |  2 +-
 hw/mem/pc-dimm.c         | 14 +++++++++++---
 hw/ppc/spapr.c           | 42 ++++++++++++++++++++++++++++++------------
 include/hw/mem/pc-dimm.h |  2 +-
 5 files changed, 55 insertions(+), 19 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 59435390ba..21081041d5 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1691,10 +1691,15 @@ static void pc_dimm_plug(HotplugHandler *hotplug_dev,
     PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
     PCDIMMDevice *dimm = PC_DIMM(dev);
     PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
-    MemoryRegion *mr = ddc->get_memory_region(dimm);
+    MemoryRegion *mr;
     uint64_t align = TARGET_PAGE_SIZE;
     bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
 
+    mr = ddc->get_memory_region(dimm, &local_err);
+    if (local_err) {
+        goto out;
+    }
+
     if (memory_region_get_alignment(mr) && pcmc->enforce_aligned_dimm) {
         align = memory_region_get_alignment(mr);
     }
@@ -1758,10 +1763,15 @@ static void pc_dimm_unplug(HotplugHandler *hotplug_dev,
     PCMachineState *pcms = PC_MACHINE(hotplug_dev);
     PCDIMMDevice *dimm = PC_DIMM(dev);
     PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
-    MemoryRegion *mr = ddc->get_memory_region(dimm);
+    MemoryRegion *mr;
     HotplugHandlerClass *hhc;
     Error *local_err = NULL;
 
+    mr = ddc->get_memory_region(dimm, &local_err);
+    if (local_err) {
+        goto out;
+    }
+
     hhc = HOTPLUG_HANDLER_GET_CLASS(pcms->acpi_dev);
     hhc->unplug(HOTPLUG_HANDLER(pcms->acpi_dev), dev, &local_err);
 
diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c
index db896b0bb6..952fce5ec8 100644
--- a/hw/mem/nvdimm.c
+++ b/hw/mem/nvdimm.c
@@ -71,7 +71,7 @@ static void nvdimm_init(Object *obj)
                         NULL, NULL);
 }
 
-static MemoryRegion *nvdimm_get_memory_region(PCDIMMDevice *dimm)
+static MemoryRegion *nvdimm_get_memory_region(PCDIMMDevice *dimm, Error **errp)
 {
     NVDIMMDevice *nvdimm = NVDIMM(dimm);
 
diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index ea67b461c2..bdf6649083 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -363,7 +363,10 @@ static void pc_dimm_get_size(Object *obj, Visitor *v, const char *name,
     PCDIMMDevice *dimm = PC_DIMM(obj);
     PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(obj);
 
-    mr = ddc->get_memory_region(dimm);
+    mr = ddc->get_memory_region(dimm, errp);
+    if (!mr) {
+        return;
+    }
     value = memory_region_size(mr);
 
     visit_type_uint64(v, name, &value, errp);
@@ -411,9 +414,14 @@ static void pc_dimm_unrealize(DeviceState *dev, Error **errp)
     host_memory_backend_set_mapped(dimm->hostmem, false);
 }
 
-static MemoryRegion *pc_dimm_get_memory_region(PCDIMMDevice *dimm)
+static MemoryRegion *pc_dimm_get_memory_region(PCDIMMDevice *dimm, Error **errp)
 {
-    return host_memory_backend_get_memory(dimm->hostmem, &error_abort);
+    if (!dimm->hostmem) {
+        error_setg(errp, "'" PC_DIMM_MEMDEV_PROP "' property must be set");
+        return NULL;
+    }
+
+    return host_memory_backend_get_memory(dimm->hostmem, errp);
 }
 
 static MemoryRegion *pc_dimm_get_vmstate_memory_region(PCDIMMDevice *dimm)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index f7a19720dc..cec441cbf4 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2772,10 +2772,15 @@ static void spapr_memory_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
     sPAPRMachineState *ms = SPAPR_MACHINE(hotplug_dev);
     PCDIMMDevice *dimm = PC_DIMM(dev);
     PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
-    MemoryRegion *mr = ddc->get_memory_region(dimm);
-    uint64_t align = memory_region_get_alignment(mr);
-    uint64_t size = memory_region_size(mr);
-    uint64_t addr;
+    MemoryRegion *mr;
+    uint64_t align, size, addr;
+
+    mr = ddc->get_memory_region(dimm, &local_err);
+    if (local_err) {
+        goto out;
+    }
+    align = memory_region_get_alignment(mr);
+    size = memory_region_size(mr);
 
     pc_dimm_memory_plug(dev, &ms->hotplug_memory, mr, align, &local_err);
     if (local_err) {
@@ -2808,10 +2813,16 @@ static void spapr_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
 {
     PCDIMMDevice *dimm = PC_DIMM(dev);
     PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
-    MemoryRegion *mr = ddc->get_memory_region(dimm);
-    uint64_t size = memory_region_size(mr);
+    MemoryRegion *mr;
+    uint64_t size;
     char *mem_dev;
 
+    mr = ddc->get_memory_region(dimm, errp);
+    if (!mr) {
+        return;
+    }
+    size = memory_region_size(mr);
+
     if (size % SPAPR_MEMORY_BLOCK_SIZE) {
         error_setg(errp, "Hotplugged memory size must be a multiple of "
                       "%lld MB", SPAPR_MEMORY_BLOCK_SIZE / M_BYTE);
@@ -2882,7 +2893,7 @@ static sPAPRDIMMState *spapr_recover_pending_dimm_state(sPAPRMachineState *ms,
 {
     sPAPRDRConnector *drc;
     PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
-    MemoryRegion *mr = ddc->get_memory_region(dimm);
+    MemoryRegion *mr = ddc->get_memory_region(dimm, &error_abort);
     uint64_t size = memory_region_size(mr);
     uint32_t nr_lmbs = size / SPAPR_MEMORY_BLOCK_SIZE;
     uint32_t avail_lmbs = 0;
@@ -2912,7 +2923,7 @@ void spapr_lmb_release(DeviceState *dev)
     sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_hotplug_handler(dev));
     PCDIMMDevice *dimm = PC_DIMM(dev);
     PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
-    MemoryRegion *mr = ddc->get_memory_region(dimm);
+    MemoryRegion *mr = ddc->get_memory_region(dimm, &error_abort);
     sPAPRDIMMState *ds = spapr_pending_dimm_unplugs_find(spapr, PC_DIMM(dev));
 
     /* This information will get lost if a migration occurs
@@ -2945,12 +2956,19 @@ static void spapr_memory_unplug_request(HotplugHandler *hotplug_dev,
     Error *local_err = NULL;
     PCDIMMDevice *dimm = PC_DIMM(dev);
     PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
-    MemoryRegion *mr = ddc->get_memory_region(dimm);
-    uint64_t size = memory_region_size(mr);
-    uint32_t nr_lmbs = size / SPAPR_MEMORY_BLOCK_SIZE;
-    uint64_t addr_start, addr;
+    MemoryRegion *mr;
+    uint32_t nr_lmbs;
+    uint64_t size, addr_start, addr;
     int i;
     sPAPRDRConnector *drc;
+
+    mr = ddc->get_memory_region(dimm, &local_err);
+    if (local_err) {
+        goto out;
+    }
+    size = memory_region_size(mr);
+    nr_lmbs = size / SPAPR_MEMORY_BLOCK_SIZE;
+
     addr_start = object_property_get_uint(OBJECT(dimm), PC_DIMM_ADDR_PROP,
                                          &local_err);
     if (local_err) {
diff --git a/include/hw/mem/pc-dimm.h b/include/hw/mem/pc-dimm.h
index 1e483f2670..6f8c3eb1b3 100644
--- a/include/hw/mem/pc-dimm.h
+++ b/include/hw/mem/pc-dimm.h
@@ -71,7 +71,7 @@ typedef struct PCDIMMDeviceClass {
 
     /* public */
     void (*realize)(PCDIMMDevice *dimm, Error **errp);
-    MemoryRegion *(*get_memory_region)(PCDIMMDevice *dimm);
+    MemoryRegion *(*get_memory_region)(PCDIMMDevice *dimm, Error **errp);
     MemoryRegion *(*get_vmstate_memory_region)(PCDIMMDevice *dimm);
 } PCDIMMDeviceClass;
 
-- 
2.13.5

[Qemu-devel] [PULL 6/7] hw/ppc/spapr_rtc: Mark the RTC device with user_creatable = false

[David Gibson]

From: Thomas Huth <thuth@redhat.com>

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 <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/ppc/spapr_rtc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/ppc/spapr_rtc.c b/hw/ppc/spapr_rtc.c
index 00a4e4c717..9ec3078691 100644
--- a/hw/ppc/spapr_rtc.c
+++ b/hw/ppc/spapr_rtc.c
@@ -164,6 +164,8 @@ static void spapr_rtc_class_init(ObjectClass *oc, void *data)
 
     dc->realize = spapr_rtc_realize;
     dc->vmsd = &vmstate_spapr_rtc;
+    /* Reason: This is an internal device only for handling the hypercalls */
+    dc->user_creatable = false;
 
     spapr_rtas_register(RTAS_GET_TIME_OF_DAY, "get-time-of-day",
                         rtas_get_time_of_day);
-- 
2.13.5

[Qemu-devel] [PULL 7/7] hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device

[David Gibson]

From: Thomas Huth <thuth@redhat.com>

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 <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/ppc/spapr_iommu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c
index e614621a83..ed2d53559a 100644
--- a/hw/ppc/spapr_iommu.c
+++ b/hw/ppc/spapr_iommu.c
@@ -618,6 +618,8 @@ static void spapr_tce_table_class_init(ObjectClass *klass, void *data)
     dc->init = spapr_tce_table_realize;
     dc->reset = spapr_tce_reset;
     dc->unrealize = spapr_tce_table_unrealize;
+    /* Reason: This is just an internal device for handling the hypercalls */
+    dc->user_creatable = false;
 
     QLIST_INIT(&spapr_tce_tables);
 
-- 
2.13.5

Re: [Qemu-devel] [PULL 0/7] ppc-for-2.10 queue 20170822

[Peter Maydell]

On 22 August 2017 at 05:24, David Gibson <david@gibson.dropbear.id.au> wrote:
> The following changes since commit 1f296733876434118fd766cfef5eb6f29ecab6a8:
>
>   Update version for v2.10.0-rc3 release (2017-08-15 18:53:31 +0100)
>
> are available in the git repository at:
>
>   git://github.com/dgibson/qemu.git tags/ppc-for-2.10-20170822
>
> for you to fetch changes up to d3234e2851f1630c695c681beac1e87ac0881260:
>
>   hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device (2017-08-22 11:11:30 +1000)
>
> ----------------------------------------------------------------
> ppc patch queue 2017-08-22
>
> 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.
>
> ----------------------------------------------------------------

I get a make check failure on ppc64 Linux:

TEST: tests/postcopy-test... (pid=12468)
  /ppc64/postcopy:
Broken pipe
qemu-system-ppc64: RP: Received invalid message 0x0000 length 0x0000
FAIL
GTester: last random seed: R02Se5468e06f561627824306d95b0566d2b
(pid=13011)
FAIL: tests/postcopy-test

thanks
-- PMM

Re: [Qemu-devel] [PULL 0/7] ppc-for-2.10 queue 20170822

[Laurent Vivier]

On 22/08/2017 11:34, Peter Maydell wrote:
> On 22 August 2017 at 05:24, David Gibson <david@gibson.dropbear.id.au> wrote:
>> The following changes since commit 1f296733876434118fd766cfef5eb6f29ecab6a8:
>>
>>   Update version for v2.10.0-rc3 release (2017-08-15 18:53:31 +0100)
>>
>> are available in the git repository at:
>>
>>   git://github.com/dgibson/qemu.git tags/ppc-for-2.10-20170822
>>
>> for you to fetch changes up to d3234e2851f1630c695c681beac1e87ac0881260:
>>
>>   hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device (2017-08-22 11:11:30 +1000)
>>
>> ----------------------------------------------------------------
>> ppc patch queue 2017-08-22
>>
>> 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.
>>
>> ----------------------------------------------------------------
> 
> I get a make check failure on ppc64 Linux:
> 
> TEST: tests/postcopy-test... (pid=12468)
>   /ppc64/postcopy:
> Broken pipe
> qemu-system-ppc64: RP: Received invalid message 0x0000 length 0x0000
> FAIL
> GTester: last random seed: R02Se5468e06f561627824306d95b0566d2b
> (pid=13011)
> FAIL: tests/postcopy-test

This test should fail with KVM PR, but it is explicitly disabled by:

tests/postcopy-test.c:

386         accel = access("/sys/module/kvm_hv", F_OK) ? "tcg" : "kvm:tcg";

What is your test machine?

[CC' Greg]
Thanks,
Laurent

Re: [Qemu-devel] [PULL 0/7] ppc-for-2.10 queue 20170822

[Peter Maydell]

On 22 August 2017 at 10:43, Laurent Vivier <lvivier@redhat.com> wrote:
> On 22/08/2017 11:34, Peter Maydell wrote:
>> On 22 August 2017 at 05:24, David Gibson <david@gibson.dropbear.id.au> wrote:
>>> The following changes since commit 1f296733876434118fd766cfef5eb6f29ecab6a8:
>>>
>>>   Update version for v2.10.0-rc3 release (2017-08-15 18:53:31 +0100)
>>>
>>> are available in the git repository at:
>>>
>>>   git://github.com/dgibson/qemu.git tags/ppc-for-2.10-20170822
>>>
>>> for you to fetch changes up to d3234e2851f1630c695c681beac1e87ac0881260:
>>>
>>>   hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device (2017-08-22 11:11:30 +1000)
>>>
>>> ----------------------------------------------------------------
>>> ppc patch queue 2017-08-22
>>>
>>> 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.
>>>
>>> ----------------------------------------------------------------
>>
>> I get a make check failure on ppc64 Linux:
>>
>> TEST: tests/postcopy-test... (pid=12468)
>>   /ppc64/postcopy:
>> Broken pipe
>> qemu-system-ppc64: RP: Received invalid message 0x0000 length 0x0000
>> FAIL
>> GTester: last random seed: R02Se5468e06f561627824306d95b0566d2b
>> (pid=13011)
>> FAIL: tests/postcopy-test
>
> This test should fail with KVM PR, but it is explicitly disabled by:
>
> tests/postcopy-test.c:
>
> 386         accel = access("/sys/module/kvm_hv", F_OK) ? "tcg" : "kvm:tcg";

There is no file of that name on the machine; but we'll be using
TCG anyway because /dev/kvm is not readable by my user.

> What is your test machine?

It's the gcc compile farm ppc64 box (gcc110 if you have compile farm
access):
Linux gcc1-power7.osuosl.org 3.10.0-514.26.2.el7.ppc64 #1 SMP Mon Jul
10 02:26:53 GMT 2017 ppc64 ppc64 ppc64 GNU/Linux

/proc/cpuinfo says

processor       : 0
cpu             : POWER7 (architected), altivec supported
clock           : 3550.000000MHz
revision        : 2.1 (pvr 003f 0201)
[etc]

timebase        : 512000000
platform        : pSeries
model           : IBM,8231-E2B
machine         : CHRP IBM,8231-E2B

git bisect blames "target/ppc: 'PVR != host PVR' in KVM_SET_SREGS workaround"
for the regression.

thanks
-- PMM

Re: [Qemu-devel] [PULL 0/7] ppc-for-2.10 queue 20170822

[Laurent Vivier]

On 22/08/2017 11:53, Peter Maydell wrote:
> On 22 August 2017 at 10:43, Laurent Vivier <lvivier@redhat.com> wrote:
>> On 22/08/2017 11:34, Peter Maydell wrote:
>>> On 22 August 2017 at 05:24, David Gibson <david@gibson.dropbear.id.au> wrote:
>>>> The following changes since commit 1f296733876434118fd766cfef5eb6f29ecab6a8:
>>>>
>>>>   Update version for v2.10.0-rc3 release (2017-08-15 18:53:31 +0100)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>   git://github.com/dgibson/qemu.git tags/ppc-for-2.10-20170822
>>>>
>>>> for you to fetch changes up to d3234e2851f1630c695c681beac1e87ac0881260:
>>>>
>>>>   hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device (2017-08-22 11:11:30 +1000)
>>>>
>>>> ----------------------------------------------------------------
>>>> ppc patch queue 2017-08-22
>>>>
>>>> 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.
>>>>
>>>> ----------------------------------------------------------------
>>>
>>> I get a make check failure on ppc64 Linux:
>>>
>>> TEST: tests/postcopy-test... (pid=12468)
>>>   /ppc64/postcopy:
>>> Broken pipe
>>> qemu-system-ppc64: RP: Received invalid message 0x0000 length 0x0000
>>> FAIL
>>> GTester: last random seed: R02Se5468e06f561627824306d95b0566d2b
>>> (pid=13011)
>>> FAIL: tests/postcopy-test

The problem is in:

bool kvmppc_pvr_workaround_required(PowerPCCPU *cpu)
{
    CPUState *cs = CPU(cpu);

    if (cap_ppc_pvr_compat) {
        return false;
    }

    return !kvmppc_is_pr(cs->kvm_state);
}

It guesses !kvm pr means kvm_hv. That is not true, it can be TCG.

This fixes the problem for me:
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -2817,5 +2817,5 @@ bool kvmppc_pvr_workaround_required(PowerPCCPU *cpu)
         return false;
     }

-    return !kvmppc_is_pr(cs->kvm_state);
+    return kvm_enabled() && !kvmppc_is_pr(cs->kvm_state);
 }

[CC' Daniel]
Thanks,
Laurent

Re: [Qemu-devel] [PULL 0/7] ppc-for-2.10 queue 20170822

[Peter Maydell]

On 22 August 2017 at 11:41, Laurent Vivier <lvivier@redhat.com> wrote:
> On 22/08/2017 11:53, Peter Maydell wrote:
>> On 22 August 2017 at 10:43, Laurent Vivier <lvivier@redhat.com> wrote:
>>> On 22/08/2017 11:34, Peter Maydell wrote:
>>>> I get a make check failure on ppc64 Linux:
>>>>
>>>> TEST: tests/postcopy-test... (pid=12468)
>>>>   /ppc64/postcopy:
>>>> Broken pipe
>>>> qemu-system-ppc64: RP: Received invalid message 0x0000 length 0x0000
>>>> FAIL
>>>> GTester: last random seed: R02Se5468e06f561627824306d95b0566d2b
>>>> (pid=13011)
>>>> FAIL: tests/postcopy-test
>
> The problem is in:
>
> bool kvmppc_pvr_workaround_required(PowerPCCPU *cpu)
> {
>     CPUState *cs = CPU(cpu);
>
>     if (cap_ppc_pvr_compat) {
>         return false;
>     }
>
>     return !kvmppc_is_pr(cs->kvm_state);
> }
>
> It guesses !kvm pr means kvm_hv. That is not true, it can be TCG.
>
> This fixes the problem for me:
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -2817,5 +2817,5 @@ bool kvmppc_pvr_workaround_required(PowerPCCPU *cpu)
>          return false;
>      }
>
> -    return !kvmppc_is_pr(cs->kvm_state);
> +    return kvm_enabled() && !kvmppc_is_pr(cs->kvm_state);
>  }

Yep, fixes the failure for me too. David, can you respin your
pull request, please?

thanks
-- PMM

Re: [Qemu-devel] [Qemu-ppc] [PULL 0/7] ppc-for-2.10 queue 20170822

[Daniel Henrique Barboza]

On 08/22/2017 07:52 AM, Peter Maydell wrote:
> On 22 August 2017 at 11:41, Laurent Vivier <lvivier@redhat.com> wrote:
>> On 22/08/2017 11:53, Peter Maydell wrote:
>>> On 22 August 2017 at 10:43, Laurent Vivier <lvivier@redhat.com> wrote:
>>>> On 22/08/2017 11:34, Peter Maydell wrote:
>>>>> I get a make check failure on ppc64 Linux:
>>>>>
>>>>> TEST: tests/postcopy-test... (pid=12468)
>>>>>    /ppc64/postcopy:
>>>>> Broken pipe
>>>>> qemu-system-ppc64: RP: Received invalid message 0x0000 length 0x0000
>>>>> FAIL
>>>>> GTester: last random seed: R02Se5468e06f561627824306d95b0566d2b
>>>>> (pid=13011)
>>>>> FAIL: tests/postcopy-test
>> The problem is in:
>>
>> bool kvmppc_pvr_workaround_required(PowerPCCPU *cpu)
>> {
>>      CPUState *cs = CPU(cpu);
>>
>>      if (cap_ppc_pvr_compat) {
>>          return false;
>>      }
>>
>>      return !kvmppc_is_pr(cs->kvm_state);
>> }
>>
>> It guesses !kvm pr means kvm_hv. That is not true, it can be TCG.
>>
>> This fixes the problem for me:
>> --- a/target/ppc/kvm.c
>> +++ b/target/ppc/kvm.c
>> @@ -2817,5 +2817,5 @@ bool kvmppc_pvr_workaround_required(PowerPCCPU *cpu)
>>           return false;
>>       }
>>
>> -    return !kvmppc_is_pr(cs->kvm_state);
>> +    return kvm_enabled() && !kvmppc_is_pr(cs->kvm_state);
>>   }

Good catch. I forgot to cover/test TCG scenarios with this patch and 
this bug
flew under the radar completely :(

> Yep, fixes the failure for me too. David, can you respin your
> pull request, please?

I've send a v2 of the patch including Laurent's fix too. Feel free to 
use the v2 or
amend it on top of the existing v1, whatever is easier.


Thanks,

Daniel

>
> thanks
> -- PMM
>

Re: [Qemu-devel] [PULL 0/7] ppc-for-2.10 queue 20170822

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]

On Tue, Aug 22, 2017 at 11:52:00AM +0100, Peter Maydell wrote:
> On 22 August 2017 at 11:41, Laurent Vivier <lvivier@redhat.com> wrote:
> > On 22/08/2017 11:53, Peter Maydell wrote:
> >> On 22 August 2017 at 10:43, Laurent Vivier <lvivier@redhat.com> wrote:
> >>> On 22/08/2017 11:34, Peter Maydell wrote:
> >>>> I get a make check failure on ppc64 Linux:
> >>>>
> >>>> TEST: tests/postcopy-test... (pid=12468)
> >>>>   /ppc64/postcopy:
> >>>> Broken pipe
> >>>> qemu-system-ppc64: RP: Received invalid message 0x0000 length 0x0000
> >>>> FAIL
> >>>> GTester: last random seed: R02Se5468e06f561627824306d95b0566d2b
> >>>> (pid=13011)
> >>>> FAIL: tests/postcopy-test
> >
> > The problem is in:
> >
> > bool kvmppc_pvr_workaround_required(PowerPCCPU *cpu)
> > {
> >     CPUState *cs = CPU(cpu);
> >
> >     if (cap_ppc_pvr_compat) {
> >         return false;
> >     }
> >
> >     return !kvmppc_is_pr(cs->kvm_state);
> > }
> >
> > It guesses !kvm pr means kvm_hv. That is not true, it can be TCG.
> >
> > This fixes the problem for me:
> > --- a/target/ppc/kvm.c
> > +++ b/target/ppc/kvm.c
> > @@ -2817,5 +2817,5 @@ bool kvmppc_pvr_workaround_required(PowerPCCPU *cpu)
> >          return false;
> >      }
> >
> > -    return !kvmppc_is_pr(cs->kvm_state);
> > +    return kvm_enabled() && !kvmppc_is_pr(cs->kvm_state);
> >  }
> 
> Yep, fixes the failure for me too. David, can you respin your
> pull request, please?

Done.  In the interests of getting it out quickly, I haven't done the
full usual set of tests, though I have done a make check on a ppc host
both with and without KVM available.  A tweaked version of the fix
above is the only change, so I'm hoping the testing round on the
previous pullreq should suffice.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]