Re: [PULL 00/30] ppc-for-5.2 queue 20200904

[David Gibson]

On Sun, Sep 06, 2020 at 04:20:10PM +0100, Peter Maydell wrote:
> On Fri, 4 Sep 2020 at 04:47, David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > The following changes since commit 67a7bfe560a1bba59efab085cb3430f45176d382:
> >
> >   Merge remote-tracking branch 
> > 'remotes/huth-gitlab/tags/pull-request-2020-09-03' into staging (2020-09-03 
> > 16:58:25 +0100)
> >
> > are available in the Git repository at:
> >
> >   git://github.com/dgibson/qemu.git tags/ppc-for-5.2-20200904
> >
> > for you to fetch changes up to b172606ecf29a140073f7787251a9d70ecb53b6e:
> >
> >   spapr_numa: move NVLink2 associativity handling to spapr_numa.c 
> > (2020-09-04 13:40:09 +1000)
> >
> > ----------------------------------------------------------------
> > ppc patch queue 2020-09-04
> >
> > Next pull request for qemu-5.2.  The biggest thing here is the
> > generalization of ARM's start-powered-off machine property to all
> > targets.  This can fix a number of odd little edge cases where KVM
> > could run vcpus before they were properly initialized.  This does
> > include changes to a number of files that aren't normally in my
> > purview.  There are suitable Acked-by lines and Peter requested this
> > come in via my tree, since the most pressing requirement for it is in
> > pseries machines with the POWER secure virtual machine facility.
> >
> > In addition we have:
> >  * The start of Daniel Barboza's rework and clean up of pseries
> >    machine NUMA handling
> >  * Correction to behaviour of the nvdimm= generic machine property on
> >    pseries
> >  * An optimization to the allocation of XIVE interrupts on KVM
> >  * Some fixes for confused behaviour with kernel_irqchip when both
> >    XICS and XIVE are in play
> >  * Add HIOMAP comamnd to pnv flash
> >  * Properly advertise the fact that spapr_vscsi doesn't handle
> >    hotplugged disks
> >  * Some assorted minor enhancements
> 
> Hi -- this fails to build for Windows:
> 
> ../../hw/ppc/spapr_numa.c: In function 'spapr_numa_fixup_cpu_dt':
> ../../hw/ppc/spapr_numa.c:77:5: error: unknown type name 'uint'
>      uint vcpu_assoc_size = NUMA_ASSOC_SIZE + 1;
>      ^

Huh, that's weird.  My testing run was less thorough than I'd usually
do, because so many tests were broken on the master branch, but I was
pretty sure I did do successful mingw builds.

> That should probably be using one of the standard C types.

Done.

> The 'check-tcg' tests for the linux-user static build also
> failed on an s390x test:
> 
>   CHECK   debian-s390x-cross
>   BUILD   s390x-linux-user guest-tests with docker qemu/debian-s390x-cross
>   RUN     tests for s390x
>   TEST    threadcount on s390x
> Unhandled trap: 0x10003
> PSW=mask 0000000180000000 addr 00000000010004f0 cc 00
> R00=0000000000000000 R01=0000000000000000 R02=0000000000000000
> R03=0000000000000000
> R04=0000000000000000 R05=0000000000000000 R06=0000000000000000
> R07=0000000000000000
> R08=0000000000000000 R09=0000000000000000 R10=0000000000000000
> R11=0000000000000000
> R12=0000000000000000 R13=0000000000000000 R14=0000000000000000
> R15=00000040008006c0
> 
> ../Makefile.target:153: recipe for target 'run-threadcount' failed
> make[2]: *** [run-threadcount] Error 1

Bother.  I did see that failure on Travis, but assumed it was a false
positive because there were so many failures on master there.

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

signature.asc
Description: PGP signature