[Qemu-devel] [PULL 0/9] ppc-for-2.12 queue 20180315

[Qemu-devel] [PULL 0/9] ppc-for-2.12 queue 20180315

[David Gibson]

The following changes since commit 026aaf47c02b79036feb830206cfebb2a726510d:

  Merge remote-tracking branch 'remotes/ehabkost/tags/python-next-pull-request' into staging (2018-03-13 16:26:44 +0000)

are available in the Git repository at:

  git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180315

for you to fetch changes up to a9ab8cc157054ea6941fb849c78d9e6c515a7730:

  target/ppc: fix tlbsync to check privilege level depending on GTSE (2018-03-15 11:18:31 +1100)

----------------------------------------------------------------
ppc patch queue for 2018-03-15

Here's the set of accumulated patches now that we're into soft freeze.
I've split new functionality into a ppc-for-2.13 branch, so this only
has bugfixes.  Well.. and a couple of simple cleanups to make bugfixes
easier, some test improvements and a trivial change to make command
line options more obvious.  I think those are all acceptable for soft
freeze.

----------------------------------------------------------------
BALATON Zoltan (2):
      sii3112: Remove unneeded exit function
      ppc440_pcix: Change some error_report to qemu_log_mask(LOG_UNIMP, ...)

Cédric Le Goater (1):
      target/ppc: fix tlbsync to check privilege level depending on GTSE

David Engraf (1):
      PPC e500: Fix gap between u-boot and kernel

Thomas Huth (5):
      tests/boot-serial: Check the 40p machine, too
      hw/ppc/prep: Fix implicit creation of "-drive if=scsi" devices
      hw/misc/macio: Mark the macio devices with user_creatable = false
      hw/ppc/spapr: Allow "spapr-vlan" as NIC model name beside "ibmveth"
      tests/boot-serial: Test the sam460ex board

 hw/ide/sii3112.c         | 12 ------------
 hw/misc/macio/macio.c    |  2 ++
 hw/ppc/e500.c            |  9 ++++-----
 hw/ppc/ppc440_pcix.c     | 11 +++++++----
 hw/ppc/prep.c            |  2 +-
 hw/ppc/spapr.c           |  5 +++--
 hw/scsi/lsi53c895a.c     |  7 +++++++
 include/hw/pci/pci.h     |  1 +
 target/ppc/translate.c   |  9 +++++++--
 tests/boot-serial-test.c |  8 ++++++--
 10 files changed, 38 insertions(+), 28 deletions(-)

[Qemu-devel] [PULL 1/9] sii3112: Remove unneeded exit function

[David Gibson]

From: BALATON Zoltan <balaton@eik.bme.hu>

