[Qemu-devel] [PULL 0/6] ppc patch queue 2017-08-09

[Qemu-devel] [PULL 0/6] ppc patch queue 2017-08-09

[David Gibson]

The following changes since commit 54affb3a3623b1d36c95e34faa722a5831323a74:

  Update version for v2.10.0-rc2 release (2017-08-08 19:07:46 +0100)

are available in the git repository at:

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

for you to fetch changes up to f57467e3b326c7736f8e481fd6b680f30e575c87:

  spapr: Fix bug in h_signal_sys_reset() (2017-08-09 14:04:28 +1000)

----------------------------------------------------------------
ppc patch queue 2017-08-09

This series contains a number of bugfixes for ppc and related
machines, for the qemu-2.10.release.  Some are true regressions,
others are serious enough and non-invasive enough to fix that it's
worth putting in 2.10 this late.

----------------------------------------------------------------

I haven't completed a Travis build for this, which is part of my usual
test regime, since the first dozen or so Travis builds are failing
more often than not on master as well.  I don't know why this is -
seems to be failing some of the x86 tests.


David Gibson (2):
      target/ppc: Implement TIDR
      target/ppc: Add stub implementation of the PSSCR

Greg Kurz (2):
      ppc: fix double-free in cpu_post_load()
      spapr_drc: abort if object_property_add_child() fails

KONRAD Frederic (1):
      booke206: fix MAS update on tlb miss

Sam Bobroff (1):
      spapr: Fix bug in h_signal_sys_reset()

 hw/ppc/spapr_drc.c          |  2 +-
 hw/ppc/spapr_hcall.c        |  9 ++++-----
 target/ppc/cpu.h            |  2 ++
 target/ppc/machine.c        |  1 -
 target/ppc/mmu_helper.c     |  2 +-
 target/ppc/translate_init.c | 10 ++++++++++
 6 files changed, 18 insertions(+), 8 deletions(-)

[Qemu-devel] [PULL 1/6] booke206: fix MAS update on tlb miss

[David Gibson]

From: KONRAD Frederic <frederic.konrad@adacore.com>

When a tlb instruction miss happen, rw is set to 0 at the bottom
of cpu_ppc_handle_mmu_fault which cause the MAS update function to miss
the SAS and TS bit in MAS6, MAS1 in booke206_update_mas_tlb_miss.

Just calling booke206_update_mas_tlb_miss with rw = 2 solve the issue.

Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 target/ppc/mmu_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c
index b7b9088842..f06b9382b4 100644
--- a/target/ppc/mmu_helper.c
+++ b/target/ppc/mmu_helper.c
@@ -1551,7 +1551,7 @@ static int cpu_ppc_handle_mmu_fault(CPUPPCState *env, target_ulong address,
                     env->spr[SPR_40x_ESR] = 0x00000000;
                     break;
                 case POWERPC_MMU_BOOKE206:
-                    booke206_update_mas_tlb_miss(env, address, rw);
+                    booke206_update_mas_tlb_miss(env, address, 2);
                     /* fall through */
                 case POWERPC_MMU_BOOKE:
                     cs->exception_index = POWERPC_EXCP_ITLB;
-- 
2.13.4

[Qemu-devel] [PULL 2/6] ppc: fix double-free in cpu_post_load()

[David Gibson]

From: Greg Kurz <groug@kaod.org>

When running nested with KVM PR, ppc_set_compat() fails and QEMU crashes
because of "double free or corruption (!prev)". The crash happens because
error_report_err() has already called error_free().

Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 target/ppc/machine.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/target/ppc/machine.c b/target/ppc/machine.c
index f578156dd4..abe0a1cdf0 100644
--- a/target/ppc/machine.c
+++ b/target/ppc/machine.c
@@ -239,7 +239,6 @@ static int cpu_post_load(void *opaque, int version_id)
         ppc_set_compat(cpu, cpu->compat_pvr, &local_err);
         if (local_err) {
             error_report_err(local_err);
-            error_free(local_err);
             return -1;
         }
     } else
-- 
2.13.4

[Qemu-devel] [PULL 3/6] target/ppc: Implement TIDR

[David Gibson]

This adds a trivial implementation of the TIDR register added in
POWER9.  This isn't particularly important to qemu directly - it's
used by accelerator modules that we don't emulate.

However, since qemu isn't aware of it, its state is not synchronized
with KVM and therefore not migrated, which can be a problem.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
---
 target/ppc/cpu.h            | 1 +
 target/ppc/translate_init.c | 5 +++++
 2 files changed, 6 insertions(+)

diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index 6ee2a26a96..f6e5413fad 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -1451,6 +1451,7 @@ void ppc_compat_add_property(Object *obj, const char *name,
 #define SPR_TEXASR            (0x082)
 #define SPR_TEXASRU           (0x083)
 #define SPR_UCTRL             (0x088)
+#define SPR_TIDR              (0x090)
 #define SPR_MPC_CMPA          (0x090)
 #define SPR_MPC_CMPB          (0x091)
 #define SPR_MPC_CMPC          (0x092)
diff --git a/target/ppc/translate_init.c b/target/ppc/translate_init.c
index 01723bdfec..94800cd29d 100644
--- a/target/ppc/translate_init.c
+++ b/target/ppc/translate_init.c
@@ -8841,6 +8841,11 @@ static void init_proc_POWER9(CPUPPCState *env)
     gen_spr_power8_book4(env);
     gen_spr_power8_rpr(env);
 
+    /* POWER9 Specific registers */
+    spr_register_kvm(env, SPR_TIDR, "TIDR", NULL, NULL,
+                     spr_read_generic, spr_write_generic,
+                     KVM_REG_PPC_TIDR, 0);
+
     /* env variables */
 #if !defined(CONFIG_USER_ONLY)
     env->slb_nr = 32;
-- 
2.13.4

[Qemu-devel] [PULL 4/6] target/ppc: Add stub implementation of the PSSCR

[David Gibson]

The PSSCR register added in POWER9 controls certain power saving mode
behaviours.  Mostly, it's not relevant to TCG, however because qemu
doesn't know about it yet, it doesn't synchronize the state with KVM,
and thus it doesn't get migrated.

To fix that, this adds a minimal stub implementation of the register.
This isn't complete, even to the extent that an implementation is
possible in TCG, just enough to get migration working.  We need to
come back later and at least properly filter the various fields in the
register based on privilege level.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
---
 target/ppc/cpu.h            | 1 +
 target/ppc/translate_init.c | 5 +++++
 2 files changed, 6 insertions(+)

diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index f6e5413fad..46d3dd88f6 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -1771,6 +1771,7 @@ void ppc_compat_add_property(Object *obj, const char *name,
 #define SPR_IC                (0x350)
 #define SPR_VTB               (0x351)
 #define SPR_MMCRC             (0x353)
+#define SPR_PSSCR             (0x357)
 #define SPR_440_INV0          (0x370)
 #define SPR_440_INV1          (0x371)
 #define SPR_440_INV2          (0x372)
diff --git a/target/ppc/translate_init.c b/target/ppc/translate_init.c
index 94800cd29d..8fb407ed73 100644
--- a/target/ppc/translate_init.c
+++ b/target/ppc/translate_init.c
@@ -8846,6 +8846,11 @@ static void init_proc_POWER9(CPUPPCState *env)
                      spr_read_generic, spr_write_generic,
                      KVM_REG_PPC_TIDR, 0);
 
+    /* FIXME: Filter fields properly based on privilege level */
+    spr_register_kvm_hv(env, SPR_PSSCR, "PSSCR", NULL, NULL, NULL, NULL,
+                        spr_read_generic, spr_write_generic,
+                        KVM_REG_PPC_PSSCR, 0);
+
     /* env variables */
 #if !defined(CONFIG_USER_ONLY)
     env->slb_nr = 32;
-- 
2.13.4

[Qemu-devel] [PULL 5/6] spapr_drc: abort if object_property_add_child() fails

[David Gibson]

From: Greg Kurz <groug@kaod.org>

object_property_add_child() can only fail in two cases:
- the child already has a parent, which shouldn't happen since the DRC was
  allocated a few lines above
- the parent already has a child with the same name, which would mean the
  caller tries to create a DRC that already exists

In both case, this is a QEMU bug and we should abort.

Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/ppc/spapr_drc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
index 47d94e782a..5260b5d363 100644
--- a/hw/ppc/spapr_drc.c
+++ b/hw/ppc/spapr_drc.c
@@ -541,7 +541,7 @@ sPAPRDRConnector *spapr_dr_connector_new(Object *owner, const char *type,
     drc->owner = owner;
     prop_name = g_strdup_printf("dr-connector[%"PRIu32"]",
                                 spapr_drc_index(drc));
-    object_property_add_child(owner, prop_name, OBJECT(drc), NULL);
+    object_property_add_child(owner, prop_name, OBJECT(drc), &error_abort);
     object_property_set_bool(OBJECT(drc), true, "realized", NULL);
     g_free(prop_name);
 
-- 
2.13.4

[Qemu-devel] [PULL 6/6] spapr: Fix bug in h_signal_sys_reset()

[David Gibson]

From: Sam Bobroff <sam.bobroff@au1.ibm.com>

The unicast case in h_signal_sys_reset() seems to be broken:
rather than selecting the target CPU, it looks like it will pick
either the first CPU or fail to find one at all.

Fix it by using the search function rather than open coding the
search.

This was found by inspection; the code appears to be unused because
the Linux kernel only uses the broadcast target.

Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/ppc/spapr_hcall.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 72ea5a8247..07b3da8dc4 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1431,11 +1431,10 @@ static target_ulong h_signal_sys_reset(PowerPCCPU *cpu,
 
     } else {
         /* Unicast */
-        CPU_FOREACH(cs) {
-            if (cpu->cpu_dt_id == target) {
-                run_on_cpu(cs, spapr_do_system_reset_on_cpu, RUN_ON_CPU_NULL);
-                return H_SUCCESS;
-            }
+        cs = CPU(ppc_get_vcpu_by_dt_id(target));
+        if (cs) {
+            run_on_cpu(cs, spapr_do_system_reset_on_cpu, RUN_ON_CPU_NULL);
+            return H_SUCCESS;
         }
         return H_PARAMETER;
     }
-- 
2.13.4

Re: [Qemu-devel] [PULL 0/6] ppc patch queue 2017-08-09

[Peter Maydell]

On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote:
> The following changes since commit 54affb3a3623b1d36c95e34faa722a5831323a74:
>
>   Update version for v2.10.0-rc2 release (2017-08-08 19:07:46 +0100)
>
> are available in the git repository at:
>
>   git://github.com/dgibson/qemu.git tags/ppc-for-2.10-20170809
>
> for you to fetch changes up to f57467e3b326c7736f8e481fd6b680f30e575c87:
>
>   spapr: Fix bug in h_signal_sys_reset() (2017-08-09 14:04:28 +1000)
>
> ----------------------------------------------------------------
> ppc patch queue 2017-08-09
>
> This series contains a number of bugfixes for ppc and related
> machines, for the qemu-2.10.release.  Some are true regressions,
> others are serious enough and non-invasive enough to fix that it's
> worth putting in 2.10 this late.
>
> ----------------------------------------------------------------

Applied, thanks.

> I haven't completed a Travis build for this, which is part of my usual
> test regime, since the first dozen or so Travis builds are failing
> more often than not on master as well.  I don't know why this is -
> seems to be failing some of the x86 tests.

Doesn't look much worse than usual to me -- of the last 24 travis
builds for master 4 failed and 20 passed.

thanks
-- PMM

Re: [Qemu-devel] [PULL 0/6] ppc patch queue 2017-08-09

[David Gibson]

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

On Thu, Aug 10, 2017 at 01:47:03PM +0100, Peter Maydell wrote:
> On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote:
> > The following changes since commit 54affb3a3623b1d36c95e34faa722a5831323a74:
> >
> >   Update version for v2.10.0-rc2 release (2017-08-08 19:07:46 +0100)
> >
> > are available in the git repository at:
> >
> >   git://github.com/dgibson/qemu.git tags/ppc-for-2.10-20170809
> >
> > for you to fetch changes up to f57467e3b326c7736f8e481fd6b680f30e575c87:
> >
> >   spapr: Fix bug in h_signal_sys_reset() (2017-08-09 14:04:28 +1000)
> >
> > ----------------------------------------------------------------
> > ppc patch queue 2017-08-09
> >
> > This series contains a number of bugfixes for ppc and related
> > machines, for the qemu-2.10.release.  Some are true regressions,
> > others are serious enough and non-invasive enough to fix that it's
> > worth putting in 2.10 this late.
> >
> > ----------------------------------------------------------------
> 
> Applied, thanks.
> 
> > I haven't completed a Travis build for this, which is part of my usual
> > test regime, since the first dozen or so Travis builds are failing
> > more often than not on master as well.  I don't know why this is -
> > seems to be failing some of the x86 tests.
> 
> Doesn't look much worse than usual to me -- of the last 24 travis
> builds for master 4 failed and 20 passed.

Uh.. that's not been my experience.  I was a bit unclear in my
description, though.  Until maybe a week and a half ago I found the
Travis build was fairly reliable, though there were occasional
transien failures.  Now, essentially every Travis build is failing for
me.  Specifically most of the first dozen or so of the batch of build
configurations on Travis fail (that's "X" not "!").  These seem to be
transient failures in the sense that if I rebuild enough times they'll
eventually pass, but unlike earlier when the builds would suceed most
of the time, they now seem to succeed at best around 1/3 of the time
(that's ~1/3 of the time for each configuration sub-build, so with a
dozen or so apparently affected that means a complete passing build
essentially never).

See for example https://travis-ci.org/dgibson/qemu/builds/263312174
where 5 subbuilds have failed (which is relatively few).  In each case
the failing error seems to be something like:

ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/i386/vhost-user/connect-fail/subprocess [55883]) failed unexpectedly

Seems to be i386 in some cases and x86_64 in others.

-- 
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/6] ppc patch queue 2017-08-09

[Peter Maydell]

On 11 August 2017 at 09:51, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Aug 10, 2017 at 01:47:03PM +0100, Peter Maydell wrote:
>> On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote:
>> > I haven't completed a Travis build for this, which is part of my usual
>> > test regime, since the first dozen or so Travis builds are failing
>> > more often than not on master as well.  I don't know why this is -
>> > seems to be failing some of the x86 tests.
>>
>> Doesn't look much worse than usual to me -- of the last 24 travis
>> builds for master 4 failed and 20 passed.
>
> Uh.. that's not been my experience.  I was a bit unclear in my
> description, though.  Until maybe a week and a half ago I found the
> Travis build was fairly reliable, though there were occasional
> transien failures.  Now, essentially every Travis build is failing for
> me.  Specifically most of the first dozen or so of the batch of build
> configurations on Travis fail (that's "X" not "!").  These seem to be
> transient failures in the sense that if I rebuild enough times they'll
> eventually pass, but unlike earlier when the builds would suceed most
> of the time, they now seem to succeed at best around 1/3 of the time
> (that's ~1/3 of the time for each configuration sub-build, so with a
> dozen or so apparently affected that means a complete passing build
> essentially never).
>
> See for example https://travis-ci.org/dgibson/qemu/builds/263312174
> where 5 subbuilds have failed (which is relatively few).  In each case
> the failing error seems to be something like:
>
> ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/i386/vhost-user/connect-fail/subprocess [55883]) failed unexpectedly
>
> Seems to be i386 in some cases and x86_64 in others.

Weird. https://travis-ci.org/qemu/qemu/builds is the master
build history and as you can see it's mostly greens.
Not sure why your setup would be significantly worse:
maybe one of the travis submaintainers has an idea.
It could just be our vhost-user-test is flaky but I don't
know why that should hit you much more than master...


thanks
-- PMM

Re: [Qemu-devel] [PULL 0/6] ppc patch queue 2017-08-09

[Philippe Mathieu-Daudé]

Hi David, Peter,

On 08/11/2017 05:59 AM, Peter Maydell wrote:
> On 11 August 2017 at 09:51, David Gibson <david@gibson.dropbear.id.au> wrote:
>> On Thu, Aug 10, 2017 at 01:47:03PM +0100, Peter Maydell wrote:
>>> On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote:
>>>> I haven't completed a Travis build for this, which is part of my usual
>>>> test regime, since the first dozen or so Travis builds are failing
>>>> more often than not on master as well.  I don't know why this is -
>>>> seems to be failing some of the x86 tests.
>>>
>>> Doesn't look much worse than usual to me -- of the last 24 travis
>>> builds for master 4 failed and 20 passed.
>>
>> Uh.. that's not been my experience.  I was a bit unclear in my
>> description, though.  Until maybe a week and a half ago I found the
>> Travis build was fairly reliable, though there were occasional
>> transien failures.  Now, essentially every Travis build is failing for
>> me.  Specifically most of the first dozen or so of the batch of build
>> configurations on Travis fail (that's "X" not "!").  These seem to be
>> transient failures in the sense that if I rebuild enough times they'll
>> eventually pass, but unlike earlier when the builds would suceed most
>> of the time, they now seem to succeed at best around 1/3 of the time
>> (that's ~1/3 of the time for each configuration sub-build, so with a
>> dozen or so apparently affected that means a complete passing build
>> essentially never).
>>
>> See for example https://travis-ci.org/dgibson/qemu/builds/263312174
>> where 5 subbuilds have failed (which is relatively few).  In each case
>> the failing error seems to be something like:
>>
>> ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/i386/vhost-user/connect-fail/subprocess [55883]) failed unexpectedly
>>
>> Seems to be i386 in some cases and x86_64 in others.

Yes, I'm experiencing the same (but a bit more frequent with i386 than 
x86_64).

> Weird. https://travis-ci.org/qemu/qemu/builds is the master
> build history and as you can see it's mostly greens.
> Not sure why your setup would be significantly worse:
> maybe one of the travis submaintainers has an idea.
> It could just be our vhost-user-test is flaky but I don't
> know why that should hit you much more than master...

No clue, I started to think repositories with less frequent builds are 
deployed on faster hardware.

Will keep the list informed if there are some improvements.

Regards,

Phil.

Re: [Qemu-devel] [PULL 0/6] ppc patch queue 2017-08-09

[David Gibson]

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

On Fri, Aug 11, 2017 at 09:59:00AM +0100, Peter Maydell wrote:
> On 11 August 2017 at 09:51, David Gibson <david@gibson.dropbear.id.au> wrote:
> > On Thu, Aug 10, 2017 at 01:47:03PM +0100, Peter Maydell wrote:
> >> On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote:
> >> > I haven't completed a Travis build for this, which is part of my usual
> >> > test regime, since the first dozen or so Travis builds are failing
> >> > more often than not on master as well.  I don't know why this is -
> >> > seems to be failing some of the x86 tests.
> >>
> >> Doesn't look much worse than usual to me -- of the last 24 travis
> >> builds for master 4 failed and 20 passed.
> >
> > Uh.. that's not been my experience.  I was a bit unclear in my
> > description, though.  Until maybe a week and a half ago I found the
> > Travis build was fairly reliable, though there were occasional
> > transien failures.  Now, essentially every Travis build is failing for
> > me.  Specifically most of the first dozen or so of the batch of build
> > configurations on Travis fail (that's "X" not "!").  These seem to be
> > transient failures in the sense that if I rebuild enough times they'll
> > eventually pass, but unlike earlier when the builds would suceed most
> > of the time, they now seem to succeed at best around 1/3 of the time
> > (that's ~1/3 of the time for each configuration sub-build, so with a
> > dozen or so apparently affected that means a complete passing build
> > essentially never).
> >
> > See for example https://travis-ci.org/dgibson/qemu/builds/263312174
> > where 5 subbuilds have failed (which is relatively few).  In each case
> > the failing error seems to be something like:
> >
> > ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/i386/vhost-user/connect-fail/subprocess [55883]) failed unexpectedly
> >
> > Seems to be i386 in some cases and x86_64 in others.
> 
> Weird. https://travis-ci.org/qemu/qemu/builds is the master
> build history and as you can see it's mostly greens.
> Not sure why your setup would be significantly worse:
> maybe one of the travis submaintainers has an idea.
> It could just be our vhost-user-test is flaky but I don't
> know why that should hit you much more than master...

So, Travis is telling me my builds are being done on a trusty
environment (even the sub-builds which don't specify a distro
explicitly).  That doesn't seem to be the case for the master tree
builds.  Then again, the sub-builds which do specifically ask for
trusty seem to be working, so I'm not sure why implicity choosing
trusty would break things.

-- 
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/6] ppc patch queue 2017-08-09

