* [PATCH] powerpc: exported functions __clear_user and copy_page use r2 so need _GLOBAL_TOC()
From: Anton Blanchard @ 2014-06-04 22:04 UTC (permalink / raw)
To: benh, paulus, mjw; +Cc: linuxppc-dev
__clear_user and copy_page load from the TOC and are also exported
to modules. This means we have to use _GLOBAL_TOC() so that we
create the global entry point that sets up the TOC.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: b/arch/powerpc/lib/copypage_64.S
===================================================================
--- a/arch/powerpc/lib/copypage_64.S
+++ b/arch/powerpc/lib/copypage_64.S
@@ -16,7 +16,7 @@ PPC64_CACHES:
.tc ppc64_caches[TC],ppc64_caches
.section ".text"
-_GLOBAL(copy_page)
+_GLOBAL_TOC(copy_page)
BEGIN_FTR_SECTION
lis r5,PAGE_SIZE@h
FTR_SECTION_ELSE
Index: b/arch/powerpc/lib/string_64.S
===================================================================
--- a/arch/powerpc/lib/string_64.S
+++ b/arch/powerpc/lib/string_64.S
@@ -77,7 +77,7 @@ err3; stb r0,0(r3)
mr r3,r4
blr
-_GLOBAL(__clear_user)
+_GLOBAL_TOC(__clear_user)
cmpdi r4,32
neg r6,r3
li r0,0
^ permalink raw reply
* Re: [PATCH V2] KVM: PPC: BOOK3S: PR: Fix PURR and SPURR emulation
From: Alexander Graf @ 2014-06-04 21:58 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1401880675-31090-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 04.06.14 13:17, Aneesh Kumar K.V wrote:
> We use time base for PURR and SPURR emulation with PR KVM since we
> are emulating a single threaded core. When using time base
> we need to make sure that we don't accumulate time spent in the host
> in PURR and SPURR value.
>
> Also we don't need to emulate mtspr because both the registers are
> hypervisor resource.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Thanks, applied to kvm-ppc-queue.
Alex
^ permalink raw reply
* [PATCH] cpufreq: ppc-corenet-cpu-freq: do_div use quotient
From: Ed Swarthout @ 2014-06-04 20:32 UTC (permalink / raw)
To: tim.gardner, scottwood, linuxppc-dev, linux-kernel
In-Reply-To: <1398701898-68201-1-git-send-email-tim.gardner@canonical.com>
6712d2931933ada259b82f06c03a855b19937074 (cpufreq:
ppc-corenet-cpufreq: Fix __udivdi3 modpost error) used the remainder
from do_div instead of the quotient. Fix that and add one to ensure
minimum is met.
Signed-off-by: Ed Swarthout <Ed.Swarthout@freescale.com>
---
drivers/cpufreq/ppc-corenet-cpufreq.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c b/drivers/cpufreq/ppc-corenet-cpufreq.c
index 0af618a..3607070 100644
--- a/drivers/cpufreq/ppc-corenet-cpufreq.c
+++ b/drivers/cpufreq/ppc-corenet-cpufreq.c
@@ -138,7 +138,7 @@ static int corenet_cpufreq_cpu_init(struct cpufreq_policy *policy)
struct cpufreq_frequency_table *table;
struct cpu_data *data;
unsigned int cpu = policy->cpu;
- u64 transition_latency_hz;
+ u64 u64temp;
np = of_get_cpu_node(cpu, NULL);
if (!np)
@@ -206,9 +206,10 @@ static int corenet_cpufreq_cpu_init(struct cpufreq_policy *policy)
for_each_cpu(i, per_cpu(cpu_mask, cpu))
per_cpu(cpu_data, i) = data;
- transition_latency_hz = 12ULL * NSEC_PER_SEC;
- policy->cpuinfo.transition_latency =
- do_div(transition_latency_hz, fsl_get_sys_freq());
+ /* Minimum transition latency is 12 platform clocks */
+ u64temp = 12ULL * NSEC_PER_SEC;
+ do_div(u64temp, fsl_get_sys_freq());
+ policy->cpuinfo.transition_latency = u64temp + 1;
of_node_put(np);
--
1.9.1
^ permalink raw reply related
* Re: [RESEND PATCH] memory: Freescale CoreNet Coherency Fabric error reporting driver
From: Scott Wood @ 2014-06-04 17:07 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Greg Kroah-Hartman, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <35f1762b80694ba4835cd7902a2faa0a@BLUPR03MB566.namprd03.prod.outlook.com>
On Wed, 2014-06-04 at 12:04 -0500, Bhushan Bharat-R65777 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, June 04, 2014 10:12 PM
> > To: Bhushan Bharat-R65777
> > Cc: Greg Kroah-Hartman; linuxppc-dev@lists.ozlabs.org; linux-
> > kernel@vger.kernel.org
> > Subject: Re: [RESEND PATCH] memory: Freescale CoreNet Coherency Fabric error
> > reporting driver
> >
> > On Wed, 2014-06-04 at 03:17 -0500, Bhushan Bharat-R65777 wrote:
> > > > +static int ccf_remove(struct platform_device *pdev) {
> > > > + struct ccf_private *ccf = dev_get_drvdata(&pdev->dev);
> > > > +
> > > > + switch (ccf->info->version) {
> > > > + case CCF1:
> > > > + iowrite32be(0, &ccf->err_regs->errdis);
> > > > + break;
> > > > +
> > > > + case CCF2:
> > > > + iowrite32be(0, &ccf->err_regs->errinten);
> > >
> > > Do you think it is same to disable detection bits in ccf->err_regs->errdis?
> >
> > Disabling the interrupt is what we're aiming for here, but ccf1 doesn't provide
> > a way to do that separate from disabling detection.
>
> What I wanted to say that do we also need to disable detection (set
> ERRDET_LAE | ERRDET_CV bits in errdis) apart from clearing errinten on
> ccf2 ?
I don't think we "need" to. You could argue that we should for
consistency, though I think there's value in errors continuing to be
detected even without the driver (e.g. can dump the registers in a
debugger).
-Scott
^ permalink raw reply
* RE: [RESEND PATCH] memory: Freescale CoreNet Coherency Fabric error reporting driver
From: Bharat.Bhushan @ 2014-06-04 17:04 UTC (permalink / raw)
To: Scott Wood
Cc: Greg Kroah-Hartman, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1401900111.6603.325.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDA0LCAyMDE0IDEwOjEyIFBNDQo+IFRvOiBCaHVz
aGFuIEJoYXJhdC1SNjU3NzcNCj4gQ2M6IEdyZWcgS3JvYWgtSGFydG1hbjsgbGludXhwcGMtZGV2
QGxpc3RzLm96bGFicy5vcmc7IGxpbnV4LQ0KPiBrZXJuZWxAdmdlci5rZXJuZWwub3JnDQo+IFN1
YmplY3Q6IFJlOiBbUkVTRU5EIFBBVENIXSBtZW1vcnk6IEZyZWVzY2FsZSBDb3JlTmV0IENvaGVy
ZW5jeSBGYWJyaWMgZXJyb3INCj4gcmVwb3J0aW5nIGRyaXZlcg0KPiANCj4gT24gV2VkLCAyMDE0
LTA2LTA0IGF0IDAzOjE3IC0wNTAwLCBCaHVzaGFuIEJoYXJhdC1SNjU3Nzcgd3JvdGU6DQo+ID4g
PiArc3RydWN0IGNjZl9lcnJfcmVncyB7DQo+ID4gPiArCXUzMiBlcnJkZXQ7CQkvKiAweDAwIEVy
cm9yIERldGVjdCBSZWdpc3RlciAqLw0KPiA+ID4gKwkvKiAweDA0IEVycm9yIEVuYWJsZSAoY2Nm
MSkvRGlzYWJsZSAoY2NmMikgUmVnaXN0ZXIgKi8NCj4gPiA+ICsJdTMyIGVycmRpczsNCj4gPiA+
ICsJLyogMHgwOCBFcnJvciBJbnRlcnJ1cHQgRW5hYmxlIFJlZ2lzdGVyIChjY2YyIG9ubHkpICov
DQo+ID4gPiArCXUzMiBlcnJpbnRlbjsNCj4gPiA+ICsJdTMyIGNlY2FyOwkJLyogMHgwYyBFcnJv
ciBDYXB0dXJlIEF0dHJpYnV0ZSBSZWdpc3RlciAqLw0KPiA+ID4gKwl1MzIgY2VjYWRyaDsJCS8q
IDB4MTAgRXJyb3IgQ2FwdHVyZSBBZGRyZXNzIEhpZ2ggKi8NCj4gPg0KPiA+IHMvY2VjYWRyaC9j
ZWNhZGRyaC9nDQo+ID4gVGhpcyB3YXkgd2Ugd2lsbCBiZSBjb25zaXN0ZW50IHdpdGggUmVmZXJl
bmNlIG1hbnVhbC4NCj4gDQo+IEl0J3MgImNlY2FkcmgiIGluIGNjZjEgYW5kICJjZWNhZGRyaCIg
aW4gY2NmMi4gIEkgc3VwcG9zZSBJIHNob3VsZCB1c2UgdGhlDQo+IGxhdHRlciBzaW5jZSAiZXJy
ZGV0L2VycmRpcy9lcnJpbnRlbiIgYXJlIHRoZSBjY2YyIG5hbWVzLg0KPiANCj4gPiA+ICsJdTMy
IGNlY2Fkcmw7CQkvKiAweDE0IEVycm9yIENhcHR1cmUgQWRkcmVzcyBMb3cgKi8NCj4gPg0KPiA+
IHMvY2VjYWRybC9jZWNhZGRybC9nDQo+ID4NCj4gPiA+ICsJdTMyIGNlY2FyMjsJCS8qIDB4MTgg
RXJyb3IgQ2FwdHVyZSBBdHRyaWJ1dGUgUmVnaXN0ZXIgMiAqLw0KPiA+ID4gK307DQo+ID4gPiAr
DQo+ID4gPiArLyogTEFFL0NWIGFsc28gdmFsaWQgZm9yIGVycmRpcyBhbmQgZXJyaW50ZW4gKi8N
Cj4gPiA+ICsjZGVmaW5lIEVSUkRFVF9MQUUJCSgxIDw8IDApICAvKiBMb2NhbCBBY2Nlc3MgRXJy
b3IgKi8NCj4gPiA+ICsjZGVmaW5lIEVSUkRFVF9DVgkJKDEgPDwgMSkgIC8qIENvaGVyZW5jeSBW
aW9sYXRpb24gKi8NCj4gPiA+ICsjZGVmaW5lIEVSUkRFVF9DVFlQRV9TSElGVAkyNgkgIC8qIENh
cHR1cmUgVHlwZSAoY2NmMiBvbmx5KSAqLw0KPiA+ID4gKyNkZWZpbmUgRVJSREVUX0NUWVBFX01B
U0sJKDB4M2YgPDwgRVJSREVUX0NUWVBFX1NISUZUKQ0KPiA+DQo+ID4gU2hvdWxkIG5vdCB0aGlz
IGJlICgweDFmIDw8IEVSUkRFVF9DVFlQRV9TSElGVCkNCj4gDQo+IFllcywgdGhhbmtzIGZvciBj
YXRjaGluZyB0aGF0Lg0KPiANCj4gPiA+ICsjZGVmaW5lIEVSUkRFVF9DQVAJCSgxIDw8IDMxKSAv
KiBDYXB0dXJlIFZhbGlkIChjY2YyIG9ubHkpICovDQo+ID4gPiArDQo+ID4gPiArI2RlZmluZSBD
RUNBUl9WQUwJCSgxIDw8IDApICAvKiBWYWxpZCAoY2NmMSBvbmx5KSAqLw0KPiA+ID4gKyNkZWZp
bmUgQ0VDQVJfVVZUCQkoMSA8PCAxNSkgLyogVW5hdmFpbGFibGUgdGFyZ2V0IElEIChjY2YxKSAq
Lw0KPiA+ID4gKyNkZWZpbmUgQ0VDQVJfU1JDSURfU0hJRlRfQ0NGMQkyNA0KPiA+ID4gKyNkZWZp
bmUgQ0VDQVJfU1JDSURfTUFTS19DQ0YxCSgweGZmIDw8IENFQ0FSX1NSQ0lEX1NISUZUX0NDRjEp
DQo+ID4gPiArI2RlZmluZSBDRUNBUl9TUkNJRF9TSElGVF9DQ0YyCTE4DQo+ID4gPiArI2RlZmlu
ZSBDRUNBUl9TUkNJRF9NQVNLX0NDRjIJKDB4ZmYgPDwgQ0VDQVJfU1JDSURfU0hJRlRfQ0NGMikN
Cj4gPiA+ICsNCj4gPiA+ICsjZGVmaW5lIENFQ0FEUkhfQUREUkgJCTB4Zg0KPiA+DQo+ID4gT24g
Y2NmMiB0aGlzIGlkIDB4ZmYuDQo+IA0KPiBPSy4gIEkgdGhpbmsgd2UgY2FuIGdldCBhd2F5IHdp
dGggdXNpbmcgMHhmZiBvbiBib3RoLg0KPiANCj4gPiA+ICtzdGF0aWMgaW50IGNjZl9yZW1vdmUo
c3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikgew0KPiA+ID4gKwlzdHJ1Y3QgY2NmX3ByaXZh
dGUgKmNjZiA9IGRldl9nZXRfZHJ2ZGF0YSgmcGRldi0+ZGV2KTsNCj4gPiA+ICsNCj4gPiA+ICsJ
c3dpdGNoIChjY2YtPmluZm8tPnZlcnNpb24pIHsNCj4gPiA+ICsJY2FzZSBDQ0YxOg0KPiA+ID4g
KwkJaW93cml0ZTMyYmUoMCwgJmNjZi0+ZXJyX3JlZ3MtPmVycmRpcyk7DQo+ID4gPiArCQlicmVh
azsNCj4gPiA+ICsNCj4gPiA+ICsJY2FzZSBDQ0YyOg0KPiA+ID4gKwkJaW93cml0ZTMyYmUoMCwg
JmNjZi0+ZXJyX3JlZ3MtPmVycmludGVuKTsNCj4gPg0KPiA+IERvIHlvdSB0aGluayBpdCBpcyBz
YW1lIHRvIGRpc2FibGUgZGV0ZWN0aW9uIGJpdHMgaW4gY2NmLT5lcnJfcmVncy0+ZXJyZGlzPw0K
PiANCj4gRGlzYWJsaW5nIHRoZSBpbnRlcnJ1cHQgaXMgd2hhdCB3ZSdyZSBhaW1pbmcgZm9yIGhl
cmUsIGJ1dCBjY2YxIGRvZXNuJ3QgcHJvdmlkZQ0KPiBhIHdheSB0byBkbyB0aGF0IHNlcGFyYXRl
IGZyb20gZGlzYWJsaW5nIGRldGVjdGlvbi4NCg0KV2hhdCBJIHdhbnRlZCB0byBzYXkgdGhhdCBk
byB3ZSBhbHNvIG5lZWQgdG8gZGlzYWJsZSBkZXRlY3Rpb24gKHNldCBFUlJERVRfTEFFIHwgRVJS
REVUX0NWIGJpdHMgaW4gZXJyZGlzKSBhcGFydCBmcm9tIGNsZWFyaW5nIGVycmludGVuIG9uIGNj
ZjIgPw0KDQpUaGFua3MNCi1CaGFyYXQNCg0KPiANCj4gLVNjb3R0DQo+IA0KDQo=
^ permalink raw reply
* Re: [RESEND PATCH] memory: Freescale CoreNet Coherency Fabric error reporting driver
From: Scott Wood @ 2014-06-04 16:41 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Greg Kroah-Hartman, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <967d9a5e0f7e4d0a8f5e7ec6b8e88ff2@BLUPR03MB566.namprd03.prod.outlook.com>
On Wed, 2014-06-04 at 03:17 -0500, Bhushan Bharat-R65777 wrote:
> > +struct ccf_err_regs {
> > + u32 errdet; /* 0x00 Error Detect Register */
> > + /* 0x04 Error Enable (ccf1)/Disable (ccf2) Register */
> > + u32 errdis;
> > + /* 0x08 Error Interrupt Enable Register (ccf2 only) */
> > + u32 errinten;
> > + u32 cecar; /* 0x0c Error Capture Attribute Register */
> > + u32 cecadrh; /* 0x10 Error Capture Address High */
>
> s/cecadrh/cecaddrh/g
> This way we will be consistent with Reference manual.
It's "cecadrh" in ccf1 and "cecaddrh" in ccf2. I suppose I should use
the latter since "errdet/errdis/errinten" are the ccf2 names.
> > + u32 cecadrl; /* 0x14 Error Capture Address Low */
>
> s/cecadrl/cecaddrl/g
>
> > + u32 cecar2; /* 0x18 Error Capture Attribute Register 2 */
> > +};
> > +
> > +/* LAE/CV also valid for errdis and errinten */
> > +#define ERRDET_LAE (1 << 0) /* Local Access Error */
> > +#define ERRDET_CV (1 << 1) /* Coherency Violation */
> > +#define ERRDET_CTYPE_SHIFT 26 /* Capture Type (ccf2 only) */
> > +#define ERRDET_CTYPE_MASK (0x3f << ERRDET_CTYPE_SHIFT)
>
> Should not this be (0x1f << ERRDET_CTYPE_SHIFT)
Yes, thanks for catching that.
> > +#define ERRDET_CAP (1 << 31) /* Capture Valid (ccf2 only) */
> > +
> > +#define CECAR_VAL (1 << 0) /* Valid (ccf1 only) */
> > +#define CECAR_UVT (1 << 15) /* Unavailable target ID (ccf1) */
> > +#define CECAR_SRCID_SHIFT_CCF1 24
> > +#define CECAR_SRCID_MASK_CCF1 (0xff << CECAR_SRCID_SHIFT_CCF1)
> > +#define CECAR_SRCID_SHIFT_CCF2 18
> > +#define CECAR_SRCID_MASK_CCF2 (0xff << CECAR_SRCID_SHIFT_CCF2)
> > +
> > +#define CECADRH_ADDRH 0xf
>
> On ccf2 this id 0xff.
OK. I think we can get away with using 0xff on both.
> > +static int ccf_remove(struct platform_device *pdev) {
> > + struct ccf_private *ccf = dev_get_drvdata(&pdev->dev);
> > +
> > + switch (ccf->info->version) {
> > + case CCF1:
> > + iowrite32be(0, &ccf->err_regs->errdis);
> > + break;
> > +
> > + case CCF2:
> > + iowrite32be(0, &ccf->err_regs->errinten);
>
> Do you think it is same to disable detection bits in ccf->err_regs->errdis?
Disabling the interrupt is what we're aiming for here, but ccf1 doesn't
provide a way to do that separate from disabling detection.
-Scott
^ permalink raw reply
* [PATCH] powerpc/mpc85xx: fix fsl/p2041-post.dtsi clockgen mux2
From: Valentin Longchamp @ 2014-06-04 15:34 UTC (permalink / raw)
To: Linux PowerPC Kernel, Scott Wood; +Cc: Linux device trees, Valentin Longchamp
The mux2 node is missing the clock-output-names field that is required
by the clk-ppc-corenet driver.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
---
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
index e2987a3..45ce43c 100644
--- a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
@@ -358,6 +358,7 @@
compatible = "fsl,qoriq-core-mux-1.0";
clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
+ clock-output-names = "cmux2";
};
mux3: mux3@60 {
--
1.8.0.1
^ permalink raw reply related
* Re: [PATCH] powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode
From: Vivek Goyal @ 2014-06-04 13:46 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: ego, matt, mahesh, kexec, linux-kernel, suzuki, ebiederm, paulus,
linuxppc-dev
In-Reply-To: <1401833365.3247.36.camel@pasglop>
On Wed, Jun 04, 2014 at 08:09:25AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote:
> > Yep, that makes sense. But unfortunately I don't have enough insight into
> > why exactly powerpc has to online the CPUs before doing a kexec. I just
> > know from the commit log and the comment mentioned above (and from my own
> > experiments) that the CPUs will get stuck if they were offline. Perhaps
> > somebody more knowledgeable can explain this in detail and suggest a proper
> > long-term solution.
> >
> > Matt, Ben, any thoughts on this?
>
> The problem is with our "soft offline" which we do on some platforms. When we
> offline we don't actually send the CPUs back to firmware or anything like that.
>
> We put them into a very low low power loop inside Linux.
>
> The new kernel has no way to extract them from that loop. So we must re-"online"
> them before we kexec so they can be passed to the new kernel normally (or returned
> to firmware like we do on powernv).
Srivatsa,
Looks like your patch has been merged.
I don't like the following change in arch independent code.
/*
* migrate_to_reboot_cpu() disables CPU hotplug assuming that
* no further code needs to use CPU hotplug (which is true in
* the reboot case). However, the kexec path depends on using
* CPU hotplug again; so re-enable it here.
*/
cpu_hotplug_enable();
As it is very powerpc specific requirement, can you enable hotplug in powerpc
arch dependent code as a short term solution.
Ideally one needs to fix the requirement of online all cpus in powerpc
as a long term solution and then get rid of hotplug enable call.
Thanks
Vivek
^ permalink raw reply
* Re: [PATCH] powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode
From: Vivek Goyal @ 2014-06-04 13:41 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: ego, matt, kexec, linux-kernel, suzuki, ebiederm, mahesh, paulus,
linuxppc-dev
In-Reply-To: <538E2FF8.8060707@linux.vnet.ibm.com>
On Wed, Jun 04, 2014 at 01:58:40AM +0530, Srivatsa S. Bhat wrote:
> On 05/28/2014 07:01 PM, Vivek Goyal wrote:
> > On Tue, May 27, 2014 at 04:25:34PM +0530, Srivatsa S. Bhat wrote:
> >> If we try to perform a kexec when the machine is in ST (Single-Threaded) mode
> >> (ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we
> >> get the following messages during boot:
> >>
> >> [ 0.089866] POWER8 performance monitor hardware support registered
> >> [ 0.089985] power8-pmu: PMAO restore workaround active.
> >> [ 5.095419] Processor 1 is stuck.
> >> [ 10.097933] Processor 2 is stuck.
> >> [ 15.100480] Processor 3 is stuck.
> >> [ 20.102982] Processor 4 is stuck.
> >> [ 25.105489] Processor 5 is stuck.
> >> [ 30.108005] Processor 6 is stuck.
> >> [ 35.110518] Processor 7 is stuck.
> >> [ 40.113369] Processor 9 is stuck.
> >> [ 45.115879] Processor 10 is stuck.
> >> [ 50.118389] Processor 11 is stuck.
> >> [ 55.120904] Processor 12 is stuck.
> >> [ 60.123425] Processor 13 is stuck.
> >> [ 65.125970] Processor 14 is stuck.
> >> [ 70.128495] Processor 15 is stuck.
> >> [ 75.131316] Processor 17 is stuck.
> >>
> >> Note that only the sibling threads are stuck, while the primary threads (0, 8,
> >> 16 etc) boot just fine. Looking closer at the previous step of kexec, we observe
> >> that kexec tries to wakeup (bring online) the sibling threads of all the cores,
> >> before performing kexec:
> >>
> >> [ 9464.131231] Starting new kernel
> >> [ 9464.148507] kexec: Waking offline cpu 1.
> >> [ 9464.148552] kexec: Waking offline cpu 2.
> >> [ 9464.148600] kexec: Waking offline cpu 3.
> >> [ 9464.148636] kexec: Waking offline cpu 4.
> >> [ 9464.148671] kexec: Waking offline cpu 5.
> >> [ 9464.148708] kexec: Waking offline cpu 6.
> >> [ 9464.148743] kexec: Waking offline cpu 7.
> >> [ 9464.148779] kexec: Waking offline cpu 9.
> >> [ 9464.148815] kexec: Waking offline cpu 10.
> >> [ 9464.148851] kexec: Waking offline cpu 11.
> >> [ 9464.148887] kexec: Waking offline cpu 12.
> >> [ 9464.148922] kexec: Waking offline cpu 13.
> >> [ 9464.148958] kexec: Waking offline cpu 14.
> >> [ 9464.148994] kexec: Waking offline cpu 15.
> >> [ 9464.149030] kexec: Waking offline cpu 17.
> >>
> >> Instrumenting this piece of code revealed that the cpu_up() operation actually
> >> fails with -EBUSY. Thus, only the primary threads of all the cores are online
> >> during kexec, and hence this is a sure-shot receipe for disaster, as explained
> >> in commit e8e5c2155b (powerpc/kexec: Fix orphaned offline CPUs across kexec),
> >> as well as in the comment above wake_offline_cpus().
> >>
> >> It turns out that cpu_up() was returning -EBUSY because the variable
> >> 'cpu_hotplug_disabled' was set to 1; and this disabling of CPU hotplug was done
> >> by migrate_to_reboot_cpu() inside kernel_kexec().
> >>
> >> Now, migrate_to_reboot_cpu() was originally written with the assumption that
> >> any further code will not need to perform CPU hotplug, since we are anyway in
> >> the reboot path. However, kexec is clearly not such a case, since we depend on
> >> onlining CPUs, atleast on powerpc.
> >>
> >> So re-enable cpu-hotplug after returning from migrate_to_reboot_cpu() in the
> >> kexec path, to fix this regression in kexec on powerpc.
> >>
> >> Also, wrap the cpu_up() in powerpc kexec code within a WARN_ON(), so that we
> >> can catch such issues more easily in the future.
> >>
> >> Fixes: c97102ba963 (kexec: migrate to reboot cpu)
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> >> ---
> >>
> >> arch/powerpc/kernel/machine_kexec_64.c | 2 +-
> >> kernel/kexec.c | 8 ++++++++
> >> 2 files changed, 9 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
> >> index 59d229a..879b3aa 100644
> >> --- a/arch/powerpc/kernel/machine_kexec_64.c
> >> +++ b/arch/powerpc/kernel/machine_kexec_64.c
> >> @@ -237,7 +237,7 @@ static void wake_offline_cpus(void)
> >> if (!cpu_online(cpu)) {
> >> printk(KERN_INFO "kexec: Waking offline cpu %d.\n",
> >> cpu);
> >> - cpu_up(cpu);
> >> + WARN_ON(cpu_up(cpu));
> >> }
> >> }
> >> }
> >> diff --git a/kernel/kexec.c b/kernel/kexec.c
> >> index c8380ad..28c5706 100644
> >> --- a/kernel/kexec.c
> >> +++ b/kernel/kexec.c
> >> @@ -1683,6 +1683,14 @@ int kernel_kexec(void)
> >> kexec_in_progress = true;
> >> kernel_restart_prepare(NULL);
> >> migrate_to_reboot_cpu();
> >> +
> >> + /*
> >> + * migrate_to_reboot_cpu() disables CPU hotplug assuming that
> >> + * no further code needs to use CPU hotplug (which is true in
> >> + * the reboot case). However, the kexec path depends on using
> >> + * CPU hotplug again; so re-enable it here.
> >> + */
> >> + cpu_hotplug_enable();
> >> printk(KERN_EMERG "Starting new kernel\n");
> >> machine_shutdown();
> >
> > After migrate_to_reboot_cpu(), we are calling machine_shutdown() which
> > calls disable_nonboot_cpus() and which in turn calls _cpu_down().
> >
>
> Hmm? I see only 'arm' calling disable_nonboot_cpus() from machine_shutdown().
> None of the other architectures call it. Is that a leftover in arm?
You are right. I did not notice that only arm is doing that. Looks like
it is calling into some platform code, I am not sure what exactly arm
does for disabling cpu.
x86 code calls stop_other_cpus() in machine_shutdown() which sends
REBOOT_VECTOR to other cpus and calls stop_this_cpu() which in turn
does.
for (;;)
halt();
IIUC, upon receipt of certain interrupts cpu will come out of halt state.
Not sure how safe it is from kexec point of view as we will be replacing
original kernel that means if cpu comes out of halt state it might be
running some random code.
Eric/hpa might know better the context here and what safeguards us on x86.
So one should not make cpu spin on some code as kexec will change that
code. It should be some other platform specific mechanism which brings
cpu in to hlt like state. So that way arm seems to be doing right thing.
I am not sure what powerpc does to stop cpus.
Thanks
Vivek
^ permalink raw reply
* Re: [PATCH] KVM: PPC: BOOK3S: PR: Fix PURR and SPURR emulation
From: Aneesh Kumar K.V @ 2014-06-04 13:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, agraf, kvm-ppc, kvm
In-Reply-To: <87vbsh6ji4.fsf@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> Paul Mackerras <paulus@samba.org> writes:
>
>> On Tue, Jun 03, 2014 at 05:46:11PM +0530, Aneesh Kumar K.V wrote:
>>> We use time base for PURR and SPURR emulation with PR KVM since we
>>> are emulating a single threaded core. When using time base
>>> we need to make sure that we don't accumulate time spent in the host
>>> in PURR and SPURR value.
>>
>> Mostly looks good except for this...
>>
>>> @@ -170,6 +175,11 @@ void kvmppc_copy_from_svcpu(struct kvm_vcpu *vcpu,
>>>
>>> out:
>>> preempt_enable();
>>> + /*
>>> + * Update purr and spurr using time base
>>> + */
>>> + vcpu->arch.purr += get_tb() - vcpu->arch.entry_tb;
>>> + vcpu->arch.spurr += get_tb() - vcpu->arch.entry_tb;
>>
>> You need to do those updates before the "out:" label. Otherwise if
>> this function gets called with !svcpu->in_use (which can happen if
>> CONFIG_PREEMPT is enabled) we would do these updates a second time for
>> one guest exit. The thing is that kvmppc_copy_from_svcpu() can get
>> called from kvmppc_core_vcpu_put_pr() if the vcpu task gets preempted
>> on the way out from the guest before we get to the regular call of
>> kvmppc_copy_from_svcpu(). It would then get called again when the
>> task gets to run, but this time it does nothing because svcpu->in_use
>> is false.
>
> Looking at the code, since we enable MSR.EE early now, we might possibly
> end up calling this function late in the guest exit path. That
> implies, we may account that time (time spent after a preempt immediately
> following a guest exit) in purr/spurr. I guess that amount of inaccuracy is
> ok, because that is the best we could do here ?
>
May be not, we do call kvmppc_copy_to_svcpu from preempt notifier
callbacks. That should ensure that we get the right value.
I have sent patch -V2 taking care of the above review comment.
-aneesh
^ permalink raw reply
* [PATCH V2] KVM: PPC: BOOK3S: PR: Fix PURR and SPURR emulation
From: Aneesh Kumar K.V @ 2014-06-04 11:17 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
We use time base for PURR and SPURR emulation with PR KVM since we
are emulating a single threaded core. When using time base
we need to make sure that we don't accumulate time spent in the host
in PURR and SPURR value.
Also we don't need to emulate mtspr because both the registers are
hypervisor resource.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
Changes from V1:
Move the purr/spurr update to happen only once in case of exit with preemption enabled.
arch/powerpc/include/asm/kvm_book3s.h | 2 --
arch/powerpc/include/asm/kvm_host.h | 4 ++--
arch/powerpc/kvm/book3s_emulate.c | 16 ++++++++--------
arch/powerpc/kvm/book3s_pr.c | 11 +++++++++++
4 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index f52f65694527..a20cc0bbd048 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -83,8 +83,6 @@ struct kvmppc_vcpu_book3s {
u64 sdr1;
u64 hior;
u64 msr_mask;
- u64 purr_offset;
- u64 spurr_offset;
#ifdef CONFIG_PPC_BOOK3S_32
u32 vsid_pool[VSID_POOL_SIZE];
u32 vsid_next;
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index bb66d8b8efdf..4a58731a0a72 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -503,8 +503,8 @@ struct kvm_vcpu_arch {
#ifdef CONFIG_BOOKE
u32 decar;
#endif
- u32 tbl;
- u32 tbu;
+ /* Time base value when we entered the guest */
+ u64 entry_tb;
u32 tcr;
ulong tsr; /* we need to perform set/clr_bits() which requires ulong */
u32 ivor[64];
diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index 3f295269af37..3565e775b61b 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -439,12 +439,6 @@ int kvmppc_core_emulate_mtspr_pr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
(mfmsr() & MSR_HV))
vcpu->arch.hflags |= BOOK3S_HFLAG_DCBZ32;
break;
- case SPRN_PURR:
- to_book3s(vcpu)->purr_offset = spr_val - get_tb();
- break;
- case SPRN_SPURR:
- to_book3s(vcpu)->spurr_offset = spr_val - get_tb();
- break;
case SPRN_GQR0:
case SPRN_GQR1:
case SPRN_GQR2:
@@ -572,10 +566,16 @@ int kvmppc_core_emulate_mfspr_pr(struct kvm_vcpu *vcpu, int sprn, ulong *spr_val
*spr_val = 0;
break;
case SPRN_PURR:
- *spr_val = get_tb() + to_book3s(vcpu)->purr_offset;
+ /*
+ * On exit we would have updated purr
+ */
+ *spr_val = vcpu->arch.purr;
break;
case SPRN_SPURR:
- *spr_val = get_tb() + to_book3s(vcpu)->purr_offset;
+ /*
+ * On exit we would have updated spurr
+ */
+ *spr_val = vcpu->arch.spurr;
break;
case SPRN_GQR0:
case SPRN_GQR1:
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 23367a7e44c3..ff15f8e31a27 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -120,6 +120,11 @@ void kvmppc_copy_to_svcpu(struct kvmppc_book3s_shadow_vcpu *svcpu,
#ifdef CONFIG_PPC_BOOK3S_64
svcpu->shadow_fscr = vcpu->arch.shadow_fscr;
#endif
+ /*
+ * Now also save the current time base value. We use this
+ * to find the guest purr and spurr value.
+ */
+ vcpu->arch.entry_tb = get_tb();
svcpu->in_use = true;
}
@@ -166,6 +171,12 @@ void kvmppc_copy_from_svcpu(struct kvm_vcpu *vcpu,
#ifdef CONFIG_PPC_BOOK3S_64
vcpu->arch.shadow_fscr = svcpu->shadow_fscr;
#endif
+ /*
+ * Update purr and spurr using time base on exit.
+ */
+ vcpu->arch.purr += get_tb() - vcpu->arch.entry_tb;
+ vcpu->arch.spurr += get_tb() - vcpu->arch.entry_tb;
+
svcpu->in_use = false;
out:
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] powerpc/powernv: Enable POWER8 doorbell IPIs
From: Michael Neuling @ 2014-06-04 11:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Preeti U Murthy, Paul Mackerras, linuxppc-dev, Anton Blanchard
In-Reply-To: <1401868995.9903.4.camel@concordia>
This patch enables POWER8 doorbell IPIs on powernv.
Since doorbells can only IPI within a core, we test to see when we can use
doorbells and if not we fall back to XICS. This also enables hypervisor
doorbells to wakeup us up from nap/sleep via the LPCR PECEDH bit.
Based on tests by Anton, the best case IPI latency between two threads drop=
ped
from 894ns to 512ns.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
v2:
Adds select of PPC_DOORBELL for PSERIES and POWERNV as suggested by mpe.
diff --git a/arch/powerpc/kernel/cpu_setup_power.S b/arch/powerpc/kernel/cp=
u_setup_power.S
index 1557e7c..4673353 100644
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ b/arch/powerpc/kernel/cpu_setup_power.S
@@ -56,6 +56,7 @@ _GLOBAL(__setup_cpu_power8)
li r0,0
mtspr SPRN_LPID,r0
mfspr r3,SPRN_LPCR
+ ori r3, r3, LPCR_PECEDH
bl __init_LPCR
bl __init_HFSCR
bl __init_tlb_power8
@@ -74,6 +75,7 @@ _GLOBAL(__restore_cpu_power8)
li r0,0
mtspr SPRN_LPID,r0
mfspr r3,SPRN_LPCR
+ ori r3, r3, LPCR_PECEDH
bl __init_LPCR
bl __init_HFSCR
bl __init_tlb_power8
diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platform=
s/powernv/Kconfig
index c252ee9..45a8ed0 100644
--- a/arch/powerpc/platforms/powernv/Kconfig
+++ b/arch/powerpc/platforms/powernv/Kconfig
@@ -17,6 +17,7 @@ config PPC_POWERNV
select CPU_FREQ_GOV_USERSPACE
select CPU_FREQ_GOV_ONDEMAND
select CPU_FREQ_GOV_CONSERVATIVE
+ select PPC_DOORBELL
default y
=20
config PPC_POWERNV_RTAS
diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/=
powernv/smp.c
index 0062a43..5fcfcf4 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -32,6 +32,7 @@
#include <asm/opal.h>
#include <asm/runlatch.h>
#include <asm/code-patching.h>
+#include <asm/dbell.h>
=20
#include "powernv.h"
=20
@@ -46,6 +47,11 @@ static void pnv_smp_setup_cpu(int cpu)
{
if (cpu !=3D boot_cpuid)
xics_setup_cpu();
+
+#ifdef CONFIG_PPC_DOORBELL
+ if (cpu_has_feature(CPU_FTR_DBELL))
+ doorbell_setup_this_cpu();
+#endif
}
=20
int pnv_smp_kick_cpu(int nr)
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platform=
s/pseries/Kconfig
index 2cb8b77..756b482 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -21,6 +21,7 @@ config PPC_PSERIES
select HAVE_CONTEXT_TRACKING
select HOTPLUG_CPU if SMP
select ARCH_RANDOM
+ select PPC_DOORBELL
default y
=20
config PPC_SPLPAR
diff --git a/arch/powerpc/sysdev/xics/icp-native.c b/arch/powerpc/sysdev/xi=
cs/icp-native.c
index 9dee470..de8d948 100644
--- a/arch/powerpc/sysdev/xics/icp-native.c
+++ b/arch/powerpc/sysdev/xics/icp-native.c
@@ -26,6 +26,7 @@
#include <asm/errno.h>
#include <asm/xics.h>
#include <asm/kvm_ppc.h>
+#include <asm/dbell.h>
=20
struct icp_ipl {
union {
@@ -145,7 +146,13 @@ static unsigned int icp_native_get_irq(void)
static void icp_native_cause_ipi(int cpu, unsigned long data)
{
kvmppc_set_host_ipi(cpu, 1);
- icp_native_set_qirr(cpu, IPI_PRIORITY);
+#ifdef CONFIG_PPC_DOORBELL
+ if (cpu_has_feature(CPU_FTR_DBELL) &&
+ (cpumask_test_cpu(cpu, cpu_sibling_mask(smp_processor_id()))))
+ doorbell_cause_ipi(cpu, data);
+ else
+#endif
+ icp_native_set_qirr(cpu, IPI_PRIORITY);
}
=20
void xics_wake_cpu(int cpu)
^ permalink raw reply related
* Re: [PATCH] KVM: PPC: BOOK3S: PR: Fix PURR and SPURR emulation
From: Aneesh Kumar K.V @ 2014-06-04 10:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, agraf, kvm-ppc, kvm
In-Reply-To: <20140604041547.GA32223@drongo>
Paul Mackerras <paulus@samba.org> writes:
> On Tue, Jun 03, 2014 at 05:46:11PM +0530, Aneesh Kumar K.V wrote:
>> We use time base for PURR and SPURR emulation with PR KVM since we
>> are emulating a single threaded core. When using time base
>> we need to make sure that we don't accumulate time spent in the host
>> in PURR and SPURR value.
>
> Mostly looks good except for this...
>
>> @@ -170,6 +175,11 @@ void kvmppc_copy_from_svcpu(struct kvm_vcpu *vcpu,
>>
>> out:
>> preempt_enable();
>> + /*
>> + * Update purr and spurr using time base
>> + */
>> + vcpu->arch.purr += get_tb() - vcpu->arch.entry_tb;
>> + vcpu->arch.spurr += get_tb() - vcpu->arch.entry_tb;
>
> You need to do those updates before the "out:" label. Otherwise if
> this function gets called with !svcpu->in_use (which can happen if
> CONFIG_PREEMPT is enabled) we would do these updates a second time for
> one guest exit. The thing is that kvmppc_copy_from_svcpu() can get
> called from kvmppc_core_vcpu_put_pr() if the vcpu task gets preempted
> on the way out from the guest before we get to the regular call of
> kvmppc_copy_from_svcpu(). It would then get called again when the
> task gets to run, but this time it does nothing because svcpu->in_use
> is false.
Looking at the code, since we enable MSR.EE early now, we might possibly
end up calling this function late in the guest exit path. That
implies, we may account that time (time spent after a preempt immediately
following a guest exit) in purr/spurr. I guess that amount of inaccuracy is
ok, because that is the best we could do here ?
-aneesh
^ permalink raw reply
* Re: [PATCH] PPC: BOOK3S: Disable/Enable TM looking at the ibm, pa-features device tree entry
From: Aneesh Kumar K.V @ 2014-06-04 10:36 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus
In-Reply-To: <871twcbvyn.fsf@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
>
>> Michael Neuling <mikey@neuling.org> writes:
>>
>>> Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> wrote:
>>>
>>>> Runtime disable transactional memory feature looking at pa-features
>>>> device tree entry. This provides a mechanism to disable TM on P8
>>>> systems.
>>>
>>> What are we actually achieving with this?
>>
>> PAPR compliance :) ? Also I wanted to disable guest kernel from doing
>> TM related save restore. Guest kernel already look at the cpu feature
>> before doing that. Hence needed a mechanism to disable the feature.
>>
>> Things like
>>
>> static inline void __switch_to_tm(struct task_struct *prev)
>> {
>> if (cpu_has_feature(CPU_FTR_TM)) {
>> tm_enable();
>> tm_reclaim_task(prev);
>> }
>> }
>>
>>
>>>
>>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>>> ---
>>>> arch/powerpc/kernel/prom.c | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>>>> index 668aa4791fd7..537bd7e7db0b 100644
>>>> --- a/arch/powerpc/kernel/prom.c
>>>> +++ b/arch/powerpc/kernel/prom.c
>>>> @@ -161,6 +161,11 @@ static struct ibm_pa_feature {
>>>> {CPU_FTR_NODSISRALIGN, 0, 0, 1, 1, 1},
>>>> {0, MMU_FTR_CI_LARGE_PAGE, 0, 1, 2, 0},
>>>> {CPU_FTR_REAL_LE, PPC_FEATURE_TRUE_LE, 5, 0, 0},
>>>> + /*
>>>> + * We should use CPU_FTR_TM_COMP so that if we disable TM, it won't get
>>>> + * enabled via device tree
>>>> + */
>>>> + {CPU_FTR_TM_COMP, 0, 0, 22, 0, 0},
>>>
>>> What does this do to guests? Will it turn TM unavailable into an
>>> illegal instruction?
>>>
>>
>> Good suggestion. I guess it should be facility unavailable interrupt ?
>> I should also make the sure __init_HFSCR only set HFSCR_TM only if the
>> cpu feature is enabled ?
>
> I looked at this and I guess we don't need to update HFSCR considering
> that the guest kernel (privileged) access to TM always happen within
> if (cpu_has_feature(CPU_FTR_TM)) conditional block. Also we want to
> disable this per guest and there is no easy way to suggest hypervisor
> that disable TM in HFSCR.
>
> BTW we already do this for guest problme state. We do in guest kernel
>
> if (cpu_has_feature(CPU_FTR_TM))
> regs->msr |= MSR_TM;
>
> IIUC that should result in facility unavailable interrupt when problem
> state try to access TM ?
>
> I will try to run some test with the patch and update here.
This will actually result in illegal instruction.
-aneesh
^ permalink raw reply
* Re: [PATCH 1/1] powerpc: correct DSCR during TM context switch
From: Michael Neuling @ 2014-06-04 10:03 UTC (permalink / raw)
To: Michael Ellerman; +Cc: aik, benh, linuxppc-dev, Sam Bobroff, khandual
In-Reply-To: <1401867077.9903.3.camel@concordia>
On Wed, 2014-06-04 at 17:31 +1000, Michael Ellerman wrote:
> Hi Sam,
>=20
> Comments inline ..
Ditto....
>=20
> On Wed, 2014-06-04 at 13:33 +1000, Sam Bobroff wrote:
> > Correct the DSCR SPR becoming temporarily corrupted when a task is
> > context switched when within a transaction. It is corrected when
> > the transaction is aborted (which will happen after a context switch)
> > but if the task has suspended (TSUSPEND) the transaction the incorrect
> > value can be seen.
>=20
> I don't quite follow this description. How is it corrected when the trans=
action
> is aborted, and when does that usually happen? If that happens the task c=
an't
> ever see the corrupted value?
>=20
> To hit the suspended case, the task starts a transaction, suspends it, is=
then
> context switched out and back in, and at that point it can see the wrong =
value?
Yep, that's it and it's corrupted until the transaction is rolled back
(normally at the tresume). At the tresume it gets rolled back to the
checkpointed value at tbegin and is no longer corrupt.
> > The problem is caused by saving a thread's DSCR afterNo it's lost at th=
at point as we've not saved it and it was overwritten when we did the trecl=
aim. it has already
> > been reverted to the CPU's default value:
> >=20
> > __switch_to() calls __switch_to_tm()
> > which calls tm_reclaim_task()
> > which calls tm_reclaim_thread()
> > which calls tm_reclaim() where the DSCR is reset
>=20
> Where the DSCR is set to DSCR_DEFAULT ? Or now PACA_DSCR since your previ=
ous
> patches?
>=20
> Could we instead fix the bug there by reverting to the thread's DSCR valu=
e?
We really need to save it earlier, before the treclaim which will
override it.
> > __switch_to() calls _switch
> > _switch() saves the DSCR to thread.dscrTBEGIN
> >=20
> > The fix is to treat the DSCR similarly to the TAR and save it early
> > in __switch_to().
> >=20
> > The program below will expose the problem:
>=20
>=20
> Can you drop this in tools/testing/selftests/powerpc/tm ?
>=20
> You'll need to create that directory, you can ape the Makefile from the p=
mu
> directory, it should be fairly obvious. See the pmu tests for how to inte=
grate
> with the test harness etc., or bug me if it's not straight forward.
>=20
>=20
> > diff --git a/arch/powerpc/include/asm/switch_to.h b/arch/powerpc/includ=
e/asm/switch_to.h
> > index 2737f46..3efd0e5 100644
> > --- a/arch/powerpc/include/asm/switch_to.h
> > +++ b/arch/powerpc/include/asm/switch_to.h
> > @@ -16,13 +16,15 @@ struct thread_struct;
> > extern struct task_struct *_switch(struct thread_struct *prev,
> > struct thread_struct *next);
> > #ifdef CONFIG_PPC_BOOK3S_64
> > -static inline void save_tar(struct thread_struct *prev)
> > +static inline void save_early_sprs(struct thread_struct *prev)
> > {
> > if (cpu_has_feature(CPU_FTR_ARCH_207S))
> > prev->tar =3D mfspr(SPRN_TAR);
> > + if (cpu_has_feature(CPU_FTR_DSCR))
> > + prev->dscr =3D mfspr(SPRN_DSCR);
> > }
>=20
> Are we going to end up saving more SPRs in this code? What makes the TAR =
& DSCR
> special vs everything else?
There are only a limited set of SPRs that TM checkpoints. The full list
is CR, LR, CTR, FPSCR, AMR, PPR, VRSAVE, VSCR, DSCR, and TAR. =20
http://www.scribd.com/doc/142877680/PowerISA-v2-07#outer_page_826
CR, LR, CTR, PPR are handled really early in the exception handler
FPSCR, VSCR are done in the FP/VMX/VSX code.
AMR we don't care about.
That just leaves the DSCR and the TAR for here....
... and the VRSAVE. Sam: did you have a patch to save that one early
too? I think we talked about it but forgot, or did we decide that it's
always broken anyway so we don't care? :-D
Mikey
> The nice thing about doing this in asm is it's nop'ed out for cpus that d=
on't
> have the DSCR. What does the generated code for this look like?
>=20
> > diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry=
_64.S
> > index 662c6dd..a107f4a 100644
> > --- a/arch/powerpc/kernel/entry_64.S
> > +++ b/arch/powerpc/kernel/entry_64.S
> > @@ -432,12 +432,6 @@ BEGIN_FTR_SECTION
> > std r24,THREAD_VRSAVE(r3)
> > END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
> > #endif /* CONFIG_ALTIVEC */
> > -#ifdef CONFIG_PPC64
> > -BEGIN_FTR_SECTION
> > - mfspr r25,SPRN_DSCR
> > - std r25,THREAD_DSCR(r3)
> > -END_FTR_SECTION_IFSET(CPU_FTR_DSCR)
> > -#endif
> > and. r0,r0,r22
> > beq+ 1f
> > andc r22,r22,r0
>=20
>=20
> cheers
>=20
>=20
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/powernv: Enable POWER8 doorbell IPIs
From: Michael Neuling @ 2014-06-04 9:38 UTC (permalink / raw)
To: Michael Ellerman
Cc: Preeti U Murthy, linuxppc-dev, Anton Blanchard, Paul Mackerras
In-Reply-To: <1401868995.9903.4.camel@concordia>
On Wed, 2014-06-04 at 18:03 +1000, Michael Ellerman wrote:
> On Mon, 2014-06-02 at 16:57 +1000, Michael Neuling wrote:
> > This patch enables POWER8 doorbell IPIs on powernv.
> >=20
> > Since doorbells can only IPI within a core, we test to see when we can =
use
> > doorbells and if not we fall back to XICS. This also enables hyperviso=
r
> > doorbells to wakeup us up from nap/sleep via the LPCR PECEDH bit.
> >=20
> > Based on tests by Anton, the best case IPI latency between two threads =
dropped
> > from 894ns to 512ns.
> >=20
> > Signed-off-by: Michael Neuling <mikey@neuling.org>
> > ---
> > arch/powerpc/kernel/cpu_setup_power.S | 2 ++
> > arch/powerpc/platforms/powernv/smp.c | 6 ++++++
> > arch/powerpc/sysdev/xics/icp-native.c | 9 ++++++++-
> > 3 files changed, 16 insertions(+), 1 deletion(-)
> >=20
> > diff --git a/arch/powerpc/kernel/cpu_setup_power.S b/arch/powerpc/kerne=
l/cpu_setup_power.S
> > index 1557e7c..4673353 100644
> > --- a/arch/powerpc/kernel/cpu_setup_power.S
> > +++ b/arch/powerpc/kernel/cpu_setup_power.S
> > @@ -56,6 +56,7 @@ _GLOBAL(__setup_cpu_power8)
> > li r0,0
> > mtspr SPRN_LPID,r0
> > mfspr r3,SPRN_LPCR
> > + ori r3, r3, LPCR_PECEDH
> > bl __init_LPCR
> > bl __init_HFSCR
> > bl __init_tlb_power8
> > @@ -74,6 +75,7 @@ _GLOBAL(__restore_cpu_power8)
> > li r0,0
> > mtspr SPRN_LPID,r0
> > mfspr r3,SPRN_LPCR
> > + ori r3, r3, LPCR_PECEDH
> > bl __init_LPCR
> > bl __init_HFSCR
> > bl __init_tlb_power8
> > diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platfo=
rms/powernv/smp.c
> > index 0062a43..5fcfcf4 100644
> > --- a/arch/powerpc/platforms/powernv/smp.c
> > +++ b/arch/powerpc/platforms/powernv/smp.c
> > @@ -32,6 +32,7 @@
> > #include <asm/opal.h>
> > #include <asm/runlatch.h>
> > #include <asm/code-patching.h>
> > +#include <asm/dbell.h>
> > =20
> > #include "powernv.h"
> > =20
> > @@ -46,6 +47,11 @@ static void pnv_smp_setup_cpu(int cpu)
> > {
> > if (cpu !=3D boot_cpuid)
> > xics_setup_cpu();
> > +
> > +#ifdef CONFIG_PPC_DOORBELL
> > + if (cpu_has_feature(CPU_FTR_DBELL))
> > + doorbell_setup_this_cpu();
> > +#endif
> > }
>=20
> Where does CONFIG_PPC_DOORBELL get set?
No where.
> It looks like the only place you can be getting it is from CONFIG_PPC_PSE=
RIES.
> If you build a POWERNV only kernel it will get disabled, which I don't th=
ink is
> what we want.
>=20
> I think we should select it for POWERNV as well as PSERIES. That would me=
an
> it's always enabled for any build of the files you touch, so you shouldn'=
t need
> the #ifdefs.
Ok, I'll add and resend.
Mikey
^ permalink raw reply
* Re: [PATCH] powerpc, xmon: Enable hardware instruction breakpoint support on POWER8
From: Anshuman Khandual @ 2014-06-04 8:48 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Michael Ellerman, linuxppc-dev, mikey
In-Reply-To: <538D654E.8040205@linux.vnet.ibm.com>
On 06/03/2014 11:33 AM, Anshuman Khandual wrote:
> On 05/30/2014 07:12 PM, Aneesh Kumar K.V wrote:
>> > Anshuman Khandual <khandual@linux.vnet.ibm.com> writes:
>> >
>>> >> This patch enables support for hardware instruction breakpoints on POWER8 with
>>> >> the help of a new register called CIABR (Completed Instruction Address Breakpoint
>>> >> Register). With this patch, single hardware instruction breakpoint can be added
>>> >> and cleared during any active xmon debug session. This hardware based instruction
>>> >> breakpoint mechanism works correctly along with the existing TRAP based instruction
>>> >> breakpoints available on xmon. Example usage as follows.
>>> >>
>>> >> (A) Start xmon:
>>> >> $echo x > /proc/sysrq-trigger
>>> >> SysRq : Entering xmon
>>> >> cpu 0x0: Vector: 0 at [c000001f6c67f960]
>>> >> pc: c000000000072078: .sysrq_handle_xmon+0x58/0x60
>>> >> lr: c000000000072078: .sysrq_handle_xmon+0x58/0x60
>>> >> sp: c000001f6c67fac0
>>> >> msr: 9000000000009032
>>> >> current = 0xc000001f6e709ac0
>>> >> paca = 0xc00000000fffa000 softe: 0 irq_happened: 0x00
>>> >> pid = 3250, comm = bash
>>> >> enter ? for help
>>> >> 0:mon> b
>>> >> type address
>>> >>
>>> >> (B) Set the breakpoint:
>>> >> 0:mon> ls .power_pmu_add
>>> >> .power_pmu_add: c000000000078f50
>>> >> 0:mon> bi c000000000078f50
>>> >> 0:mon> b
>>> >> type address
>>> >> 1 inst c000000000078f50 .power_pmu_add+0x0/0x2e0
>>> >> 0:mon> ls .perf_event_interrupt
>>> >> .perf_event_interrupt: c00000000007aee0
>>> >> 0:mon> bi c00000000007aee0
>>> >> One instruction breakpoint possible with CIABR
>>> >> 0:mon> x
>>> >>
>>> >> (C) Run the workload (with the breakpoint):
>>> >> $./perf record ls
>>> >> cpu 0x2: Vector: d00 (Single Step) at [c000001f718133a0]
>>> >> pc: c000000000078f54: .power_pmu_add+0x4/0x2e0
>>> >> lr: c000000000155be0: .event_sched_in+0x90/0x1d0
>>> >> sp: c000001f71813620
>>> >> msr: 9000000040109032
>>> >> current = 0xc000001f6ce30000
>>> >> paca = 0xc00000000fffa600 softe: 0 irq_happened: 0x01
>>> >> pid = 3270, comm = ls
>>> >> std r22,-80(r1)
>>> >> enter ? for help
>>> >>
>>> >> (D) Clear the breakpoint:
>>> >> 2:mon> bc
>>> >> All breakpoints cleared
>>> >> 2:mon> x
>>> >> [ perf record: Woken up 1 times to write data ]
>>> >> [ perf record: Captured and wrote 0.002 MB perf.data (~66 samples) ]
>>> >>
>>> >> (E) Run the workload again (without any breakpoints):
>>> >> $./perf record ls
>>> >> [ perf record: Woken up 1 times to write data ]
>>> >> [ perf record: Captured and wrote 0.001 MB perf.data (~61 samples) ]
>>> >>
>>> >> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>>> >> ---
>>> >> arch/powerpc/xmon/xmon.c | 62 ++++++++++++++++++++++++++++++++++++++++++++----
>>> >> 1 file changed, 58 insertions(+), 4 deletions(-)
>>> >>
>>> >> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
>>> >> index 3fd1d9a..f74ec83 100644
>>> >> --- a/arch/powerpc/xmon/xmon.c
>>> >> +++ b/arch/powerpc/xmon/xmon.c
>>> >> @@ -48,6 +48,7 @@
>>> >> #ifdef CONFIG_PPC64
>>> >> #include <asm/hvcall.h>
>>> >> #include <asm/paca.h>
>>> >> +#include <asm/plpar_wrappers.h>
>>> >> #endif
>>> >>
>>> >> #include "nonstdio.h"
>>> >> @@ -89,6 +90,7 @@ struct bpt {
>>> >> /* Bits in bpt.enabled */
>>> >> #define BP_IABR_TE 1 /* IABR translation enabled */
>>> >> #define BP_IABR 2
>>> >> +#define BP_CIABR 4
>>> >> #define BP_TRAP 8
>>> >> #define BP_DABR 0x10
>>> >>
>>> >> @@ -97,6 +99,7 @@ static struct bpt bpts[NBPTS];
>>> >> static struct bpt dabr;
>>> >> static struct bpt *iabr;
>>> >> static unsigned bpinstr = 0x7fe00008; /* trap */
>>> >> +static bool ciabr_used = false; /* CIABR instruction breakpoint */
>>> >>
>>> >> #define BP_NUM(bp) ((bp) - bpts + 1)
>>> >>
>>> >> @@ -269,6 +272,34 @@ static inline void cinval(void *p)
>>> >> asm volatile ("dcbi 0,%0; icbi 0,%0" : : "r" (p));
>>> >> }
>>> >>
>>> >> +static void write_ciabr(unsigned long ciabr)
>>> >> +{
>>> >> + if (cpu_has_feature(CPU_FTR_HVMODE)) {
>>> >> + mtspr(SPRN_CIABR, ciabr);
>>> >> + return;
>>> >> + }
>>> >> +
>>> >> +#ifdef CONFIG_PPC64
>>> >> + plapr_set_ciabr(ciabr);
>>> >> +#endif
>>> >> +}
>>> >> +
>>> >> +static void set_ciabr(unsigned long addr)
>>> >> +{
>>> >> + addr &= ~CIABR_PRIV;
>>> >> + if (cpu_has_feature(CPU_FTR_HVMODE))
>>> >> + addr |= CIABR_PRIV_HYPER;
>>> >> + else
>>> >> + addr |= CIABR_PRIV_SUPER;
>>> >> + write_ciabr(addr);
>>> >> +}
>>> >> +
>>> >> +static void clear_ciabr(void)
>>> >> +{
>>> >> + if (cpu_has_feature(CPU_FTR_ARCH_207S))
>>> >> + write_ciabr(0);
>>> >> +}
>>> >> +
>>> >> /*
>>> >> * Disable surveillance (the service processor watchdog function)
>>> >> * while we are in xmon.
>>> >> @@ -764,6 +795,9 @@ static void insert_cpu_bpts(void)
>>> >> if (iabr && cpu_has_feature(CPU_FTR_IABR))
>>> >> mtspr(SPRN_IABR, iabr->address
>>> >> | (iabr->enabled & (BP_IABR|BP_IABR_TE)));
>>> >> +
>>> >> + if (iabr && cpu_has_feature(CPU_FTR_ARCH_207S))
>>> >> + set_ciabr(iabr->address);
>>> >> }
>>> >>
>>> >> static void remove_bpts(void)
>>> >> @@ -791,6 +825,7 @@ static void remove_cpu_bpts(void)
>>> >> hw_breakpoint_disable();
>>> >> if (cpu_has_feature(CPU_FTR_IABR))
>>> >> mtspr(SPRN_IABR, 0);
>>> >> + clear_ciabr();
>>> >> }
>>> >>
>>> >> /* Command interpreting routine */
>>> >> @@ -1124,7 +1159,7 @@ static char *breakpoint_help_string =
>>> >> "b <addr> [cnt] set breakpoint at given instr addr\n"
>>> >> "bc clear all breakpoints\n"
>>> >> "bc <n/addr> clear breakpoint number n or at addr\n"
>>> >> - "bi <addr> [cnt] set hardware instr breakpoint (POWER3/RS64 only)\n"
>>> >> + "bi <addr> [cnt] set hardware instr breakpoint (POWER3/RS64/POWER8 only)\n"
>>> >> "bd <addr> [cnt] set hardware data breakpoint\n"
>>> >> "";
>>> >>
>>> >> @@ -1163,11 +1198,20 @@ bpt_cmds(void)
>>> >> break;
>>> >>
>>> >> case 'i': /* bi - hardware instr breakpoint */
>>> >> - if (!cpu_has_feature(CPU_FTR_IABR)) {
>>> >> + if (!cpu_has_feature(CPU_FTR_IABR) && !cpu_has_feature(CPU_FTR_ARCH_207S)) {
>>> >> printf("Hardware instruction breakpoint "
>>> >> "not supported on this cpu\n");
>>> >> break;
>>> >> }
>>> >> +
>>> >> + if (cpu_has_feature(CPU_FTR_ARCH_207S)) {
>>> >> + if (ciabr_used) {
>>> >> + printf("One instruction breakpoint "
>>> >> + "possible with CIABR\n");
>>> >> + break;
>>> >> + }
>> >
>> > We don't seem to do that with iabr ? Why keep ciabr different
> Right now with the IABR implementation if we try to set hardware instruction
> breakpoint while one is already there, it just get overridden with the new
> address without complaining. I thought with this at least for CIABR cases,
> it will complain about it and require the user to clear the breakpoint
> explicitly before allowing a new breakpoint. Okay will remove this.
>
I tried removing the "ciabr_used" variable and all related checks/assignments on it.
Then I was able to add all these three address as hardware instruction breakpoint
and xmon never complained that it might override the existing actual checkpoint
implemented with CIABR. It accepted all the three addresses which can later be
listed as below.
0:mon> b
type address
1 inst c0000000000830d0 .power_pmu_add+0x0/0x2e0
2 inst c000000000084690 .power_pmu_del+0x0/0x3a0
3 inst c000000000085060 .perf_event_interrupt+0x0/0x480
But in reality, only perf_event_interrupt function's address got written into CIABR
register and got triggered with the workload. I dont have a system which has IABR
support to test it's behaviour for this situation. But this does not sound okay,
we should explicitly inform the user that the hardware instruction breakpoint has
been overridden with the latest command or reject the attempt. Looking for some
suggestions in this regard. Thank you.
^ permalink raw reply
* RE: [RESEND PATCH] memory: Freescale CoreNet Coherency Fabric error reporting driver
From: Bharat.Bhushan @ 2014-06-04 8:17 UTC (permalink / raw)
To: Scott Wood, Greg Kroah-Hartman
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <20140530222743.GA6918@home.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGludXhwcGMtZGV2IFtt
YWlsdG86bGludXhwcGMtZGV2LQ0KPiBib3VuY2VzK2JoYXJhdC5iaHVzaGFuPWZyZWVzY2FsZS5j
b21AbGlzdHMub3psYWJzLm9yZ10gT24gQmVoYWxmIE9mIFNjb3R0IFdvb2QNCj4gU2VudDogU2F0
dXJkYXksIE1heSAzMSwgMjAxNCAzOjU4IEFNDQo+IFRvOiBHcmVnIEtyb2FoLUhhcnRtYW4NCj4g
Q2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJu
ZWwub3JnDQo+IFN1YmplY3Q6IFtSRVNFTkQgUEFUQ0hdIG1lbW9yeTogRnJlZXNjYWxlIENvcmVO
ZXQgQ29oZXJlbmN5IEZhYnJpYyBlcnJvcg0KPiByZXBvcnRpbmcgZHJpdmVyDQo+IA0KPiBUaGUg
Q29yZU5ldCBDb2hlcmVuY3kgRmFicmljIGlzIHBhcnQgb2YgdGhlIG1lbW9yeSBzdWJzeXN0ZW0g
b24gc29tZSBGcmVlc2NhbGUNCj4gUW9ySVEgY2hpcHMuICBJdCBjYW4gcmVwb3J0IGNvaGVyZW5j
eSB2aW9sYXRpb25zIChlLmcuDQo+IGR1ZSB0byBtaXN1c2luZyBtZW1vcnkgdGhhdCBpcyBtYXBw
ZWQgbm9uY29oZXJlbnQpIGFzIHdlbGwgYXMgdHJhbnNhY3Rpb25zIHRoYXQNCj4gZG8gbm90IGhp
dCBhbnkgbG9jYWwgYWNjZXNzIHdpbmRvdywgb3Igd2hpY2ggaGl0IGEgbG9jYWwgYWNjZXNzIHdp
bmRvdyB3aXRoIGFuDQo+IGludmFsaWQgdGFyZ2V0IElELg0KPiANCj4gU2lnbmVkLW9mZi1ieTog
U2NvdHQgV29vZCA8c2NvdHR3b29kQGZyZWVzY2FsZS5jb20+DQo+IC0tLQ0KPiBSZXNlbmRpbmcg
dG8gdGhlIHByb3BlciBsaXN0IGFkZHJlc3NlcyAtLSBzb3JyeSBmb3IgdGhlIGR1cGxpY2F0ZS4N
Cj4gDQo+ICBhcmNoL3Bvd2VycGMvY29uZmlncy9jb3JlbmV0MzJfc21wX2RlZmNvbmZpZyB8ICAg
MSArDQo+ICBhcmNoL3Bvd2VycGMvY29uZmlncy9jb3JlbmV0NjRfc21wX2RlZmNvbmZpZyB8ICAg
MSArDQo+ICBkcml2ZXJzL21lbW9yeS9LY29uZmlnICAgICAgICAgICAgICAgICAgICAgICB8ICAx
MCArKw0KPiAgZHJpdmVycy9tZW1vcnkvTWFrZWZpbGUgICAgICAgICAgICAgICAgICAgICAgfCAg
IDEgKw0KPiAgZHJpdmVycy9tZW1vcnkvZnNsLWNvcmVuZXQtY2YuYyAgICAgICAgICAgICAgfCAy
NDYgKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+ICA1IGZpbGVzIGNoYW5nZWQsIDI1OSBp
bnNlcnRpb25zKCspDQo+ICBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVycy9tZW1vcnkvZnNsLWNv
cmVuZXQtY2YuYw0KPiANCj4gZGlmZiAtLWdpdCBhL2FyY2gvcG93ZXJwYy9jb25maWdzL2NvcmVu
ZXQzMl9zbXBfZGVmY29uZmlnDQo+IGIvYXJjaC9wb3dlcnBjL2NvbmZpZ3MvY29yZW5ldDMyX3Nt
cF9kZWZjb25maWcNCj4gaW5kZXggYzE5ZmYwNS4uMGM5OWQ3ZSAxMDA2NDQNCj4gLS0tIGEvYXJj
aC9wb3dlcnBjL2NvbmZpZ3MvY29yZW5ldDMyX3NtcF9kZWZjb25maWcNCj4gKysrIGIvYXJjaC9w
b3dlcnBjL2NvbmZpZ3MvY29yZW5ldDMyX3NtcF9kZWZjb25maWcNCj4gQEAgLTE3OSwzICsxNzks
NCBAQCBDT05GSUdfQ1JZUFRPX1NIQTUxMj15ICBDT05GSUdfQ1JZUFRPX0FFUz15ICAjDQo+IENP
TkZJR19DUllQVE9fQU5TSV9DUFJORyBpcyBub3Qgc2V0ICBDT05GSUdfQ1JZUFRPX0RFVl9GU0xf
Q0FBTT15DQo+ICtDT05GSUdfRlNMX0NPUkVORVRfQ0Y9eQ0KPiBkaWZmIC0tZ2l0IGEvYXJjaC9w
b3dlcnBjL2NvbmZpZ3MvY29yZW5ldDY0X3NtcF9kZWZjb25maWcNCj4gYi9hcmNoL3Bvd2VycGMv
Y29uZmlncy9jb3JlbmV0NjRfc21wX2RlZmNvbmZpZw0KPiBpbmRleCA1YzdmYTE5Li44ZmI2MTZk
IDEwMDY0NA0KPiAtLS0gYS9hcmNoL3Bvd2VycGMvY29uZmlncy9jb3JlbmV0NjRfc21wX2RlZmNv
bmZpZw0KPiArKysgYi9hcmNoL3Bvd2VycGMvY29uZmlncy9jb3JlbmV0NjRfc21wX2RlZmNvbmZp
Zw0KPiBAQCAtMTc1LDMgKzE3NSw0IEBAIENPTkZJR19DUllQVE9fU0hBMjU2PXkgIENPTkZJR19D
UllQVE9fU0hBNTEyPXkgICMNCj4gQ09ORklHX0NSWVBUT19BTlNJX0NQUk5HIGlzIG5vdCBzZXQg
IENPTkZJR19DUllQVE9fREVWX0ZTTF9DQUFNPXkNCj4gK0NPTkZJR19GU0xfQ09SRU5FVF9DRj15
DQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL21lbW9yeS9LY29uZmlnIGIvZHJpdmVycy9tZW1vcnkv
S2NvbmZpZyBpbmRleA0KPiBjNTllOWM5Li5mYWI4MWExIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJz
L21lbW9yeS9LY29uZmlnDQo+ICsrKyBiL2RyaXZlcnMvbWVtb3J5L0tjb25maWcNCj4gQEAgLTYx
LDYgKzYxLDE2IEBAIGNvbmZpZyBURUdSQTMwX01DDQo+ICAJICBhbmFseXNpcywgZXNwZWNpYWxs
eSBmb3IgSU9NTVUvU01NVShTeXN0ZW0gTWVtb3J5IE1hbmFnZW1lbnQNCj4gIAkgIFVuaXQpIG1v
ZHVsZS4NCj4gDQo+ICtjb25maWcgRlNMX0NPUkVORVRfQ0YNCj4gKwl0cmlzdGF0ZSAiRnJlZXNj
YWxlIENvcmVOZXQgRXJyb3IgUmVwb3J0aW5nIg0KPiArCWRlcGVuZHMgb24gRlNMX1NPQ19CT09L
RQ0KPiArCWhlbHANCj4gKwkgIFNheSBZIGZvciByZXBvcnRpbmcgb2YgZXJyb3JzIGZyb20gdGhl
IEZyZWVzY2FsZSBDb3JlTmV0DQo+ICsJICBDb2hlcmVuY3kgRmFicmljLiAgRXJyb3JzIHJlcG9y
dGVkIGluY2x1ZGUgYWNjZXNzZXMgdG8NCj4gKwkgIHBoeXNpY2FsIGFkZHJlc3NlcyB0aGF0IG1h
cHBlZCBieSBubyBsb2NhbCBhY2Nlc3Mgd2luZG93DQo+ICsJICAoTEFXKSBvciBhbiBpbnZhbGlk
IExBVywgYXMgd2VsbCBhcyBiYWQgY2FjaGUgc3RhdGUgdGhhdA0KPiArCSAgcmVwcmVzZW50cyBh
IGNvaGVyZW5jeSB2aW9sYXRpb24uDQo+ICsNCj4gIGNvbmZpZyBGU0xfSUZDDQo+ICAJYm9vbA0K
PiAgCWRlcGVuZHMgb24gRlNMX1NPQw0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9tZW1vcnkvTWFr
ZWZpbGUgYi9kcml2ZXJzL21lbW9yeS9NYWtlZmlsZSBpbmRleA0KPiA3MTE2MGEyLi40MDU1YzQ3
IDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL21lbW9yeS9NYWtlZmlsZQ0KPiArKysgYi9kcml2ZXJz
L21lbW9yeS9NYWtlZmlsZQ0KPiBAQCAtNyw2ICs3LDcgQEAgb2JqLSQoQ09ORklHX09GKQkJKz0g
b2ZfbWVtb3J5Lm8NCj4gIGVuZGlmDQo+ICBvYmotJChDT05GSUdfVElfQUVNSUYpCQkrPSB0aS1h
ZW1pZi5vDQo+ICBvYmotJChDT05GSUdfVElfRU1JRikJCSs9IGVtaWYubw0KPiArb2JqLSQoQ09O
RklHX0ZTTF9DT1JFTkVUX0NGKQkrPSBmc2wtY29yZW5ldC1jZi5vDQo+ICBvYmotJChDT05GSUdf
RlNMX0lGQykJCSs9IGZzbF9pZmMubw0KPiAgb2JqLSQoQ09ORklHX01WRUJVX0RFVkJVUykJKz0g
bXZlYnUtZGV2YnVzLm8NCj4gIG9iai0kKENPTkZJR19URUdSQTIwX01DKQkrPSB0ZWdyYTIwLW1j
Lm8NCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvbWVtb3J5L2ZzbC1jb3JlbmV0LWNmLmMgYi9kcml2
ZXJzL21lbW9yeS9mc2wtY29yZW5ldC1jZi5jDQo+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0IGluZGV4
IDAwMDAwMDAuLmE1N2E2MTQNCj4gLS0tIC9kZXYvbnVsbA0KPiArKysgYi9kcml2ZXJzL21lbW9y
eS9mc2wtY29yZW5ldC1jZi5jDQo+IEBAIC0wLDAgKzEsMjQ2IEBADQo+ICsvKg0KPiArICogQ29y
ZU5ldCBDb2hlcmVuY3kgRmFicmljIGVycm9yIHJlcG9ydGluZw0KPiArICoNCj4gKyAqIENvcHly
aWdodCAyMDE0IEZyZWVzY2FsZSBTZW1pY29uZHVjdG9yIEluYy4NCj4gKyAqDQo+ICsgKiBUaGlz
IHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgIGl0IGFuZC9v
cg0KPiArbW9kaWZ5IGl0DQo+ICsgKiB1bmRlciAgdGhlIHRlcm1zIG9mICB0aGUgR05VIEdlbmVy
YWwgIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQ0KPiArdGhlDQo+ICsgKiBGcmVlIFNv
ZnR3YXJlIEZvdW5kYXRpb247ICBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSAgTGljZW5zZSwgb3Ig
KGF0DQo+ICt5b3VyDQo+ICsgKiBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KPiArICovDQo+
ICsNCj4gKyNpbmNsdWRlIDxsaW51eC9pbnRlcnJ1cHQuaD4NCj4gKyNpbmNsdWRlIDxsaW51eC9p
by5oPg0KPiArI2luY2x1ZGUgPGxpbnV4L2lycS5oPg0KPiArI2luY2x1ZGUgPGxpbnV4L21vZHVs
ZS5oPg0KPiArI2luY2x1ZGUgPGxpbnV4L29mLmg+DQo+ICsjaW5jbHVkZSA8bGludXgvb2ZfYWRk
cmVzcy5oPg0KPiArI2luY2x1ZGUgPGxpbnV4L29mX2RldmljZS5oPg0KPiArI2luY2x1ZGUgPGxp
bnV4L29mX2lycS5oPg0KPiArI2luY2x1ZGUgPGxpbnV4L3BsYXRmb3JtX2RldmljZS5oPg0KPiAr
DQo+ICtlbnVtIGNjZl92ZXJzaW9uIHsNCj4gKwlDQ0YxLA0KPiArCUNDRjIsDQo+ICt9Ow0KPiAr
DQo+ICtzdHJ1Y3QgY2NmX2luZm8gew0KPiArCWVudW0gY2NmX3ZlcnNpb24gdmVyc2lvbjsNCj4g
KwlpbnQgZXJyX3JlZ19vZmZzOw0KPiArfTsNCj4gKw0KPiArc3RhdGljIGNvbnN0IHN0cnVjdCBj
Y2ZfaW5mbyBjY2YxX2luZm8gPSB7DQo+ICsJLnZlcnNpb24gPSBDQ0YxLA0KPiArCS5lcnJfcmVn
X29mZnMgPSAweGEwMCwNCj4gK307DQo+ICsNCj4gK3N0YXRpYyBjb25zdCBzdHJ1Y3QgY2NmX2lu
Zm8gY2NmMl9pbmZvID0gew0KPiArCS52ZXJzaW9uID0gQ0NGMiwNCj4gKwkuZXJyX3JlZ19vZmZz
ID0gMHhlNDAsDQo+ICt9Ow0KPiArDQo+ICtzdGF0aWMgY29uc3Qgc3RydWN0IG9mX2RldmljZV9p
ZCBjY2ZfbWF0Y2hlc1tdID0gew0KPiArCXsNCj4gKwkJLmNvbXBhdGlibGUgPSAiZnNsLGNvcmVu
ZXQxLWNmIiwNCj4gKwkJLmRhdGEgPSAmY2NmMV9pbmZvLA0KPiArCX0sDQo+ICsJew0KPiArCQku
Y29tcGF0aWJsZSA9ICJmc2wsY29yZW5ldDItY2YiLA0KPiArCQkuZGF0YSA9ICZjY2YyX2luZm8s
DQo+ICsJfSwNCj4gKwl7fQ0KPiArfTsNCj4gKw0KPiArc3RydWN0IGNjZl9lcnJfcmVncyB7DQo+
ICsJdTMyIGVycmRldDsJCS8qIDB4MDAgRXJyb3IgRGV0ZWN0IFJlZ2lzdGVyICovDQo+ICsJLyog
MHgwNCBFcnJvciBFbmFibGUgKGNjZjEpL0Rpc2FibGUgKGNjZjIpIFJlZ2lzdGVyICovDQo+ICsJ
dTMyIGVycmRpczsNCj4gKwkvKiAweDA4IEVycm9yIEludGVycnVwdCBFbmFibGUgUmVnaXN0ZXIg
KGNjZjIgb25seSkgKi8NCj4gKwl1MzIgZXJyaW50ZW47DQo+ICsJdTMyIGNlY2FyOwkJLyogMHgw
YyBFcnJvciBDYXB0dXJlIEF0dHJpYnV0ZSBSZWdpc3RlciAqLw0KPiArCXUzMiBjZWNhZHJoOwkJ
LyogMHgxMCBFcnJvciBDYXB0dXJlIEFkZHJlc3MgSGlnaCAqLw0KDQpzL2NlY2FkcmgvY2VjYWRk
cmgvZw0KVGhpcyB3YXkgd2Ugd2lsbCBiZSBjb25zaXN0ZW50IHdpdGggUmVmZXJlbmNlIG1hbnVh
bC4NCg0KPiArCXUzMiBjZWNhZHJsOwkJLyogMHgxNCBFcnJvciBDYXB0dXJlIEFkZHJlc3MgTG93
ICovDQoNCnMvY2VjYWRybC9jZWNhZGRybC9nDQoNCj4gKwl1MzIgY2VjYXIyOwkJLyogMHgxOCBF
cnJvciBDYXB0dXJlIEF0dHJpYnV0ZSBSZWdpc3RlciAyICovDQo+ICt9Ow0KPiArDQo+ICsvKiBM
QUUvQ1YgYWxzbyB2YWxpZCBmb3IgZXJyZGlzIGFuZCBlcnJpbnRlbiAqLw0KPiArI2RlZmluZSBF
UlJERVRfTEFFCQkoMSA8PCAwKSAgLyogTG9jYWwgQWNjZXNzIEVycm9yICovDQo+ICsjZGVmaW5l
IEVSUkRFVF9DVgkJKDEgPDwgMSkgIC8qIENvaGVyZW5jeSBWaW9sYXRpb24gKi8NCj4gKyNkZWZp
bmUgRVJSREVUX0NUWVBFX1NISUZUCTI2CSAgLyogQ2FwdHVyZSBUeXBlIChjY2YyIG9ubHkpICov
DQo+ICsjZGVmaW5lIEVSUkRFVF9DVFlQRV9NQVNLCSgweDNmIDw8IEVSUkRFVF9DVFlQRV9TSElG
VCkNCg0KU2hvdWxkIG5vdCB0aGlzIGJlICgweDFmIDw8IEVSUkRFVF9DVFlQRV9TSElGVCkNCg0K
PiArI2RlZmluZSBFUlJERVRfQ0FQCQkoMSA8PCAzMSkgLyogQ2FwdHVyZSBWYWxpZCAoY2NmMiBv
bmx5KSAqLw0KPiArDQo+ICsjZGVmaW5lIENFQ0FSX1ZBTAkJKDEgPDwgMCkgIC8qIFZhbGlkIChj
Y2YxIG9ubHkpICovDQo+ICsjZGVmaW5lIENFQ0FSX1VWVAkJKDEgPDwgMTUpIC8qIFVuYXZhaWxh
YmxlIHRhcmdldCBJRCAoY2NmMSkgKi8NCj4gKyNkZWZpbmUgQ0VDQVJfU1JDSURfU0hJRlRfQ0NG
MQkyNA0KPiArI2RlZmluZSBDRUNBUl9TUkNJRF9NQVNLX0NDRjEJKDB4ZmYgPDwgQ0VDQVJfU1JD
SURfU0hJRlRfQ0NGMSkNCj4gKyNkZWZpbmUgQ0VDQVJfU1JDSURfU0hJRlRfQ0NGMgkxOA0KPiAr
I2RlZmluZSBDRUNBUl9TUkNJRF9NQVNLX0NDRjIJKDB4ZmYgPDwgQ0VDQVJfU1JDSURfU0hJRlRf
Q0NGMikNCj4gKw0KPiArI2RlZmluZSBDRUNBRFJIX0FERFJICQkweGYNCg0KT24gY2NmMiB0aGlz
IGlkIDB4ZmYuDQoNCj4gKw0KPiArc3RydWN0IGNjZl9wcml2YXRlIHsNCj4gKwljb25zdCBzdHJ1
Y3QgY2NmX2luZm8gKmluZm87DQo+ICsJc3RydWN0IGRldmljZSAqZGV2Ow0KPiArCXZvaWQgX19p
b21lbSAqcmVnczsNCj4gKwlzdHJ1Y3QgY2NmX2Vycl9yZWdzIF9faW9tZW0gKmVycl9yZWdzOyB9
Ow0KPiArDQo+ICtzdGF0aWMgaXJxcmV0dXJuX3QgY2NmX2lycShpbnQgaXJxLCB2b2lkICpkZXZf
aWQpIHsNCj4gKwlzdHJ1Y3QgY2NmX3ByaXZhdGUgKmNjZiA9IGRldl9pZDsNCj4gKwlzdGF0aWMg
REVGSU5FX1JBVEVMSU1JVF9TVEFURShyYXRlbGltaXQsIERFRkFVTFRfUkFURUxJTUlUX0lOVEVS
VkFMLA0KPiArCQkJCSAgICAgIERFRkFVTFRfUkFURUxJTUlUX0JVUlNUKTsNCj4gKwl1MzIgZXJy
ZGV0LCBjZWNhciwgY2VjYXIyOw0KPiArCXU2NCBhZGRyOw0KPiArCXUzMiBzcmNfaWQ7DQo+ICsJ
Ym9vbCB1dnQgPSBmYWxzZTsNCj4gKwlib29sIGNhcF92YWxpZCA9IGZhbHNlOw0KPiArDQo+ICsJ
ZXJyZGV0ID0gaW9yZWFkMzJiZSgmY2NmLT5lcnJfcmVncy0+ZXJyZGV0KTsNCj4gKwljZWNhciA9
IGlvcmVhZDMyYmUoJmNjZi0+ZXJyX3JlZ3MtPmNlY2FyKTsNCj4gKwljZWNhcjIgPSBpb3JlYWQz
MmJlKCZjY2YtPmVycl9yZWdzLT5jZWNhcjIpOw0KPiArCWFkZHIgPSBpb3JlYWQzMmJlKCZjY2Yt
PmVycl9yZWdzLT5jZWNhZHJsKTsNCj4gKwlhZGRyIHw9ICgodTY0KShpb3JlYWQzMmJlKCZjY2Yt
PmVycl9yZWdzLT5jZWNhZHJoKSAmDQo+ICsJCSAgICAgICBDRUNBRFJIX0FERFJIKSkgPDwgMzI7
DQoNClNvIHRoaXMgZ28gZG93biB0byBjY2YgdmVyc2lvbiB0eXBlIHN3aXRjaC4gDQoNCj4gKw0K
PiArCWlmICghX19yYXRlbGltaXQoJnJhdGVsaW1pdCkpDQo+ICsJCWdvdG8gb3V0Ow0KPiArDQo+
ICsJc3dpdGNoIChjY2YtPmluZm8tPnZlcnNpb24pIHsNCj4gKwljYXNlIENDRjE6DQo+ICsJCWlm
IChjZWNhciAmIENFQ0FSX1ZBTCkgew0KPiArCQkJaWYgKGNlY2FyICYgQ0VDQVJfVVZUKQ0KPiAr
CQkJCXV2dCA9IHRydWU7DQo+ICsNCj4gKwkJCXNyY19pZCA9IChjZWNhciAmIENFQ0FSX1NSQ0lE
X01BU0tfQ0NGMSkgPj4NCj4gKwkJCQkgQ0VDQVJfU1JDSURfU0hJRlRfQ0NGMTsNCj4gKwkJCWNh
cF92YWxpZCA9IHRydWU7DQo+ICsJCX0NCj4gKw0KPiArCQlicmVhazsNCj4gKwljYXNlIENDRjI6
DQo+ICsJCWlmIChlcnJkZXQgJiBFUlJERVRfQ0FQKSB7DQo+ICsJCQlzcmNfaWQgPSAoY2VjYXIg
JiBDRUNBUl9TUkNJRF9NQVNLX0NDRjIpID4+DQo+ICsJCQkJIENFQ0FSX1NSQ0lEX1NISUZUX0ND
RjI7DQo+ICsJCQljYXBfdmFsaWQgPSB0cnVlOw0KPiArCQl9DQo+ICsNCj4gKwkJYnJlYWs7DQo+
ICsJfQ0KPiArDQo+ICsJZGV2X2NyaXQoY2NmLT5kZXYsICJlcnJkZXQgMHglMDh4IGNlY2FyIDB4
JTA4eCBjZWNhcjIgMHglMDh4XG4iLA0KPiArCQkgZXJyZGV0LCBjZWNhciwgY2VjYXIyKTsNCj4g
Kw0KPiArCWlmIChlcnJkZXQgJiBFUlJERVRfTEFFKSB7DQo+ICsJCWlmICh1dnQpDQo+ICsJCQlk
ZXZfY3JpdChjY2YtPmRldiwgIkxBVyBVbmF2YWlsYWJsZSBUYXJnZXQgSURcbiIpOw0KPiArCQll
bHNlDQo+ICsJCQlkZXZfY3JpdChjY2YtPmRldiwgIkxvY2FsIEFjY2VzcyBXaW5kb3cgRXJyb3Jc
biIpOw0KPiArCX0NCj4gKw0KPiArCWlmIChlcnJkZXQgJiBFUlJERVRfQ1YpDQo+ICsJCWRldl9j
cml0KGNjZi0+ZGV2LCAiQ29oZXJlbmN5IFZpb2xhdGlvblxuIik7DQo+ICsNCj4gKwlpZiAoY2Fw
X3ZhbGlkKSB7DQo+ICsJCWRldl9jcml0KGNjZi0+ZGV2LCAiYWRkcmVzcyAweCUwOWxseCwgc3Jj
IGlkIDB4JXhcbiIsDQo+ICsJCQkgYWRkciwgc3JjX2lkKTsNCj4gKwl9DQo+ICsNCj4gK291dDoN
Cj4gKwlpb3dyaXRlMzJiZShlcnJkZXQsICZjY2YtPmVycl9yZWdzLT5lcnJkZXQpOw0KPiArCXJl
dHVybiBlcnJkZXQgPyBJUlFfSEFORExFRCA6IElSUV9OT05FOyB9DQo+ICsNCj4gK3N0YXRpYyBp
bnQgY2NmX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpIHsNCj4gKwlzdHJ1Y3Qg
Y2NmX3ByaXZhdGUgKmNjZjsNCj4gKwlzdHJ1Y3QgcmVzb3VyY2UgKnI7DQo+ICsJY29uc3Qgc3Ry
dWN0IG9mX2RldmljZV9pZCAqbWF0Y2g7DQo+ICsJaW50IHJldCwgaXJxOw0KPiArDQo+ICsJbWF0
Y2ggPSBvZl9tYXRjaF9kZXZpY2UoY2NmX21hdGNoZXMsICZwZGV2LT5kZXYpOw0KPiArCWlmIChX
QVJOX09OKCFtYXRjaCkpDQo+ICsJCXJldHVybiAtRU5PREVWOw0KPiArDQo+ICsJY2NmID0gZGV2
bV9remFsbG9jKCZwZGV2LT5kZXYsIHNpemVvZigqY2NmKSwgR0ZQX0tFUk5FTCk7DQo+ICsJaWYg
KCFjY2YpDQo+ICsJCXJldHVybiAtRU5PTUVNOw0KPiArDQo+ICsJciA9IHBsYXRmb3JtX2dldF9y
ZXNvdXJjZShwZGV2LCBJT1JFU09VUkNFX01FTSwgMCk7DQo+ICsJaWYgKCFyKSB7DQo+ICsJCWRl
dl9lcnIoJnBkZXYtPmRldiwgIiVzOiBubyBtZW0gcmVzb3VyY2VcbiIsIF9fZnVuY19fKTsNCj4g
KwkJcmV0dXJuIC1FTlhJTzsNCj4gKwl9DQo+ICsNCj4gKwljY2YtPnJlZ3MgPSBkZXZtX2lvcmVt
YXBfcmVzb3VyY2UoJnBkZXYtPmRldiwgcik7DQo+ICsJaWYgKElTX0VSUihjY2YtPnJlZ3MpKSB7
DQo+ICsJCWRldl9lcnIoJnBkZXYtPmRldiwgIiVzOiBjYW4ndCBtYXAgbWVtIHJlc291cmNlXG4i
LCBfX2Z1bmNfXyk7DQo+ICsJCXJldHVybiBQVFJfRVJSKGNjZi0+cmVncyk7DQo+ICsJfQ0KPiAr
DQo+ICsJY2NmLT5kZXYgPSAmcGRldi0+ZGV2Ow0KPiArCWNjZi0+aW5mbyA9IG1hdGNoLT5kYXRh
Ow0KPiArCWNjZi0+ZXJyX3JlZ3MgPSBjY2YtPnJlZ3MgKyBjY2YtPmluZm8tPmVycl9yZWdfb2Zm
czsNCj4gKw0KPiArCWRldl9zZXRfZHJ2ZGF0YSgmcGRldi0+ZGV2LCBjY2YpOw0KPiArDQo+ICsJ
aXJxID0gcGxhdGZvcm1fZ2V0X2lycShwZGV2LCAwKTsNCj4gKwlpZiAoIWlycSkgew0KPiArCQlk
ZXZfZXJyKCZwZGV2LT5kZXYsICIlczogbm8gaXJxXG4iLCBfX2Z1bmNfXyk7DQo+ICsJCXJldHVy
biAtRU5YSU87DQo+ICsJfQ0KPiArDQo+ICsJcmV0ID0gZGV2bV9yZXF1ZXN0X2lycSgmcGRldi0+
ZGV2LCBpcnEsIGNjZl9pcnEsIDAsIHBkZXYtPm5hbWUsIGNjZik7DQo+ICsJaWYgKHJldCkgew0K
PiArCQlkZXZfZXJyKCZwZGV2LT5kZXYsICIlczogY2FuJ3QgcmVxdWVzdCBpcnFcbiIsIF9fZnVu
Y19fKTsNCj4gKwkJcmV0dXJuIHJldDsNCj4gKwl9DQo+ICsNCj4gKwlzd2l0Y2ggKGNjZi0+aW5m
by0+dmVyc2lvbikgew0KPiArCWNhc2UgQ0NGMToNCj4gKwkJLyogT24gQ0NGMSB0aGlzIHJlZ2lz
dGVyIGVuYWJsZXMgcmF0aGVyIHRoYW4gZGlzYWJsZXMuICovDQo+ICsJCWlvd3JpdGUzMmJlKEVS
UkRFVF9MQUUgfCBFUlJERVRfQ1YsICZjY2YtPmVycl9yZWdzLT5lcnJkaXMpOw0KPiArCQlicmVh
azsNCj4gKw0KPiArCWNhc2UgQ0NGMjoNCj4gKwkJaW93cml0ZTMyYmUoMCwgJmNjZi0+ZXJyX3Jl
Z3MtPmVycmRpcyk7DQo+ICsJCWlvd3JpdGUzMmJlKEVSUkRFVF9MQUUgfCBFUlJERVRfQ1YsICZj
Y2YtPmVycl9yZWdzLT5lcnJpbnRlbik7DQo+ICsJCWJyZWFrOw0KPiArCX0NCj4gKw0KPiArCXJl
dHVybiAwOw0KPiArfQ0KPiArDQo+ICtzdGF0aWMgaW50IGNjZl9yZW1vdmUoc3RydWN0IHBsYXRm
b3JtX2RldmljZSAqcGRldikgew0KPiArCXN0cnVjdCBjY2ZfcHJpdmF0ZSAqY2NmID0gZGV2X2dl
dF9kcnZkYXRhKCZwZGV2LT5kZXYpOw0KPiArDQo+ICsJc3dpdGNoIChjY2YtPmluZm8tPnZlcnNp
b24pIHsNCj4gKwljYXNlIENDRjE6DQo+ICsJCWlvd3JpdGUzMmJlKDAsICZjY2YtPmVycl9yZWdz
LT5lcnJkaXMpOw0KPiArCQlicmVhazsNCj4gKw0KPiArCWNhc2UgQ0NGMjoNCj4gKwkJaW93cml0
ZTMyYmUoMCwgJmNjZi0+ZXJyX3JlZ3MtPmVycmludGVuKTsNCg0KRG8geW91IHRoaW5rIGl0IGlz
IHNhbWUgdG8gZGlzYWJsZSBkZXRlY3Rpb24gYml0cyBpbiBjY2YtPmVycl9yZWdzLT5lcnJkaXM/
DQoNClRoYW5rcw0KLUJoYXJhdA0KDQo+ICsJCWJyZWFrOw0KPiArCX0NCj4gKw0KPiArCXJldHVy
biAwOw0KPiArfQ0KPiArDQo+ICtzdGF0aWMgc3RydWN0IHBsYXRmb3JtX2RyaXZlciBjY2ZfZHJp
dmVyID0gew0KPiArCS5kcml2ZXIgPSB7DQo+ICsJCS5uYW1lID0gS0JVSUxEX01PRE5BTUUsDQo+
ICsJCS5vd25lciA9IFRISVNfTU9EVUxFLA0KPiArCQkub2ZfbWF0Y2hfdGFibGUgPSBjY2ZfbWF0
Y2hlcywNCj4gKwl9LA0KPiArCS5wcm9iZSA9IGNjZl9wcm9iZSwNCj4gKwkucmVtb3ZlID0gY2Nm
X3JlbW92ZSwNCj4gK307DQo+ICsNCj4gK21vZHVsZV9wbGF0Zm9ybV9kcml2ZXIoY2NmX2RyaXZl
cik7DQo+ICsNCj4gK01PRFVMRV9MSUNFTlNFKCJHUEwiKTsNCj4gK01PRFVMRV9BVVRIT1IoIkZy
ZWVzY2FsZSBTZW1pY29uZHVjdG9yIik7IE1PRFVMRV9ERVNDUklQVElPTigiRnJlZXNjYWxlDQo+
ICtDb3JlTmV0IENvaGVyZW5jeSBGYWJyaWMgZXJyb3IgcmVwb3J0aW5nIik7DQo+IC0tDQo+IDEu
OS4xDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
IExpbnV4cHBjLWRldiBtYWlsaW5nIGxpc3QNCj4gTGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5v
cmcNCj4gaHR0cHM6Ly9saXN0cy5vemxhYnMub3JnL2xpc3RpbmZvL2xpbnV4cHBjLWRldg0K
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/powernv: Enable POWER8 doorbell IPIs
From: Michael Ellerman @ 2014-06-04 8:03 UTC (permalink / raw)
To: Michael Neuling
Cc: Preeti U Murthy, linuxppc-dev, Anton Blanchard, Paul Mackerras
In-Reply-To: <1401692223-28337-2-git-send-email-mikey@neuling.org>
On Mon, 2014-06-02 at 16:57 +1000, Michael Neuling wrote:
> This patch enables POWER8 doorbell IPIs on powernv.
>
> Since doorbells can only IPI within a core, we test to see when we can use
> doorbells and if not we fall back to XICS. This also enables hypervisor
> doorbells to wakeup us up from nap/sleep via the LPCR PECEDH bit.
>
> Based on tests by Anton, the best case IPI latency between two threads dropped
> from 894ns to 512ns.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> arch/powerpc/kernel/cpu_setup_power.S | 2 ++
> arch/powerpc/platforms/powernv/smp.c | 6 ++++++
> arch/powerpc/sysdev/xics/icp-native.c | 9 ++++++++-
> 3 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/cpu_setup_power.S b/arch/powerpc/kernel/cpu_setup_power.S
> index 1557e7c..4673353 100644
> --- a/arch/powerpc/kernel/cpu_setup_power.S
> +++ b/arch/powerpc/kernel/cpu_setup_power.S
> @@ -56,6 +56,7 @@ _GLOBAL(__setup_cpu_power8)
> li r0,0
> mtspr SPRN_LPID,r0
> mfspr r3,SPRN_LPCR
> + ori r3, r3, LPCR_PECEDH
> bl __init_LPCR
> bl __init_HFSCR
> bl __init_tlb_power8
> @@ -74,6 +75,7 @@ _GLOBAL(__restore_cpu_power8)
> li r0,0
> mtspr SPRN_LPID,r0
> mfspr r3,SPRN_LPCR
> + ori r3, r3, LPCR_PECEDH
> bl __init_LPCR
> bl __init_HFSCR
> bl __init_tlb_power8
> diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
> index 0062a43..5fcfcf4 100644
> --- a/arch/powerpc/platforms/powernv/smp.c
> +++ b/arch/powerpc/platforms/powernv/smp.c
> @@ -32,6 +32,7 @@
> #include <asm/opal.h>
> #include <asm/runlatch.h>
> #include <asm/code-patching.h>
> +#include <asm/dbell.h>
>
> #include "powernv.h"
>
> @@ -46,6 +47,11 @@ static void pnv_smp_setup_cpu(int cpu)
> {
> if (cpu != boot_cpuid)
> xics_setup_cpu();
> +
> +#ifdef CONFIG_PPC_DOORBELL
> + if (cpu_has_feature(CPU_FTR_DBELL))
> + doorbell_setup_this_cpu();
> +#endif
> }
Where does CONFIG_PPC_DOORBELL get set?
It looks like the only place you can be getting it is from CONFIG_PPC_PSERIES.
If you build a POWERNV only kernel it will get disabled, which I don't think is
what we want.
I think we should select it for POWERNV as well as PSERIES. That would mean
it's always enabled for any build of the files you touch, so you shouldn't need
the #ifdefs.
cheers
^ permalink raw reply
* [PATCH v2 2/2] powerpc/powernv: Set memory_block_size_bytes to 256MB
From: Anton Blanchard @ 2014-06-04 7:52 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20140604175047.35b116b3@kryten>
powerpc sets a low SECTION_SIZE_BITS to accomodate small pseries
boxes. We default to 16MB memory blocks, and boxes with a lot
of memory end up with enormous numbers of sysfs memory nodes.
Set a more reasonable default for powernv of 256MB.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
arch/powerpc/platforms/powernv/setup.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index 865aab4..8c16a5f 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -244,6 +244,13 @@ static void pnv_kexec_cpu_down(int crash_shutdown, int secondary)
}
#endif /* CONFIG_KEXEC */
+#ifdef CONFIG_MEMORY_HOTPLUG_SPARSE
+static unsigned long pnv_memory_block_size(void)
+{
+ return 256UL * 1024 * 1024;
+}
+#endif
+
static void __init pnv_setup_machdep_opal(void)
{
ppc_md.get_boot_time = opal_get_boot_time;
@@ -326,4 +333,7 @@ define_machine(powernv) {
#ifdef CONFIG_KEXEC
.kexec_cpu_down = pnv_kexec_cpu_down,
#endif
+#ifdef CONFIG_MEMORY_HOTPLUG_SPARSE
+ .memory_block_size = pnv_memory_block_size,
+#endif
};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] powerpc: Allow ppc_md platform hook to override memory_block_size_bytes
From: Anton Blanchard @ 2014-06-04 7:50 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
The pseries platform code unconditionally overrides
memory_block_size_bytes regardless of the running platform.
Create a ppc_md hook that so each platform can choose to
do what it wants.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
arch/powerpc/include/asm/machdep.h | 3 +++
arch/powerpc/kernel/setup_64.c | 10 ++++++++++
arch/powerpc/platforms/pseries/hotplug-memory.c | 17 +++--------------
arch/powerpc/platforms/pseries/pseries.h | 2 ++
arch/powerpc/platforms/pseries/setup.c | 3 +++
5 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index 374abc2..f92b0b5 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -98,6 +98,9 @@ struct machdep_calls {
void (*iommu_save)(void);
void (*iommu_restore)(void);
#endif
+#ifdef CONFIG_MEMORY_HOTPLUG_SPARSE
+ unsigned long (*memory_block_size)(void);
+#endif
#endif /* CONFIG_PPC64 */
void (*pci_dma_dev_setup)(struct pci_dev *dev);
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 90b532a..ee082d7 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -36,6 +36,7 @@
#include <linux/lockdep.h>
#include <linux/memblock.h>
#include <linux/hugetlb.h>
+#include <linux/memory.h>
#include <asm/io.h>
#include <asm/kdump.h>
@@ -780,6 +781,15 @@ void __init setup_per_cpu_areas(void)
}
#endif
+#ifdef CONFIG_MEMORY_HOTPLUG_SPARSE
+unsigned long memory_block_size_bytes(void)
+{
+ if (ppc_md.memory_block_size)
+ return ppc_md.memory_block_size();
+
+ return MIN_MEMORY_BLOCK_SIZE;
+}
+#endif
#if defined(CONFIG_PPC_INDIRECT_PIO) || defined(CONFIG_PPC_INDIRECT_MMIO)
struct ppc_pci_io ppc_pci_io;
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 7f75c94..7995135 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -21,7 +21,7 @@
#include <asm/prom.h>
#include <asm/sparsemem.h>
-static unsigned long get_memblock_size(void)
+unsigned long pseries_memory_block_size(void)
{
struct device_node *np;
unsigned int memblock_size = MIN_MEMORY_BLOCK_SIZE;
@@ -64,17 +64,6 @@ static unsigned long get_memblock_size(void)
return memblock_size;
}
-/* WARNING: This is going to override the generic definition whenever
- * pseries is built-in regardless of what platform is active at boot
- * time. This is fine for now as this is the only "option" and it
- * should work everywhere. If not, we'll have to turn this into a
- * ppc_md. callback
- */
-unsigned long memory_block_size_bytes(void)
-{
- return get_memblock_size();
-}
-
#ifdef CONFIG_MEMORY_HOTREMOVE
static int pseries_remove_memory(u64 start, u64 size)
{
@@ -105,7 +94,7 @@ static int pseries_remove_memblock(unsigned long base, unsigned int memblock_siz
if (!pfn_valid(start_pfn))
goto out;
- block_sz = memory_block_size_bytes();
+ block_sz = pseries_memory_block_size();
sections_per_block = block_sz / MIN_MEMORY_BLOCK_SIZE;
nid = memory_add_physaddr_to_nid(base);
@@ -201,7 +190,7 @@ static int pseries_update_drconf_memory(struct of_prop_reconfig *pr)
u32 *p;
int i, rc = -EINVAL;
- memblock_size = get_memblock_size();
+ memblock_size = pseries_memory_block_size();
if (!memblock_size)
return -EINVAL;
diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h
index 9921953..361add6 100644
--- a/arch/powerpc/platforms/pseries/pseries.h
+++ b/arch/powerpc/platforms/pseries/pseries.h
@@ -64,4 +64,6 @@ extern int dlpar_detach_node(struct device_node *);
struct pci_host_bridge;
int pseries_root_bridge_prepare(struct pci_host_bridge *bridge);
+unsigned long pseries_memory_block_size(void);
+
#endif /* _PSERIES_PSERIES_H */
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 215c3c2..adc21a0 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -810,4 +810,7 @@ define_machine(pseries) {
#ifdef CONFIG_KEXEC
.machine_kexec = pSeries_machine_kexec,
#endif
+#ifdef CONFIG_MEMORY_HOTPLUG_SPARSE
+ .memory_block_size = pseries_memory_block_size,
+#endif
};
--
1.9.1
^ permalink raw reply related
* [PATCH] powerpc/powernv: Fix killed EEH event
From: Gavin Shan @ 2014-06-04 7:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
On PowerNV platform, EEH errors are reported by IO accessors or poller
driven by interrupt. After the PE is isolated, we won't produce EEH
event for the PE. The current implementation has possibility of EEH
event lost in this way:
The interrupt handler queues one "special" event, which drives the poller.
EEH thread doesn't pick the special event yet. IO accessors kicks in, the
frozen PE is marked as "isolated" and EEH event is queued to the list.
EEH thread runs because of special event and purge all existing EEH events.
However, we never produce an other EEH event for the frozen PE. Eventually,
the PE is marked as "isolated" and we don't have EEH event to recover it.
The patch fixes the issue to keep EEH events for PEs that have been
marked as "isolated" with the help of additional "force" help to
eeh_remove_event().
Reported-by: Rolf Brudeseth <rolfb@us.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh_event.h | 2 +-
arch/powerpc/kernel/eeh_driver.c | 4 ++--
arch/powerpc/kernel/eeh_event.c | 21 +++++++++++++++------
arch/powerpc/platforms/powernv/eeh-ioda.c | 2 +-
4 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh_event.h b/arch/powerpc/include/asm/eeh_event.h
index 89d5670..1e551a2 100644
--- a/arch/powerpc/include/asm/eeh_event.h
+++ b/arch/powerpc/include/asm/eeh_event.h
@@ -33,7 +33,7 @@ struct eeh_event {
int eeh_event_init(void);
int eeh_send_failure_event(struct eeh_pe *pe);
-void eeh_remove_event(struct eeh_pe *pe);
+void eeh_remove_event(struct eeh_pe *pe, bool force);
void eeh_handle_event(struct eeh_pe *pe);
#endif /* __KERNEL__ */
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index 8bb40e7..420da61 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -770,7 +770,7 @@ static void eeh_handle_special_event(void)
eeh_serialize_lock(&flags);
/* Purge all events */
- eeh_remove_event(NULL);
+ eeh_remove_event(NULL, true);
list_for_each_entry(hose, &hose_list, list_node) {
phb_pe = eeh_phb_pe_get(hose);
@@ -789,7 +789,7 @@ static void eeh_handle_special_event(void)
eeh_serialize_lock(&flags);
/* Purge all events of the PHB */
- eeh_remove_event(pe);
+ eeh_remove_event(pe, true);
if (rc == EEH_NEXT_ERR_DEAD_PHB)
eeh_pe_state_mark(pe, EEH_PE_ISOLATED);
diff --git a/arch/powerpc/kernel/eeh_event.c b/arch/powerpc/kernel/eeh_event.c
index 72d748b..4eefb6e 100644
--- a/arch/powerpc/kernel/eeh_event.c
+++ b/arch/powerpc/kernel/eeh_event.c
@@ -152,24 +152,33 @@ int eeh_send_failure_event(struct eeh_pe *pe)
/**
* eeh_remove_event - Remove EEH event from the queue
* @pe: Event binding to the PE
+ * @force: Event will be removed unconditionally
*
* On PowerNV platform, we might have subsequent coming events
* is part of the former one. For that case, those subsequent
* coming events are totally duplicated and unnecessary, thus
* they should be removed.
*/
-void eeh_remove_event(struct eeh_pe *pe)
+void eeh_remove_event(struct eeh_pe *pe, bool force)
{
unsigned long flags;
struct eeh_event *event, *tmp;
+ /*
+ * If we have NULL PE passed in, we have dead IOC
+ * or we're sure we can report all existing errors
+ * by the caller.
+ *
+ * With "force", the event with associated PE that
+ * have been isolated, the event won't be removed
+ * to avoid event lost.
+ */
spin_lock_irqsave(&eeh_eventlist_lock, flags);
list_for_each_entry_safe(event, tmp, &eeh_eventlist, list) {
- /*
- * If we don't have valid PE passed in, that means
- * we already have event corresponding to dead IOC
- * and all events should be purged.
- */
+ if (!force && event->pe &&
+ (event->pe->state & EEH_PE_ISOLATED))
+ continue;
+
if (!pe) {
list_del(&event->list);
kfree(event);
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index cab3e62..f1f089d 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -797,7 +797,7 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
* And we should keep the cached OPAL notifier event sychronized
* between the kernel and firmware.
*/
- eeh_remove_event(NULL);
+ eeh_remove_event(NULL, false);
opal_notifier_update_evt(OPAL_EVENT_PCI_ERROR, 0x0ul);
list_for_each_entry(hose, &hose_list, list_node) {
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 1/1] powerpc: correct DSCR during TM context switch
From: Michael Ellerman @ 2014-06-04 7:31 UTC (permalink / raw)
To: Sam Bobroff; +Cc: aik, mikey, benh, linuxppc-dev, khandual
In-Reply-To: <f1ddc3bc4b970a480367a45cdca51e879cb14df0.1401852531.git.sam.bobroff@au1.ibm.com>
Hi Sam,
Comments inline ..
On Wed, 2014-06-04 at 13:33 +1000, Sam Bobroff wrote:
> Correct the DSCR SPR becoming temporarily corrupted when a task is
> context switched when within a transaction. It is corrected when
> the transaction is aborted (which will happen after a context switch)
> but if the task has suspended (TSUSPEND) the transaction the incorrect
> value can be seen.
I don't quite follow this description. How is it corrected when the transaction
is aborted, and when does that usually happen? If that happens the task can't
ever see the corrupted value?
To hit the suspended case, the task starts a transaction, suspends it, is then
context switched out and back in, and at that point it can see the wrong value?
> The problem is caused by saving a thread's DSCR after it has already
> been reverted to the CPU's default value:
>
> __switch_to() calls __switch_to_tm()
> which calls tm_reclaim_task()
> which calls tm_reclaim_thread()
> which calls tm_reclaim() where the DSCR is reset
Where the DSCR is set to DSCR_DEFAULT ? Or now PACA_DSCR since your previous
patches?
Could we instead fix the bug there by reverting to the thread's DSCR value?
> __switch_to() calls _switch
> _switch() saves the DSCR to thread.dscr
>
> The fix is to treat the DSCR similarly to the TAR and save it early
> in __switch_to().
>
> The program below will expose the problem:
Can you drop this in tools/testing/selftests/powerpc/tm ?
You'll need to create that directory, you can ape the Makefile from the pmu
directory, it should be fairly obvious. See the pmu tests for how to integrate
with the test harness etc., or bug me if it's not straight forward.
> diff --git a/arch/powerpc/include/asm/switch_to.h b/arch/powerpc/include/asm/switch_to.h
> index 2737f46..3efd0e5 100644
> --- a/arch/powerpc/include/asm/switch_to.h
> +++ b/arch/powerpc/include/asm/switch_to.h
> @@ -16,13 +16,15 @@ struct thread_struct;
> extern struct task_struct *_switch(struct thread_struct *prev,
> struct thread_struct *next);
> #ifdef CONFIG_PPC_BOOK3S_64
> -static inline void save_tar(struct thread_struct *prev)
> +static inline void save_early_sprs(struct thread_struct *prev)
> {
> if (cpu_has_feature(CPU_FTR_ARCH_207S))
> prev->tar = mfspr(SPRN_TAR);
> + if (cpu_has_feature(CPU_FTR_DSCR))
> + prev->dscr = mfspr(SPRN_DSCR);
> }
Are we going to end up saving more SPRs in this code? What makes the TAR & DSCR
special vs everything else?
The nice thing about doing this in asm is it's nop'ed out for cpus that don't
have the DSCR. What does the generated code for this look like?
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index 662c6dd..a107f4a 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -432,12 +432,6 @@ BEGIN_FTR_SECTION
> std r24,THREAD_VRSAVE(r3)
> END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
> #endif /* CONFIG_ALTIVEC */
> -#ifdef CONFIG_PPC64
> -BEGIN_FTR_SECTION
> - mfspr r25,SPRN_DSCR
> - std r25,THREAD_DSCR(r3)
> -END_FTR_SECTION_IFSET(CPU_FTR_DSCR)
> -#endif
> and. r0,r0,r22
> beq+ 1f
> andc r22,r22,r0
cheers
^ permalink raw reply
* [PATCH] powerpc/powernv: Fix endian issues in memory error handling code
From: Anton Blanchard @ 2014-06-04 4:48 UTC (permalink / raw)
To: benh, paulus, mahesh; +Cc: linuxppc-dev
struct OpalMemoryErrorData is passed to us from firmware, so we
have to byteswap it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Having enums in a firmware interface concerns me, but that cleanup
can be in a subsequent patch.
Mahesh, could you give this a test to see if it works?
Index: b/arch/powerpc/include/asm/opal.h
===================================================================
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -482,7 +482,7 @@ enum OpalMemErr_DynErrType {
struct OpalMemoryErrorData {
enum OpalMemErr_Version version:8; /* 0x00 */
enum OpalMemErrType type:8; /* 0x01 */
- uint16_t flags; /* 0x02 */
+ __be16 flags; /* 0x02 */
uint8_t reserved_1[4]; /* 0x04 */
union {
@@ -490,15 +490,15 @@ struct OpalMemoryErrorData {
struct {
enum OpalMemErr_ResilErrType resil_err_type:8;
uint8_t reserved_1[7];
- uint64_t physical_address_start;
- uint64_t physical_address_end;
+ __be64 physical_address_start;
+ __be64 physical_address_end;
} resilience;
/* Dynamic memory deallocation error info */
struct {
enum OpalMemErr_DynErrType dyn_err_type:8;
uint8_t reserved_1[7];
- uint64_t physical_address_start;
- uint64_t physical_address_end;
+ __be64 physical_address_start;
+ __be64 physical_address_end;
} dyn_dealloc;
} u;
};
Index: b/arch/powerpc/platforms/powernv/opal-memory-errors.c
===================================================================
--- a/arch/powerpc/platforms/powernv/opal-memory-errors.c
+++ b/arch/powerpc/platforms/powernv/opal-memory-errors.c
@@ -47,12 +47,12 @@ static void handle_memory_error_event(st
__func__, merr_evt->type);
switch (merr_evt->type) {
case OPAL_MEM_ERR_TYPE_RESILIENCE:
- paddr_start = merr_evt->u.resilience.physical_address_start;
- paddr_end = merr_evt->u.resilience.physical_address_end;
+ paddr_start = be64_to_cpu(merr_evt->u.resilience.physical_address_start);
+ paddr_end = be64_to_cpu(merr_evt->u.resilience.physical_address_end);
break;
case OPAL_MEM_ERR_TYPE_DYN_DALLOC:
- paddr_start = merr_evt->u.dyn_dealloc.physical_address_start;
- paddr_end = merr_evt->u.dyn_dealloc.physical_address_end;
+ paddr_start = be64_to_cpu(merr_evt->u.dyn_dealloc.physical_address_start);
+ paddr_end = be64_to_cpu(merr_evt->u.dyn_dealloc.physical_address_end);
break;
default:
return;
^ permalink raw reply
* Re: [PATCH] KVM: PPC: BOOK3S: PR: Fix PURR and SPURR emulation
From: Paul Mackerras @ 2014-06-04 4:15 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, agraf, kvm-ppc, kvm
In-Reply-To: <1401797771-25606-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Tue, Jun 03, 2014 at 05:46:11PM +0530, Aneesh Kumar K.V wrote:
> We use time base for PURR and SPURR emulation with PR KVM since we
> are emulating a single threaded core. When using time base
> we need to make sure that we don't accumulate time spent in the host
> in PURR and SPURR value.
Mostly looks good except for this...
> @@ -170,6 +175,11 @@ void kvmppc_copy_from_svcpu(struct kvm_vcpu *vcpu,
>
> out:
> preempt_enable();
> + /*
> + * Update purr and spurr using time base
> + */
> + vcpu->arch.purr += get_tb() - vcpu->arch.entry_tb;
> + vcpu->arch.spurr += get_tb() - vcpu->arch.entry_tb;
You need to do those updates before the "out:" label. Otherwise if
this function gets called with !svcpu->in_use (which can happen if
CONFIG_PREEMPT is enabled) we would do these updates a second time for
one guest exit. The thing is that kvmppc_copy_from_svcpu() can get
called from kvmppc_core_vcpu_put_pr() if the vcpu task gets preempted
on the way out from the guest before we get to the regular call of
kvmppc_copy_from_svcpu(). It would then get called again when the
task gets to run, but this time it does nothing because svcpu->in_use
is false.
Paul.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox