qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [for-2.11 PATCH 00/26] spapr: add support fo


From: David Gibson
Subject: Re: [Qemu-ppc] [Qemu-devel] [for-2.11 PATCH 00/26] spapr: add support for PHB hotplug
Date: Fri, 28 Jul 2017 13:40:42 +1000
User-agent: Mutt/1.8.3 (2017-05-23)

On Fri, Jul 28, 2017 at 01:27:05PM +1000, Alexey Kardashevskiy wrote:
> On 28/07/17 02:39, Greg Kurz wrote:
> > On Wed, 26 Jul 2017 17:31:17 -0300
> > Daniel Henrique Barboza <address@hidden> wrote:
> > 
> >> I've tested the patch set using Greg's Github branch. It worked fine in 
> >> my tests
> >> using a Fedora 26 and an Ubuntu 17.04 guests. I have two observations
> >> though:
> >>
> >> 1 - This is not related to this patch set per se because it is 
> >> reproducible on master, but
> >> I think it is interfering with this new feature.  There is a 
> >> warning/error message in
> >> the kernel right after SLOF that goes:
> >>
> >> (...)
> >>   -> smp_release_cpus()  
> >> spinning_secondaries = 0
> >>   <- smp_release_cpus()
> >> Linux ppc64le
> >> #1 SMP Mon Jul 1[    0.030450] pci 0000:00:02.0: of_irq_parse_pci: 
> >> failed with rc=-22
> >> [    0.030552] pci 0000:00:0f.0: of_irq_parse_pci: failed with rc=-22
> >> [  OK  ] Started Security Auditing Service.
> >> (...)
> >>
> > 
> > This is a regression in QEMU master introduced by this commit:
> > 
> > commit b87680427e8a3ff682f66514e99a8344e7437247
> > Author: Cédric Le Goater <address@hidden>
> > Date:   Wed Jul 5 19:13:15 2017 +0200
> > 
> >     spapr: populate device tree depending on XIVE_EXPLOIT option
> >     
> >     When XIVE is supported, the device tree should be populated
> >     accordingly and the XIVE memory regions mapped to activate MMIOs.
> >     
> >     Depending on the design we choose, we could also allocate different
> >     ICS and ICP objects, or switch between objects. This needs to be
> >     discussed.
> >     
> >     Signed-off-by: Cédric Le Goater <address@hidden>
> >     Signed-off-by: David Gibson <address@hidden>
> > 
> > It is very similar to the issue that motivated the new 
> > KVMPPC_H_UPDATE_PHANDLE
> > hcall (see patch 24 and 26 in this series):
> > 
> > - QEMU creates an "interrupt-controller" node with a phandle property
> >   with the value 0x1111
> > - QEMU passes the FDT to SLOF
> > - SLOF converts all references to the phandle to an SLOF internal value
> > 
> > => from now on (ie, until the next machine reset), the guest only knows
> >    the OF phandle.
> > 
> > - during CAS, if we go XICS, we send back an updated FDT with the
> >   phandle of the "interrupt-controller" node reverted to 0x1111
> > 
> > => the guest complains because all cold-plugged devices nodes refer
> >    to the OF phandle, not 0x1111
> > 
> > A solution is to use the value set by KVMPPC_H_UPDATE_PHANDLE during CAS
> > instead of 0x1111. I could verify it makes the guest warning disappear.
> > 
> > I'll send a dedicated patchset to fix this in 2.10.
> 
> 
> The SLOF I pushed for 2.10 does not have it though. And the rest of XIVE is
> not targeted for 2.10 anyway. So imho the solution is reverting "spapr:
> populate device tree depending on XIVE_EXPLOIT option" for 2.10.

I agree, I've applied the revert to ppc-for-2.10 now.

-- 
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: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]