[Michael S. Tsirkin]

On Fri, Aug 11, 2017 at 09:59:00AM +0100, Peter Maydell wrote:
> On 11 August 2017 at 09:51, David Gibson <david@gibson.dropbear.id.au> wrote:
> > On Thu, Aug 10, 2017 at 01:47:03PM +0100, Peter Maydell wrote:
> >> On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote:
> >> > I haven't completed a Travis build for this, which is part of my usual
> >> > test regime, since the first dozen or so Travis builds are failing
> >> > more often than not on master as well.  I don't know why this is -
> >> > seems to be failing some of the x86 tests.
> >>
> >> Doesn't look much worse than usual to me -- of the last 24 travis
> >> builds for master 4 failed and 20 passed.
> >
> > Uh.. that's not been my experience.  I was a bit unclear in my
> > description, though.  Until maybe a week and a half ago I found the
> > Travis build was fairly reliable, though there were occasional
> > transien failures.  Now, essentially every Travis build is failing for
> > me.  Specifically most of the first dozen or so of the batch of build
> > configurations on Travis fail (that's "X" not "!").  These seem to be
> > transient failures in the sense that if I rebuild enough times they'll
> > eventually pass, but unlike earlier when the builds would suceed most
> > of the time, they now seem to succeed at best around 1/3 of the time
> > (that's ~1/3 of the time for each configuration sub-build, so with a
> > dozen or so apparently affected that means a complete passing build
> > essentially never).
> >
> > See for example https://travis-ci.org/dgibson/qemu/builds/263312174
> > where 5 subbuilds have failed (which is relatively few).  In each case
> > the failing error seems to be something like:
> >
> > ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/i386/vhost-user/connect-fail/subprocess [55883]) failed unexpectedly
> >
> > Seems to be i386 in some cases and x86_64 in others.