An exit function was mistakenly left here but it's not needed because
the PCI bars are organised differently in this device. Calling this
exit function during device_del was causing an abort with
memory_region_del_subregion: `Assertion subregion->container == mr' failed.

Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/ide/sii3112.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/hw/ide/sii3112.c b/hw/ide/sii3112.c
index e3896c65b4..743a50ed51 100644
--- a/hw/ide/sii3112.c
+++ b/hw/ide/sii3112.c
@@ -327,17 +327,6 @@ static void sii3112_pci_realize(PCIDevice *dev, Error **errp)
     qemu_register_reset(sii3112_reset, s);
 }
 
-static void sii3112_pci_exitfn(PCIDevice *dev)
-{
-    PCIIDEState *d = PCI_IDE(dev);
-    int i;
-
-    for (i = 0; i < 2; ++i) {
-        memory_region_del_subregion(&d->bmdma_bar, &d->bmdma[i].extra_io);
-        memory_region_del_subregion(&d->bmdma_bar, &d->bmdma[i].addr_ioport);
-    }
-}
-
 static void sii3112_pci_class_init(ObjectClass *klass, void *data)
 {
     DeviceClass *dc = DEVICE_CLASS(klass);
@@ -348,7 +337,6 @@ static void sii3112_pci_class_init(ObjectClass *klass, void *data)
     pd->class_id = PCI_CLASS_STORAGE_RAID;
     pd->revision = 1;
     pd->realize = sii3112_pci_realize;
-    pd->exit = sii3112_pci_exitfn;
     dc->desc = "SiI3112A SATA controller";
     set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
 }
-- 
2.14.3

[Qemu-devel] [PULL 2/9] tests/boot-serial: Check the 40p machine, too

[David Gibson]

From: Thomas Huth <thuth@redhat.com>

The "40p" machine is using the Open Hack'Ware BIOS, just like the "prep"
machine, so we can test it accordingly with the boot-serial tester, too.
While we're at it, also change the strings that we are using for the
"prep" machine, so that this test now also checks some CLI parameters.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 tests/boot-serial-test.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
index ece25c694f..5b24cd26c1 100644
--- a/tests/boot-serial-test.c
+++ b/tests/boot-serial-test.c
@@ -75,11 +75,13 @@ typedef struct testdef {
 static testdef_t tests[] = {
     { "alpha", "clipper", "", "PCI:" },
     { "ppc", "ppce500", "", "U-Boot" },
-    { "ppc", "prep", "", "Open Hack'Ware BIOS" },
+    { "ppc", "prep", "-m 96", "Memory size: 96 MB" },
+    { "ppc", "40p", "-boot d", "Booting from device d" },
     { "ppc", "g3beige", "", "PowerPC,750" },
     { "ppc", "mac99", "", "PowerPC,G4" },
     { "ppc64", "ppce500", "", "U-Boot" },
-    { "ppc64", "prep", "", "Open Hack'Ware BIOS" },
+    { "ppc64", "prep", "-boot e", "Booting from device e" },
+    { "ppc64", "40p", "-m 192", "Memory size: 192 MB" },
     { "ppc64", "mac99", "", "PowerPC,970FX" },
     { "ppc64", "pseries", "", "Open Firmware" },
     { "ppc64", "powernv", "-cpu POWER8", "OPAL" },
-- 
2.14.3

[Qemu-devel] [PULL 3/9] hw/ppc/prep: Fix implicit creation of "-drive if=scsi" devices

[David Gibson]

From: Thomas Huth <thuth@redhat.com>

The global hack for creating SCSI devices has recently been removed,
but this apparently broke SCSI devices on some boards that were not
ready for this change yet. For the 40p machine you now get:

$ ppc64-softmmu/qemu-system-ppc64 -M 40p -cdrom x.iso
qemu-system-ppc64: -cdrom x.iso: machine type does not support if=scsi,bus=0,unit=2

Fix it by providing a lsi53c810_create() function that takes care
of calling scsi_bus_legacy_handle_cmdline() after creating the
corresponding SCSI controller.

Fixes: 1454509726719e0933c800fad00d6999752688ea
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/ppc/prep.c        | 2 +-
 hw/scsi/lsi53c895a.c | 7 +++++++
 include/hw/pci/pci.h | 1 +
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index 096d4d4cfb..3361509a85 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -788,7 +788,7 @@ static void ibm_40p_init(MachineState *machine)
         qdev_prop_set_uint32(dev, "equipment", 0xc0);
         qdev_init_nofail(dev);
 
-        pci_create_simple(pci_bus, PCI_DEVFN(1, 0), "lsi53c810");
+        lsi53c810_create(pci_bus, PCI_DEVFN(1, 0));
 
         /* XXX: s3-trio at PCI_DEVFN(2, 0) */
         pci_vga_init(pci_bus);
diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c
index f3d4c4d230..160657f4b9 100644
--- a/hw/scsi/lsi53c895a.c
+++ b/hw/scsi/lsi53c895a.c
@@ -2279,3 +2279,10 @@ void lsi53c895a_create(PCIBus *bus)
 
     scsi_bus_legacy_handle_cmdline(&s->bus);
 }
+
+void lsi53c810_create(PCIBus *bus, int devfn)
+{
+    LSIState *s = LSI53C895A(pci_create_simple(bus, devfn, "lsi53c810"));
+
+    scsi_bus_legacy_handle_cmdline(&s->bus);
+}
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index d8c18c7fa4..e255941b5a 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -708,6 +708,7 @@ PCIDevice *pci_create(PCIBus *bus, int devfn, const char *name);
 PCIDevice *pci_create_simple(PCIBus *bus, int devfn, const char *name);
 
 void lsi53c895a_create(PCIBus *bus);
+void lsi53c810_create(PCIBus *bus, int devfn);
 
 qemu_irq pci_allocate_irq(PCIDevice *pci_dev);
 void pci_set_irq(PCIDevice *pci_dev, int level);
-- 
2.14.3

[Qemu-devel] [PULL 4/9] hw/misc/macio: Mark the macio devices with user_creatable = false

[David Gibson]

From: Thomas Huth <thuth@redhat.com>

The macio devices currently cause a crash when the user tries to
instantiate them on a different machine:

$ ppc64-softmmu/qemu-system-ppc64 -device macio-newworld
Unexpected error in qemu_chr_fe_init() at chardev/char-fe.c:222:
qemu-system-ppc64: -device macio-newworld: Device 'serial0' is in use
Aborted (core dumped)

These devices are clearly not intended to be creatable by the user
since they are using serial_hds[] directly in their instance_init
function. So let's mark them with user_creatable = false.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/misc/macio/macio.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/misc/macio/macio.c b/hw/misc/macio/macio.c
index af1bd46b4b..454244f59e 100644
--- a/hw/misc/macio/macio.c
+++ b/hw/misc/macio/macio.c
@@ -406,6 +406,8 @@ static void macio_class_init(ObjectClass *klass, void *data)
     k->class_id = PCI_CLASS_OTHERS << 8;
     dc->props = macio_properties;
     set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
+    /* Reason: Uses serial_hds in macio_instance_init */
+    dc->user_creatable = false;
 }
 
 static const TypeInfo macio_oldworld_type_info = {
-- 
2.14.3

[Qemu-devel] [PULL 5/9] PPC e500: Fix gap between u-boot and kernel

[David Gibson]

From: David Engraf <david.engraf@sysgo.com>

This patch moves the gap between u-boot and kernel at the correct location.

Signed-off-by: David Engraf <david.engraf@sysgo.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/ppc/e500.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index 43c15d18c4..bdef2bddc6 100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -1009,6 +1009,10 @@ void ppce500_init(MachineState *machine, PPCE500Params *params)
     }
 
     cur_base = loadaddr + payload_size;
+    if (cur_base < (32 * 1024 * 1024)) {
+        /* u-boot occupies memory up to 32MB, so load blobs above */
+        cur_base = (32 * 1024 * 1024);
+    }
 
     /* Load bare kernel only if no bios/u-boot has been provided */
     if (machine->kernel_filename && !kernel_as_payload) {
@@ -1025,11 +1029,6 @@ void ppce500_init(MachineState *machine, PPCE500Params *params)
         cur_base += kernel_size;
     }
 
-    if (cur_base < (32 * 1024 * 1024)) {
-        /* u-boot occupies memory up to 32MB, so load blobs above */
-        cur_base = (32 * 1024 * 1024);
-    }
-
     /* Load initrd. */
     if (machine->initrd_filename) {
         initrd_base = (cur_base + INITRD_LOAD_PAD) & ~INITRD_PAD_MASK;
-- 
2.14.3

[Qemu-devel] [PULL 6/9] hw/ppc/spapr: Allow "spapr-vlan" as NIC model name beside "ibmveth"

[David Gibson]

From: Thomas Huth <thuth@redhat.com>

With the new "--nic" command line parameter option, the "old" way of
specifying a NIC model via the nd_table[] is becoming more prominent
again. But for the pseries "spapr-vlan" device, there is a confusing
discrepancy between the model name that is used for "--device" (i.e.
"spapr-vlan") and the model name that has to be used for "--net nic"
or the new "--nic" parameter (i.e. "ibmveth"). Since "spapr-vlan" is
the "real" name of the device, let's allow "spapr-vlan" to be used
as model name for the nd_table[] entries, too.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/ppc/spapr.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 7e1c858566..dfa9e43601 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2607,10 +2607,11 @@ static void spapr_machine_init(MachineState *machine)
         NICInfo *nd = &nd_table[i];
 
         if (!nd->model) {
-            nd->model = g_strdup("ibmveth");
+            nd->model = g_strdup("spapr-vlan");
         }
 
-        if (strcmp(nd->model, "ibmveth") == 0) {
+        if (g_str_equal(nd->model, "spapr-vlan") ||
+            g_str_equal(nd->model, "ibmveth")) {
             spapr_vlan_create(spapr->vio_bus, nd);
         } else {
             pci_nic_init_nofail(&nd_table[i], phb->bus, nd->model, NULL);
-- 
2.14.3

[Qemu-devel] [PULL 7/9] ppc440_pcix: Change some error_report to qemu_log_mask(LOG_UNIMP, ...)

[David Gibson]

From: BALATON Zoltan <balaton@eik.bme.hu>

Using log unimp is more appropriate for these messages and this also
silences them by default so they won't clobber make check output when
tests are added for this board.

Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/ppc/ppc440_pcix.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/ppc440_pcix.c b/hw/ppc/ppc440_pcix.c
index ab2626a9de..b1307e6477 100644
--- a/hw/ppc/ppc440_pcix.c
+++ b/hw/ppc/ppc440_pcix.c
@@ -21,6 +21,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu/error-report.h"
+#include "qemu/log.h"
 #include "hw/hw.h"
 #include "hw/ppc/ppc.h"
 #include "hw/ppc/ppc4xx.h"
@@ -286,8 +287,9 @@ static void ppc440_pcix_reg_write4(void *opaque, hwaddr addr,
         break;
 
     default:
-        error_report("%s: unhandled PCI internal register 0x%lx", __func__,
-                     (unsigned long)addr);
+        qemu_log_mask(LOG_UNIMP,
+                      "%s: unhandled PCI internal register 0x%"HWADDR_PRIx"\n",
+                      __func__, addr);
         break;
     }
 }
@@ -377,8 +379,9 @@ static uint64_t ppc440_pcix_reg_read4(void *opaque, hwaddr addr,
         break;
 
     default:
-        error_report("%s: invalid PCI internal register 0x%lx", __func__,
-                     (unsigned long)addr);
+        qemu_log_mask(LOG_UNIMP,
+                      "%s: invalid PCI internal register 0x%" HWADDR_PRIx "\n",
+                      __func__, addr);
         val = 0;
     }
 
-- 
2.14.3

[Qemu-devel] [PULL 8/9] tests/boot-serial: Test the sam460ex board

[David Gibson]

From: Thomas Huth <thuth@redhat.com>

We've got a U-Boot firmware for this board in our repository, and
the firmware prints some output to the serial console, so we can
check this board in the boot-serial tester, too.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 tests/boot-serial-test.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
index 5b24cd26c1..011525d8cf 100644
--- a/tests/boot-serial-test.c
+++ b/tests/boot-serial-test.c
@@ -79,12 +79,14 @@ static testdef_t tests[] = {
     { "ppc", "40p", "-boot d", "Booting from device d" },
     { "ppc", "g3beige", "", "PowerPC,750" },
     { "ppc", "mac99", "", "PowerPC,G4" },
+    { "ppc", "sam460ex", "-m 256", "DRAM:  256 MiB" },
     { "ppc64", "ppce500", "", "U-Boot" },
     { "ppc64", "prep", "-boot e", "Booting from device e" },
     { "ppc64", "40p", "-m 192", "Memory size: 192 MB" },
     { "ppc64", "mac99", "", "PowerPC,970FX" },
     { "ppc64", "pseries", "", "Open Firmware" },
     { "ppc64", "powernv", "-cpu POWER8", "OPAL" },
+    { "ppc64", "sam460ex", "-device e1000", "8086  100e" },
     { "i386", "isapc", "-cpu qemu32 -device sga", "SGABIOS" },
     { "i386", "pc", "-device sga", "SGABIOS" },
     { "i386", "q35", "-device sga", "SGABIOS" },
-- 
2.14.3

[Qemu-devel] [PULL 9/9] target/ppc: fix tlbsync to check privilege level depending on GTSE

[David Gibson]

From: Cédric Le Goater <clg@kaod.org>

tlbsync also needs to check the Guest Translation Shootdown Enable
(GTSE) bit in the Logical Partition Control Register (LPCR) to
determine at which privilege level it is running.

See commit c6fd28fd573d ("target/ppc: Update tlbie to check privilege
level based on GTSE")

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 target/ppc/translate.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index 0a0c090c99..218665b408 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -4526,7 +4526,7 @@ static void gen_tlbie(DisasContext *ctx)
     TCGv_i32 t1;
 
     if (ctx->gtse) {
-        CHK_SV; /* If gtse is set then tblie is supervisor privileged */
+        CHK_SV; /* If gtse is set then tlbie is supervisor privileged */
     } else {
         CHK_HV; /* Else hypervisor privileged */
     }
@@ -4553,7 +4553,12 @@ static void gen_tlbsync(DisasContext *ctx)
 #if defined(CONFIG_USER_ONLY)
     GEN_PRIV;
 #else
-    CHK_HV;
+
+    if (ctx->gtse) {
+        CHK_SV; /* If gtse is set then tlbsync is supervisor privileged */
+    } else {
+        CHK_HV; /* Else hypervisor privileged */
+    }
 
     /* BookS does both ptesync and tlbsync make tlbsync a nop for server */
     if (ctx->insns_flags & PPC_BOOKE) {
-- 
2.14.3

Re: [Qemu-devel] [PULL 0/9] ppc-for-2.12 queue 20180315

[Peter Maydell]

On 15 March 2018 at 04:18, David Gibson <david@gibson.dropbear.id.au> wrote:
> The following changes since commit 026aaf47c02b79036feb830206cfebb2a726510d:
>
>   Merge remote-tracking branch 'remotes/ehabkost/tags/python-next-pull-request' into staging (2018-03-13 16:26:44 +0000)
>
> are available in the Git repository at:
>
>   git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180315
>
> for you to fetch changes up to a9ab8cc157054ea6941fb849c78d9e6c515a7730:
>
>   target/ppc: fix tlbsync to check privilege level depending on GTSE (2018-03-15 11:18:31 +1100)
>
> ----------------------------------------------------------------
> ppc patch queue for 2018-03-15
>
> Here's the set of accumulated patches now that we're into soft freeze.
> I've split new functionality into a ppc-for-2.13 branch, so this only
> has bugfixes.  Well.. and a couple of simple cleanups to make bugfixes
> easier, some test improvements and a trivial change to make command
> line options more obvious.  I think those are all acceptable for soft
> freeze.
>

Hi -- this looks like it provokes new runtime error warnings from the
clang sanitizer:

TEST: tests/boot-serial-test... (pid=926)
  /ppc/boot-serial/ppce500:                                            OK
  /ppc/boot-serial/prep:                                               OK
  /ppc/boot-serial/40p:                                                OK
  /ppc/boot-serial/g3beige:                                            OK
  /ppc/boot-serial/mac99:                                              OK
  /ppc/boot-serial/sam460ex:
/home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
runtime error: load of value 142, which is not a valid value for type
'bool'
OK

TEST: tests/boot-serial-test... (pid=1016)
  /ppc64/boot-serial/ppce500:                                          OK
  /ppc64/boot-serial/prep:                                             OK
  /ppc64/boot-serial/40p:                                              OK
  /ppc64/boot-serial/mac99:                                            OK
  /ppc64/boot-serial/pseries:                                          OK
  /ppc64/boot-serial/powernv:                                          OK
  /ppc64/boot-serial/sam460ex:
/home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
runtime error: load of value 85, which is not a valid value for type
'bool'
OK

Looks like you're not initializing ctx->lazy_tlb_flush for all configs:
    if (env->mmu_model == POWERPC_MMU_32B ||
        env->mmu_model == POWERPC_MMU_601 ||
        (env->mmu_model & POWERPC_MMU_64B))
            ctx->lazy_tlb_flush = true;

should perhaps be
    ctx->lazy_tlb_flush =
        env->mmu_model == POWERPC_MMU_32B ||
        env->mmu_model == POWERPC_MMU_601 ||
        (env->mmu_model & POWERPC_MMU_64B);

?

thanks
-- PMM

Re: [Qemu-devel] [PULL 0/9] ppc-for-2.12 queue 20180315

[David Gibson]

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

On Fri, Mar 16, 2018 at 05:25:04PM +0000, Peter Maydell wrote:
> On 15 March 2018 at 04:18, David Gibson <david@gibson.dropbear.id.au> wrote:
> > The following changes since commit 026aaf47c02b79036feb830206cfebb2a726510d:
> >
> >   Merge remote-tracking branch 'remotes/ehabkost/tags/python-next-pull-request' into staging (2018-03-13 16:26:44 +0000)
> >
> > are available in the Git repository at:
> >
> >   git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180315
> >
> > for you to fetch changes up to a9ab8cc157054ea6941fb849c78d9e6c515a7730:
> >
> >   target/ppc: fix tlbsync to check privilege level depending on GTSE (2018-03-15 11:18:31 +1100)
> >
> > ----------------------------------------------------------------
> > ppc patch queue for 2018-03-15
> >
> > Here's the set of accumulated patches now that we're into soft freeze.
> > I've split new functionality into a ppc-for-2.13 branch, so this only
> > has bugfixes.  Well.. and a couple of simple cleanups to make bugfixes
> > easier, some test improvements and a trivial change to make command
> > line options more obvious.  I think those are all acceptable for soft
> > freeze.
> >
> 
> Hi -- this looks like it provokes new runtime error warnings from the
> clang sanitizer:

Hrm.  What options do you need to trip these warnings?  Just using
--cc=clang doesn't give them to me, and using --enable-sanitizers
gives my piles of unrelated warnings.

> 
> TEST: tests/boot-serial-test... (pid=926)
>   /ppc/boot-serial/ppce500:                                            OK
>   /ppc/boot-serial/prep:                                               OK
>   /ppc/boot-serial/40p:                                                OK
>   /ppc/boot-serial/g3beige:                                            OK
>   /ppc/boot-serial/mac99:                                              OK
>   /ppc/boot-serial/sam460ex:
> /home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
> runtime error: load of value 142, which is not a valid value for type
> 'bool'
> OK
> 
> TEST: tests/boot-serial-test... (pid=1016)
>   /ppc64/boot-serial/ppce500:                                          OK
>   /ppc64/boot-serial/prep:                                             OK
>   /ppc64/boot-serial/40p:                                              OK
>   /ppc64/boot-serial/mac99:                                            OK
>   /ppc64/boot-serial/pseries:                                          OK
>   /ppc64/boot-serial/powernv:                                          OK
>   /ppc64/boot-serial/sam460ex:
> /home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
> runtime error: load of value 85, which is not a valid value for type
> 'bool'
> OK
> 
> Looks like you're not initializing ctx->lazy_tlb_flush for all configs:
>     if (env->mmu_model == POWERPC_MMU_32B ||
>         env->mmu_model == POWERPC_MMU_601 ||
>         (env->mmu_model & POWERPC_MMU_64B))
>             ctx->lazy_tlb_flush = true;
> 
> should perhaps be
>     ctx->lazy_tlb_flush =
>         env->mmu_model == POWERPC_MMU_32B ||
>         env->mmu_model == POWERPC_MMU_601 ||
>         (env->mmu_model & POWERPC_MMU_64B);
> 
> ?

Uh.. maybe.. except I don't see anything in the series that would be
likely to change that behaviour.

-- 
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 --]

Re: [Qemu-devel] [PULL 0/9] ppc-for-2.12 queue 20180315

[Peter Maydell]

On 17 March 2018 at 04:02, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Fri, Mar 16, 2018 at 05:25:04PM +0000, Peter Maydell wrote:
>> Hi -- this looks like it provokes new runtime error warnings from the
>> clang sanitizer:
>
> Hrm.  What options do you need to trip these warnings?  Just using
> --cc=clang doesn't give them to me, and using --enable-sanitizers
> gives my piles of unrelated warnings.

https://wiki.qemu.org/Testing#clang_UBSan documents the necessary
cflags.

>
>>
>> TEST: tests/boot-serial-test... (pid=926)
>>   /ppc/boot-serial/ppce500:                                            OK
>>   /ppc/boot-serial/prep:                                               OK
>>   /ppc/boot-serial/40p:                                                OK
>>   /ppc/boot-serial/g3beige:                                            OK
>>   /ppc/boot-serial/mac99:                                              OK
>>   /ppc/boot-serial/sam460ex:
>> /home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
>> runtime error: load of value 142, which is not a valid value for type
>> 'bool'
>> OK
>>
>> TEST: tests/boot-serial-test... (pid=1016)
>>   /ppc64/boot-serial/ppce500:                                          OK
>>   /ppc64/boot-serial/prep:                                             OK
>>   /ppc64/boot-serial/40p:                                              OK
>>   /ppc64/boot-serial/mac99:                                            OK
>>   /ppc64/boot-serial/pseries:                                          OK
>>   /ppc64/boot-serial/powernv:                                          OK
>>   /ppc64/boot-serial/sam460ex:
>> /home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
>> runtime error: load of value 85, which is not a valid value for type
>> 'bool'
>> OK
>>
>> Looks like you're not initializing ctx->lazy_tlb_flush for all configs:
>>     if (env->mmu_model == POWERPC_MMU_32B ||
>>         env->mmu_model == POWERPC_MMU_601 ||
>>         (env->mmu_model & POWERPC_MMU_64B))
>>             ctx->lazy_tlb_flush = true;
>>
>> should perhaps be
>>     ctx->lazy_tlb_flush =
>>         env->mmu_model == POWERPC_MMU_32B ||
>>         env->mmu_model == POWERPC_MMU_601 ||
>>         (env->mmu_model & POWERPC_MMU_64B);
>>
>> ?
>
> Uh.. maybe.. except I don't see anything in the series that would be
> likely to change that behaviour.

I imagine it's "tests/boot-serial: Test the sam460ex board" --
this code was previously not being exercised in 'make check',
and now it is.

thanks
-- PMM

Re: [Qemu-devel] [Qemu-ppc] [PULL 0/9] ppc-for-2.12 queue 20180315

[BALATON Zoltan]

On Sat, 17 Mar 2018, Peter Maydell wrote:
> On 17 March 2018 at 04:02, David Gibson <david@gibson.dropbear.id.au> wrote:
>> On Fri, Mar 16, 2018 at 05:25:04PM +0000, Peter Maydell wrote:
>>> Hi -- this looks like it provokes new runtime error warnings from the
>>> clang sanitizer:
>>
>> Hrm.  What options do you need to trip these warnings?  Just using
>> --cc=clang doesn't give them to me, and using --enable-sanitizers
>> gives my piles of unrelated warnings.
>
> https://wiki.qemu.org/Testing#clang_UBSan documents the necessary
> cflags.
>
>>
>>>
>>> TEST: tests/boot-serial-test... (pid=926)
>>>   /ppc/boot-serial/ppce500:                                            OK
>>>   /ppc/boot-serial/prep:                                               OK
>>>   /ppc/boot-serial/40p:                                                OK
>>>   /ppc/boot-serial/g3beige:                                            OK
>>>   /ppc/boot-serial/mac99:                                              OK
>>>   /ppc/boot-serial/sam460ex:
>>> /home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
>>> runtime error: load of value 142, which is not a valid value for type
>>> 'bool'
>>> OK
>>>
>>> TEST: tests/boot-serial-test... (pid=1016)
>>>   /ppc64/boot-serial/ppce500:                                          OK
>>>   /ppc64/boot-serial/prep:                                             OK
>>>   /ppc64/boot-serial/40p:                                              OK
>>>   /ppc64/boot-serial/mac99:                                            OK
>>>   /ppc64/boot-serial/pseries:                                          OK
>>>   /ppc64/boot-serial/powernv:                                          OK
>>>   /ppc64/boot-serial/sam460ex:
>>> /home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
>>> runtime error: load of value 85, which is not a valid value for type
>>> 'bool'
>>> OK
>>>
>>> Looks like you're not initializing ctx->lazy_tlb_flush for all configs:
>>>     if (env->mmu_model == POWERPC_MMU_32B ||
>>>         env->mmu_model == POWERPC_MMU_601 ||
>>>         (env->mmu_model & POWERPC_MMU_64B))
>>>             ctx->lazy_tlb_flush = true;
>>>
>>> should perhaps be
>>>     ctx->lazy_tlb_flush =
>>>         env->mmu_model == POWERPC_MMU_32B ||
>>>         env->mmu_model == POWERPC_MMU_601 ||
>>>         (env->mmu_model & POWERPC_MMU_64B);
>>>
>>> ?
>>
>> Uh.. maybe.. except I don't see anything in the series that would be
>> likely to change that behaviour.
>
> I imagine it's "tests/boot-serial: Test the sam460ex board" --
> this code was previously not being exercised in 'make check',
> and now it is.

I'm not sure what could cause this in case of sam460ex. It has PPC440 
which has POWERPC_MMU_BOOKE but the ppce500 should also have that and a 
similar u-boot and that does not produce this error. Is there maybe some 
initialisation of some structure I've missed somewhere? But these 
DisasContext structs seem to be internal to TCG so I'm not sure what could 
be missing outside of TCG to avoid this. Could be that the different 
u-boot version does something that triggers this while the one for ppce500 
does not execute code that causes this warning during the test?

Regards,
BALATON Zoltan

Re: [Qemu-devel] [Qemu-ppc] [PULL 0/9] ppc-for-2.12 queue 20180315

[BALATON Zoltan]

On Sat, 17 Mar 2018, BALATON Zoltan wrote:
> On Sat, 17 Mar 2018, Peter Maydell wrote:
>> On 17 March 2018 at 04:02, David Gibson <david@gibson.dropbear.id.au> 
>> wrote:
>>> On Fri, Mar 16, 2018 at 05:25:04PM +0000, Peter Maydell wrote:
>>>> Hi -- this looks like it provokes new runtime error warnings from the
>>>> clang sanitizer:
>>> 
>>> Hrm.  What options do you need to trip these warnings?  Just using
>>> --cc=clang doesn't give them to me, and using --enable-sanitizers
>>> gives my piles of unrelated warnings.
>> 
>> https://wiki.qemu.org/Testing#clang_UBSan documents the necessary
>> cflags.
>> 
>>> 
>>>> 
>>>> TEST: tests/boot-serial-test... (pid=926)
>>>>   /ppc/boot-serial/ppce500:                                            OK
>>>>   /ppc/boot-serial/prep:                                               OK
>>>>   /ppc/boot-serial/40p:                                                OK
>>>>   /ppc/boot-serial/g3beige:                                            OK
>>>>   /ppc/boot-serial/mac99:                                              OK
>>>>   /ppc/boot-serial/sam460ex:
>>>> /home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
>>>> runtime error: load of value 142, which is not a valid value for type
>>>> 'bool'
>>>> OK
>>>> 
>>>> TEST: tests/boot-serial-test... (pid=1016)
>>>>   /ppc64/boot-serial/ppce500:                                          OK
>>>>   /ppc64/boot-serial/prep:                                             OK
>>>>   /ppc64/boot-serial/40p:                                              OK
>>>>   /ppc64/boot-serial/mac99:                                            OK
>>>>   /ppc64/boot-serial/pseries:                                          OK
>>>>   /ppc64/boot-serial/powernv:                                          OK
>>>>   /ppc64/boot-serial/sam460ex:
>>>> /home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
>>>> runtime error: load of value 85, which is not a valid value for type
>>>> 'bool'
>>>> OK
>>>> 
>>>> Looks like you're not initializing ctx->lazy_tlb_flush for all configs:
>>>>     if (env->mmu_model == POWERPC_MMU_32B ||
>>>>         env->mmu_model == POWERPC_MMU_601 ||
>>>>         (env->mmu_model & POWERPC_MMU_64B))
>>>>             ctx->lazy_tlb_flush = true;
>>>> 
>>>> should perhaps be
>>>>     ctx->lazy_tlb_flush =
>>>>         env->mmu_model == POWERPC_MMU_32B ||
>>>>         env->mmu_model == POWERPC_MMU_601 ||
>>>>         (env->mmu_model & POWERPC_MMU_64B);
>>>> 
>>>> ?
>>> 
>>> Uh.. maybe.. except I don't see anything in the series that would be
>>> likely to change that behaviour.
>> 
>> I imagine it's "tests/boot-serial: Test the sam460ex board" --
>> this code was previously not being exercised in 'make check',
>> and now it is.
>
> I'm not sure what could cause this in case of sam460ex. It has PPC440 which 
> has POWERPC_MMU_BOOKE but the ppce500 should also have that and a similar 
> u-boot and that does not produce this error. Is there maybe some 
> initialisation of some structure I've missed somewhere? But these 
> DisasContext structs seem to be internal to TCG so I'm not sure what could be 
> missing outside of TCG to avoid this. Could be that the different u-boot 
> version does something that triggers this while the one for ppce500 does not 
> execute code that causes this warning during the test?

Oops, replied too soon. I've checked e500 and it seems to have 
POWERPC_MMU_BOOKE206 (I thought e500 was BookE but I don't know these very 
well). Only bamboo, virtex-ml507 and sam460ex seem to be POWERPC_MMU_BOOKE 
so if only the sam460ex test is added now and the others were never tested 
then it could be this is the first time this is catched.

Regards,
BALATON Zoltan

Re: [Qemu-devel] [Qemu-ppc] [PULL 0/9] ppc-for-2.12 queue 20180315

[David Gibson]

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

On Sat, Mar 17, 2018 at 12:30:58PM +0100, BALATON Zoltan wrote:
> On Sat, 17 Mar 2018, BALATON Zoltan wrote:
> > On Sat, 17 Mar 2018, Peter Maydell wrote:
> > > On 17 March 2018 at 04:02, David Gibson
> > > <david@gibson.dropbear.id.au> wrote:
> > > > On Fri, Mar 16, 2018 at 05:25:04PM +0000, Peter Maydell wrote:
> > > > > Hi -- this looks like it provokes new runtime error warnings from the
> > > > > clang sanitizer:
> > > > 
> > > > Hrm.  What options do you need to trip these warnings?  Just using
> > > > --cc=clang doesn't give them to me, and using --enable-sanitizers
> > > > gives my piles of unrelated warnings.
> > > 
> > > https://wiki.qemu.org/Testing#clang_UBSan documents the necessary
> > > cflags.
> > > 
> > > > 
> > > > > 
> > > > > TEST: tests/boot-serial-test... (pid=926)
> > > > >   /ppc/boot-serial/ppce500:                                            OK
> > > > >   /ppc/boot-serial/prep:                                               OK
> > > > >   /ppc/boot-serial/40p:                                                OK
> > > > >   /ppc/boot-serial/g3beige:                                            OK
> > > > >   /ppc/boot-serial/mac99:                                              OK
> > > > >   /ppc/boot-serial/sam460ex:
> > > > > /home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
> > > > > runtime error: load of value 142, which is not a valid value for type
> > > > > 'bool'
> > > > > OK
> > > > > 
> > > > > TEST: tests/boot-serial-test... (pid=1016)
> > > > >   /ppc64/boot-serial/ppce500:                                          OK
> > > > >   /ppc64/boot-serial/prep:                                             OK
> > > > >   /ppc64/boot-serial/40p:                                              OK
> > > > >   /ppc64/boot-serial/mac99:                                            OK
> > > > >   /ppc64/boot-serial/pseries:                                          OK
> > > > >   /ppc64/boot-serial/powernv:                                          OK
> > > > >   /ppc64/boot-serial/sam460ex:
> > > > > /home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
> > > > > runtime error: load of value 85, which is not a valid value for type
> > > > > 'bool'
> > > > > OK
> > > > > 
> > > > > Looks like you're not initializing ctx->lazy_tlb_flush for all configs:
> > > > >     if (env->mmu_model == POWERPC_MMU_32B ||
> > > > >         env->mmu_model == POWERPC_MMU_601 ||
> > > > >         (env->mmu_model & POWERPC_MMU_64B))
> > > > >             ctx->lazy_tlb_flush = true;
> > > > > 
> > > > > should perhaps be
> > > > >     ctx->lazy_tlb_flush =
> > > > >         env->mmu_model == POWERPC_MMU_32B ||
> > > > >         env->mmu_model == POWERPC_MMU_601 ||
> > > > >         (env->mmu_model & POWERPC_MMU_64B);
> > > > > 
> > > > > ?
> > > > 
> > > > Uh.. maybe.. except I don't see anything in the series that would be
> > > > likely to change that behaviour.
> > > 
> > > I imagine it's "tests/boot-serial: Test the sam460ex board" --
> > > this code was previously not being exercised in 'make check',
> > > and now it is.
> > 
> > I'm not sure what could cause this in case of sam460ex. It has PPC440
> > which has POWERPC_MMU_BOOKE but the ppce500 should also have that and a
> > similar u-boot and that does not produce this error. Is there maybe some
> > initialisation of some structure I've missed somewhere? But these
> > DisasContext structs seem to be internal to TCG so I'm not sure what
> > could be missing outside of TCG to avoid this. Could be that the
> > different u-boot version does something that triggers this while the one
> > for ppce500 does not execute code that causes this warning during the
> > test?
> 
> Oops, replied too soon. I've checked e500 and it seems to have
> POWERPC_MMU_BOOKE206 (I thought e500 was BookE but I don't know these very
> well). Only bamboo, virtex-ml507 and sam460ex seem to be POWERPC_MMU_BOOKE
> so if only the sam460ex test is added now and the others were never tested
> then it could be this is the first time this is catched.

Thanks for the pointer.  I've now confirmed that the sam460ex test was
the problem.

-- 
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 --]

Re: [Qemu-devel] [PULL 0/9] ppc-for-2.12 queue 20180315

[David Gibson]

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

On Sat, Mar 17, 2018 at 10:08:26AM +0000, Peter Maydell wrote:
> On 17 March 2018 at 04:02, David Gibson <david@gibson.dropbear.id.au> wrote:
> > On Fri, Mar 16, 2018 at 05:25:04PM +0000, Peter Maydell wrote:
> >> Hi -- this looks like it provokes new runtime error warnings from the
> >> clang sanitizer:
> >
> > Hrm.  What options do you need to trip these warnings?  Just using
> > --cc=clang doesn't give them to me, and using --enable-sanitizers
> > gives my piles of unrelated warnings.
> 
> https://wiki.qemu.org/Testing#clang_UBSan documents the necessary
> cflags.

Thanks.

> >> TEST: tests/boot-serial-test... (pid=926)
> >>   /ppc/boot-serial/ppce500:                                            OK
> >>   /ppc/boot-serial/prep:                                               OK
> >>   /ppc/boot-serial/40p:                                                OK
> >>   /ppc/boot-serial/g3beige:                                            OK
> >>   /ppc/boot-serial/mac99:                                              OK
> >>   /ppc/boot-serial/sam460ex:
> >> /home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
> >> runtime error: load of value 142, which is not a valid value for type
> >> 'bool'
> >> OK
> >>
> >> TEST: tests/boot-serial-test... (pid=1016)
> >>   /ppc64/boot-serial/ppce500:                                          OK
> >>   /ppc64/boot-serial/prep:                                             OK
> >>   /ppc64/boot-serial/40p:                                              OK
> >>   /ppc64/boot-serial/mac99:                                            OK
> >>   /ppc64/boot-serial/pseries:                                          OK
> >>   /ppc64/boot-serial/powernv:                                          OK
> >>   /ppc64/boot-serial/sam460ex:
> >> /home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
> >> runtime error: load of value 85, which is not a valid value for type
> >> 'bool'
> >> OK
> >>
> >> Looks like you're not initializing ctx->lazy_tlb_flush for all configs:
> >>     if (env->mmu_model == POWERPC_MMU_32B ||
> >>         env->mmu_model == POWERPC_MMU_601 ||
> >>         (env->mmu_model & POWERPC_MMU_64B))
> >>             ctx->lazy_tlb_flush = true;
> >>
> >> should perhaps be
> >>     ctx->lazy_tlb_flush =
> >>         env->mmu_model == POWERPC_MMU_32B ||
> >>         env->mmu_model == POWERPC_MMU_601 ||
> >>         (env->mmu_model & POWERPC_MMU_64B);
> >>
> >> ?
> >
> > Uh.. maybe.. except I don't see anything in the series that would be
> > likely to change that behaviour.
> 
> I imagine it's "tests/boot-serial: Test the sam460ex board" --
> this code was previously not being exercised in 'make check',
> and now it is.

Yeah, looks like.

-- 
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 --]

Re: [Qemu-devel] [Qemu-ppc] [PULL 0/9] ppc-for-2.12 queue 20180315

[Thomas Huth]

On 17.03.2018 12:30, BALATON Zoltan wrote:
> On Sat, 17 Mar 2018, BALATON Zoltan wrote:
>> On Sat, 17 Mar 2018, Peter Maydell wrote:
[...]
>>>>>   /ppc64/boot-serial/sam460ex:
>>>>> /home/petmay01/linaro/qemu-for-merges/target/ppc/translate.c:2979:15:
>>>>> runtime error: load of value 85, which is not a valid value for type
>>>>> 'bool'
>>>>> OK
>>>>>
>>>>> Looks like you're not initializing ctx->lazy_tlb_flush for all
>>>>> configs:
>>>>>     if (env->mmu_model == POWERPC_MMU_32B ||
>>>>>         env->mmu_model == POWERPC_MMU_601 ||
>>>>>         (env->mmu_model & POWERPC_MMU_64B))
>>>>>             ctx->lazy_tlb_flush = true;
>>>>>
>>>>> should perhaps be
>>>>>     ctx->lazy_tlb_flush =
>>>>>         env->mmu_model == POWERPC_MMU_32B ||
>>>>>         env->mmu_model == POWERPC_MMU_601 ||
>>>>>         (env->mmu_model & POWERPC_MMU_64B);
>>>>>
>>>>> ?
>>>>
>>>> Uh.. maybe.. except I don't see anything in the series that would be
>>>> likely to change that behaviour.
>>>
>>> I imagine it's "tests/boot-serial: Test the sam460ex board" --
>>> this code was previously not being exercised in 'make check',
>>> and now it is.
>>
>> I'm not sure what could cause this in case of sam460ex. It has PPC440
>> which has POWERPC_MMU_BOOKE but the ppce500 should also have that and
>> a similar u-boot and that does not produce this error. Is there maybe
>> some initialisation of some structure I've missed somewhere? But these
>> DisasContext structs seem to be internal to TCG so I'm not sure what
>> could be missing outside of TCG to avoid this. Could be that the
>> different u-boot version does something that triggers this while the
>> one for ppce500 does not execute code that causes this warning during
>> the test?
> 
> Oops, replied too soon. I've checked e500 and it seems to have
> POWERPC_MMU_BOOKE206 (I thought e500 was BookE but I don't know these
> very well). Only bamboo, virtex-ml507 and sam460ex seem to be
> POWERPC_MMU_BOOKE so if only the sam460ex test is added now and the
> others were never tested then it could be this is the first time this is
> catched.

Right, bamboo and virtex-ml507 do not ship with a pre-built firmware
image, so they are *not* tested in the boot-serial tester. ppce500 is
the only embedded PPC board that is tested so far. So it's good that we
finally have one more test case for an additional CPU type here :-)

 Thomas