[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: |
Alexey Kardashevskiy |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [for-2.11 PATCH 00/26] spapr: add support for PHB hotplug |
Date: |
Fri, 28 Jul 2017 13:27:05 +1000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
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.
--
Alexey
signature.asc
Description: OpenPGP digital signature