And is it always the connect-fail test?

> Weird. https://travis-ci.org/qemu/qemu/builds is the master
> build history and as you can see it's mostly greens.
> Not sure why your setup would be significantly worse:
> maybe one of the travis submaintainers has an idea.
> It could just be our vhost-user-test is flaky but I don't
> know why that should hit you much more than master...
> 
> 
> thanks
> -- PMM

Re: [Qemu-devel] [PULL 0/6] ppc patch queue 2017-08-09

[David Gibson]

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

On Mon, Aug 14, 2017 at 05:20:21PM +0300, Michael S. Tsirkin wrote:
> On Fri, Aug 11, 2017 at 09:59:00AM +0100, Peter Maydell wrote:
> > On 11 August 2017 at 09:51, David Gibson <david@gibson.dropbear.id.au> wrote:
> > > On Thu, Aug 10, 2017 at 01:47:03PM +0100, Peter Maydell wrote:
> > >> On 9 August 2017 at 08:03, David Gibson <david@gibson.dropbear.id.au> wrote:
> > >> > I haven't completed a Travis build for this, which is part of my usual
> > >> > test regime, since the first dozen or so Travis builds are failing
> > >> > more often than not on master as well.  I don't know why this is -
> > >> > seems to be failing some of the x86 tests.
> > >>
> > >> Doesn't look much worse than usual to me -- of the last 24 travis
> > >> builds for master 4 failed and 20 passed.
> > >
> > > Uh.. that's not been my experience.  I was a bit unclear in my
> > > description, though.  Until maybe a week and a half ago I found the
> > > Travis build was fairly reliable, though there were occasional
> > > transien failures.  Now, essentially every Travis build is failing for
> > > me.  Specifically most of the first dozen or so of the batch of build
> > > configurations on Travis fail (that's "X" not "!").  These seem to be
> > > transient failures in the sense that if I rebuild enough times they'll
> > > eventually pass, but unlike earlier when the builds would suceed most
> > > of the time, they now seem to succeed at best around 1/3 of the time
> > > (that's ~1/3 of the time for each configuration sub-build, so with a
> > > dozen or so apparently affected that means a complete passing build
> > > essentially never).
> > >
> > > See for example https://travis-ci.org/dgibson/qemu/builds/263312174
> > > where 5 subbuilds have failed (which is relatively few).  In each case
> > > the failing error seems to be something like:
> > >
> > > ERROR:tests/vhost-user-test.c:807:test_connect_fail: child process (/i386/vhost-user/connect-fail/subprocess [55883]) failed unexpectedly
> > >
> > > Seems to be i386 in some cases and x86_64 in others.
> 
> And is it always the connect-fail test?

I think so, though I haven't checked every single failing output to
make sure.

> 
> > Weird. https://travis-ci.org/qemu/qemu/builds is the master
> > build history and as you can see it's mostly greens.
> > Not sure why your setup would be significantly worse:
> > maybe one of the travis submaintainers has an idea.
> > It could just be our vhost-user-test is flaky but I don't
> > know why that should hit you much more than master...
> > 
> > 
> > thanks
> > -- PMM
> 

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