* Re: [PATCH v2] On ppc64le we HAVE_RELIABLE_STACKTRACE
From: Segher Boessenkool @ 2018-03-05 17:09 UTC (permalink / raw)
To: Torsten Duwe
Cc: Michael Ellerman, Jiri Kosina, linux-kernel, Nicholas Piggin,
Josh Poimboeuf, live-patching, linuxppc-dev
In-Reply-To: <20180305164928.GA17953@lst.de>
On Mon, Mar 05, 2018 at 05:49:28PM +0100, Torsten Duwe wrote:
> The "Power Architecture 64-Bit ELF V2 ABI" says in section 2.3.2.3:
>
> [...] There are several rules that must be adhered to in order to ensure
> reliable and consistent call chain backtracing:
>
> * Before a function calls any other function, it shall establish its
> own stack frame, whose size shall be a multiple of 16 bytes.
>
> – In instances where a function’s prologue creates a stack frame, the
> back-chain word of the stack frame shall be updated atomically with
> the value of the stack pointer (r1) when a back chain is implemented.
> (This must be supported as default by all ELF V2 ABI-compliant
> environments.)
> [...]
> – The function shall save the link register that contains its return
> address in the LR save doubleword of its caller’s stack frame before
> calling another function.
All of this is also true for the other PowerPC ABIs, fwiw (both 32-bit
and 64-bit; the offset of the LR save slot isn't the same in all ABIs).
Segher
^ permalink raw reply
* [PATCH v2] On ppc64le we HAVE_RELIABLE_STACKTRACE
From: Torsten Duwe @ 2018-03-05 16:49 UTC (permalink / raw)
To: Michael Ellerman
Cc: Jiri Kosina, Josh Poimboeuf, linuxppc-dev, linux-kernel,
Nicholas Piggin, live-patching
The "Power Architecture 64-Bit ELF V2 ABI" says in section 2.3.2.3:
[...] There are several rules that must be adhered to in order to ensure
reliable and consistent call chain backtracing:
* Before a function calls any other function, it shall establish its
own stack frame, whose size shall be a multiple of 16 bytes.
– In instances where a function’s prologue creates a stack frame, the
back-chain word of the stack frame shall be updated atomically with
the value of the stack pointer (r1) when a back chain is implemented.
(This must be supported as default by all ELF V2 ABI-compliant
environments.)
[...]
– The function shall save the link register that contains its return
address in the LR save doubleword of its caller’s stack frame before
calling another function.
To me this sounds like the equivalent of HAVE_RELIABLE_STACKTRACE.
This patch may be unneccessarily limited to ppc64le, but OTOH the only
user of this flag so far is livepatching, which is only implemented on
PPCs with 64-LE, a.k.a. ELF ABI v2.
This change also implements save_stack_trace_tsk_reliable() for ppc64
that checks for the above conditions, where possible.
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
v2:
* implemented save_stack_trace_tsk_reliable(), with a bunch of sanity
checks. The test for a kernel code pointer is much nicer now, and
the exit condition is exact (when compared to last week's follow-up)
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 73ce5dd07642..9f49913e19e3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -220,6 +220,7 @@ config PPC
select HAVE_PERF_USER_STACK_DUMP
select HAVE_RCU_TABLE_FREE if SMP
select HAVE_REGS_AND_STACK_ACCESS_API
+ select HAVE_RELIABLE_STACKTRACE if PPC64 && CPU_LITTLE_ENDIAN
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_VIRT_CPU_ACCOUNTING
select HAVE_IRQ_TIME_ACCOUNTING
diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
index d534ed901538..e14c2dfd5311 100644
--- a/arch/powerpc/kernel/stacktrace.c
+++ b/arch/powerpc/kernel/stacktrace.c
@@ -11,8 +11,11 @@
*/
#include <linux/export.h>
+#include <linux/kallsyms.h>
+#include <linux/module.h>
#include <linux/sched.h>
#include <linux/sched/debug.h>
+#include <linux/sched/task_stack.h>
#include <linux/stacktrace.h>
#include <asm/ptrace.h>
#include <asm/processor.h>
@@ -76,3 +79,77 @@ save_stack_trace_regs(struct pt_regs *regs, struct stack_trace *trace)
save_context_stack(trace, regs->gpr[1], current, 0);
}
EXPORT_SYMBOL_GPL(save_stack_trace_regs);
+
+#ifdef CONFIG_HAVE_RELIABLE_STACKTRACE
+int
+save_stack_trace_tsk_reliable(struct task_struct *tsk,
+ struct stack_trace *trace)
+{
+ unsigned long sp;
+ unsigned long stack_page = (unsigned long)task_stack_page(tsk);
+
+ /* The last frame (unwinding first) may not yet have saved
+ * its LR onto the stack.
+ */
+ int firstframe = 1;
+
+ if (tsk == current)
+ sp = current_stack_pointer();
+ else
+ sp = tsk->thread.ksp;
+
+ if (sp < stack_page + sizeof(struct thread_struct)
+ || sp > stack_page + THREAD_SIZE - STACK_FRAME_OVERHEAD)
+ return 1;
+
+ for (;;) {
+ unsigned long *stack = (unsigned long *) sp;
+ unsigned long newsp, ip;
+
+ /* sanity check: ABI requires SP to be aligned 16 bytes. */
+ if (sp & 0xF)
+ return 1;
+
+ newsp = stack[0];
+ /* Stack grows downwards; unwinder may only go up. */
+ if (newsp <= sp)
+ return 1;
+
+ if (newsp >= stack_page + THREAD_SIZE)
+ return 1; /* invalid backlink, too far up. */
+
+ /* Examine the saved LR: it must point into kernel code. */
+ ip = stack[STACK_FRAME_LR_SAVE];
+ if (!firstframe) {
+ if (!func_ptr_is_kernel_text((void *)ip)) {
+#ifdef CONFIG_MODULES
+ struct module *mod = __module_text_address(ip);
+
+ if (!mod)
+#endif
+ return 1;
+ }
+ }
+ firstframe = 0;
+
+ if (!trace->skip)
+ trace->entries[trace->nr_entries++] = ip;
+ else
+ trace->skip--;
+
+ /* SP value loaded on kernel entry, see "PACAKSAVE(r13)" in
+ * _switch() and system_call_common()
+ */
+ if (newsp == stack_page + THREAD_SIZE - /* SWITCH_FRAME_SIZE */
+ (STACK_FRAME_OVERHEAD + sizeof(struct pt_regs)))
+ break;
+
+ if (trace->nr_entries >= trace->max_entries)
+ return -E2BIG;
+
+ sp = newsp;
+ }
+ return 0;
+}
+EXPORT_SYMBOL_GPL(save_stack_trace_tsk_reliable);
+#endif /* CONFIG_HAVE_RELIABLE_STACKTRACE */
^ permalink raw reply related
* RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
From: Nipun Gupta @ 2018-03-05 15:54 UTC (permalink / raw)
To: Robin Murphy, will.deacon@arm.com, mark.rutland@arm.com,
catalin.marinas@arm.com
Cc: iommu@lists.linux-foundation.org, robh+dt@kernel.org, hch@lst.de,
m.szyprowski@samsung.com, gregkh@linuxfoundation.org,
joro@8bytes.org, Leo Li, shawnguo@kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, Bharat Bhushan, stuyoder@gmail.com,
Laurentiu Tudor
In-Reply-To: <f382e92a-8ab5-7c93-1f39-fe6797e5c876@arm.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iaW4gTXVycGh5IFtt
YWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMDUsIDIw
MTggMjE6MDcNCj4gVG86IE5pcHVuIEd1cHRhIDxuaXB1bi5ndXB0YUBueHAuY29tPjsgd2lsbC5k
ZWFjb25AYXJtLmNvbTsNCj4gbWFyay5ydXRsYW5kQGFybS5jb207IGNhdGFsaW4ubWFyaW5hc0Bh
cm0uY29tDQo+IENjOiBpb21tdUBsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgcm9iaCtkdEBr
ZXJuZWwub3JnOyBoY2hAbHN0LmRlOw0KPiBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207IGdyZWdr
aEBsaW51eGZvdW5kYXRpb24ub3JnOyBqb3JvQDhieXRlcy5vcmc7DQo+IExlbyBMaSA8bGVveWFu
Zy5saUBueHAuY29tPjsgc2hhd25ndW9Aa2VybmVsLm9yZzsgbGludXgtDQo+IGtlcm5lbEB2Z2Vy
Lmtlcm5lbC5vcmc7IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eC1hcm0tDQo+IGtl
cm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsg
QmhhcmF0IEJodXNoYW4NCj4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+OyBzdHV5b2RlckBnbWFp
bC5jb207IExhdXJlbnRpdSBUdWRvcg0KPiA8bGF1cmVudGl1LnR1ZG9yQG54cC5jb20+DQo+IFN1
YmplY3Q6IFJlOiBbUEFUQ0ggMS82XSBEb2NzOiBkdDogYWRkIGZzbC1tYyBpb21tdS1wYXJlbnQg
ZGV2aWNlLXRyZWUgYmluZGluZw0KPiANCj4gT24gMDUvMDMvMTggMTU6MDAsIE5pcHVuIEd1cHRh
IHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g
RnJvbTogUm9iaW4gTXVycGh5IFttYWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+ID4+IFNl
bnQ6IE1vbmRheSwgTWFyY2ggMDUsIDIwMTggMjA6MjMNCj4gPj4gVG86IE5pcHVuIEd1cHRhIDxu
aXB1bi5ndXB0YUBueHAuY29tPjsgd2lsbC5kZWFjb25AYXJtLmNvbTsNCj4gPj4gbWFyay5ydXRs
YW5kQGFybS5jb207IGNhdGFsaW4ubWFyaW5hc0Bhcm0uY29tDQo+ID4+IENjOiBpb21tdUBsaXN0
cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgcm9iaCtkdEBrZXJuZWwub3JnOyBoY2hAbHN0LmRlOw0K
PiA+PiBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207IGdyZWdraEBsaW51eGZvdW5kYXRpb24ub3Jn
Ow0KPiBqb3JvQDhieXRlcy5vcmc7DQo+ID4+IExlbyBMaSA8bGVveWFuZy5saUBueHAuY29tPjsg
c2hhd25ndW9Aa2VybmVsLm9yZzsgbGludXgtDQo+ID4+IGtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7
IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eC1hcm0tDQo+ID4+IGtlcm5lbEBsaXN0
cy5pbmZyYWRlYWQub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgQmhhcmF0IEJo
dXNoYW4NCj4gPj4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+OyBzdHV5b2RlckBnbWFpbC5jb207
IExhdXJlbnRpdSBUdWRvcg0KPiA+PiA8bGF1cmVudGl1LnR1ZG9yQG54cC5jb20+DQo+ID4+IFN1
YmplY3Q6IFJlOiBbUEFUQ0ggMS82XSBEb2NzOiBkdDogYWRkIGZzbC1tYyBpb21tdS1wYXJlbnQg
ZGV2aWNlLXRyZWUNCj4gYmluZGluZw0KPiA+Pg0KPiA+PiBPbiAwNS8wMy8xOCAxNDoyOSwgTmlw
dW4gR3VwdGEgd3JvdGU6DQo+ID4+PiBUaGUgZXhpc3RpbmcgSU9NTVUgYmluZGluZ3MgY2Fubm90
IGJlIHVzZWQgdG8gc3BlY2lmeSB0aGUgcmVsYXRpb25zaGlwDQo+ID4+PiBiZXR3ZWVuIGZzbC1t
YyBkZXZpY2VzIGFuZCBJT01NVXMuIFRoaXMgcGF0Y2ggYWRkcyBhIGJpbmRpbmcgZm9yDQo+ID4+
PiBtYXBwaW5nIGZzbC1tYyBkZXZpY2VzIHRvIElPTU1VcywgdXNpbmcgYSBuZXcgaW9tbXUtcGFy
ZW50IHByb3BlcnR5Lg0KPiA+Pg0KPiA+PiBHaXZlbiB0aGF0IGFsbG93aW5nICJtc2ktcGFyZW50
IiBmb3IgI21zaS1jZWxscyA+IDEgaXMgbWVyZWx5IGENCj4gPj4gYmFja3dhcmQtY29tcGF0aWJp
bGl0eSBib2RnZSBmdWxsIG9mIGhhcmQtY29kZWQgYXNzdW1wdGlvbnMsIHdoeSB3b3VsZA0KPiA+
PiB3ZSB3YW50IHRvIGtub3dpbmdseSBpbnRyb2R1Y2UgYSBzaW1pbGFybHkgdW5wbGVhc2FudCBl
cXVpdmFsZW50IGZvcg0KPiA+PiBJT01NVXM/IFdoYXQncyB3cm9uZyB3aXRoICJpb21tdS1tYXAi
Pw0KPiA+DQo+ID4gSGkgUm9iaW4sDQo+ID4NCj4gPiBXaXRoICdtc2ktcGFyZW50JyB0aGUgcHJv
cGVydHkgaXMgZml4ZWQgdXAgdG8gaGF2ZSBtc2ktbWFwLiBJbiB0aGlzIGNhc2UgdGhlcmUgaXMN
Cj4gPiBubyBmaXh1cCByZXF1aXJlZCBhbmQgc2ltcGxlICdpb21tdS1wYXJlbnQnIHByb3BlcnR5
IGNhbiBiZSB1c2VkLCB3aXRoIE1DDQo+IGJ1cw0KPiA+IGl0c2VsZiBwcm92aWRpbmcgdGhlIHN0
cmVhbS1pZCdzIChpbiB0aGUgY29kZSBleGVjdXRpb24gdmlhIEZXKS4NCj4gPg0KPiA+IFdlIGNh
biBhbHNvIHVzZSB0aGUgaW9tbXUtbWFwIHByb3BlcnR5IHNpbWlsYXIgdG8gUENJLCB3aGljaCB3
aWxsIHJlcXVpcmUgdS0NCj4gYm9vdA0KPiA+IGZpeHVwLiBCdXQgdGhlbiBpdCBsZWFkcyB0byBs
aXR0bGUgYml0IGNvbXBsaWNhdGlvbnMgb2YgdS1ib290IC0ga2VybmVsDQo+IGNvbXBhdGliaWxp
dHkuDQo+IA0KPiBXaGF0IG5lZWRzIGZpeGluZyB1cD8gV2l0aCBhIHN0cmVhbS1tYXAtbWFzayBp
biBwbGFjZSB0byBpZ25vcmUgdGhlDQo+IHVwcGVyIFN0cmVhbSBJRCBiaXRzLCB5b3UganVzdCBu
ZWVkOg0KPiANCj4gCWlvbW11LW1hcCA9IDwwICZzbW11IDAgMHg4MD47DQo+IA0KPiB0byBzYXkg
dGhhdCB0aGUgbG93ZXIgYml0cyBvZiB0aGUgSUNJRCB2YWx1ZSBtYXAgZGlyZWN0bHkgdG8gdGhl
IGxvd2VyDQo+IGJpdHMgb2YgdGhlIFN0cmVhbSBJRCB2YWx1ZSAtIHRoYXQncyB0aGUgc2FtZSBm
aXhlZCBwcm9wZXJ0eSBvZiB0aGUNCj4gaGFyZHdhcmUgdGhhdCB5b3UncmUgd2FudGluZyB0byBh
c3N1bWUgaW4gaW9tbXUtcGFyZW50Lg0KDQpNYWtlcyBzZW5zZS4gSSB3YXMgZ29pbmcgaW4gYSBs
aXR0bGUgYml0IHdyb25nIGRpcmVjdGlvbi4gVGhhbmtzIGZvciBjb3JyZWN0aW5nLg0KSSB3aWxs
IHNlbmQgdjIgcGF0Y2hzZXQgd2l0aCBpb21tdS1tYXAgcHJvcGVydHkuDQoNClJlZ2FyZHMsDQpO
aXB1bg0KDQo+IA0KPiA+IElmIHlvdSBzdWdnZXN0IHdlIGNhbiByZS11c2UgdGhlIGlvbW11LW1h
cCBwcm9wZXJ0eS4gV2hhdCBpcyB5b3VyIG9waW5pb24/DQo+IA0KPiBJIHRoaW5rIGl0IG1ha2Vz
IGEgbG90IG1vcmUgc2Vuc2UgdG8gZGlyZWN0bHkgdXNlIHRoZSBwcm9wZXJ0eSB3aGljaA0KPiBh
bHJlYWR5IGV4aXN0cywgdGhhbiB0byBpbnRyb2R1Y2UgYSBuZXcgb25lIHRvIG1lcmVseSBhc3N1
bWUgb25lDQo+IGhhcmQtY29kZWQgdmFsdWUgb2YgdGhlIGV4aXN0aW5nIG9uZS4gRXh0ZW5kaW5n
IG1zaS1wYXJlbnQgdG8gbXNpLW1hcA0KPiB3YXMgYSBjYXNlIG9mICJvb3BzLCBpdCB0dXJucyBv
dXQgd2UgbmVlZCBtb3JlIGZsZXhpYmlsaXR5IGhlcmUiOyBmb3INCj4gdGhlIGNhc2Ugb2YgaW9t
bXUtbWFwIEkgY2FuJ3QgaW1hZ2luZSBhbnkganVzdGlmaWNhdGlvbiBmb3Igc2F5aW5nDQo+ICJv
b3BzLCB3ZSBuZWVkIGxlc3MgZmxleGliaWxpdHkgaGVyZSIgKHNhdmluZyA5IHdob2xlIGJ5dGVz
IGluIHRoZSBEVA0KPiByZWFsbHkgaXMgaXJyZWxldmFudCkuDQo+IA0KPiBSb2Jpbi4NCg==
^ permalink raw reply
* Re: [PATCH 5/6] dma-mapping: support fsl-mc bus
From: Robin Murphy @ 2018-03-05 15:48 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Nipun Gupta, will.deacon, mark.rutland, catalin.marinas, iommu,
robh+dt, m.szyprowski, gregkh, joro, leoyang.li, shawnguo,
linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev,
bharat.bhushan, stuyoder, laurentiu.tudor
In-Reply-To: <20180305150814.GA15918@lst.de>
On 05/03/18 15:08, Christoph Hellwig wrote:
> We should not add any new hardocded busses here. Please mark them in
> OF/ACPI.
Unfortunately for us, fsl-mc is conceptually rather like PCI in that
it's software-discoverable and the only thing described in DT is the bus
"host", thus we need the same sort of thing as for PCI to map from the
child devices back to the bus root in order to find the appropriate
firmware node. Worse than PCI, though, we wouldn't even have the option
of describing child devices statically in firmware at all, since it's
actually one of these runtime-configurable "build your own network
accelerator" hardware pools where userspace gets to create and destroy
"devices" as it likes.
Robin.
^ permalink raw reply
* Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
From: Robin Murphy @ 2018-03-05 15:37 UTC (permalink / raw)
To: Nipun Gupta, will.deacon@arm.com, mark.rutland@arm.com,
catalin.marinas@arm.com
Cc: iommu@lists.linux-foundation.org, robh+dt@kernel.org, hch@lst.de,
m.szyprowski@samsung.com, gregkh@linuxfoundation.org,
joro@8bytes.org, Leo Li, shawnguo@kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, Bharat Bhushan, stuyoder@gmail.com,
Laurentiu Tudor
In-Reply-To: <HE1PR0401MB24254CBDB8B6F537D08B925DE6DA0@HE1PR0401MB2425.eurprd04.prod.outlook.com>
On 05/03/18 15:00, Nipun Gupta wrote:
>
>
>> -----Original Message-----
>> From: Robin Murphy [mailto:robin.murphy@arm.com]
>> Sent: Monday, March 05, 2018 20:23
>> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon@arm.com;
>> mark.rutland@arm.com; catalin.marinas@arm.com
>> Cc: iommu@lists.linux-foundation.org; robh+dt@kernel.org; hch@lst.de;
>> m.szyprowski@samsung.com; gregkh@linuxfoundation.org; joro@8bytes.org;
>> Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org; linux-
>> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
>> kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org; Bharat Bhushan
>> <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor
>> <laurentiu.tudor@nxp.com>
>> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
>>
>> On 05/03/18 14:29, Nipun Gupta wrote:
>>> The existing IOMMU bindings cannot be used to specify the relationship
>>> between fsl-mc devices and IOMMUs. This patch adds a binding for
>>> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
>>
>> Given that allowing "msi-parent" for #msi-cells > 1 is merely a
>> backward-compatibility bodge full of hard-coded assumptions, why would
>> we want to knowingly introduce a similarly unpleasant equivalent for
>> IOMMUs? What's wrong with "iommu-map"?
>
> Hi Robin,
>
> With 'msi-parent' the property is fixed up to have msi-map. In this case there is
> no fixup required and simple 'iommu-parent' property can be used, with MC bus
> itself providing the stream-id's (in the code execution via FW).
>
> We can also use the iommu-map property similar to PCI, which will require u-boot
> fixup. But then it leads to little bit complications of u-boot - kernel compatibility.
What needs fixing up? With a stream-map-mask in place to ignore the
upper Stream ID bits, you just need:
iommu-map = <0 &smmu 0 0x80>;
to say that the lower bits of the ICID value map directly to the lower
bits of the Stream ID value - that's the same fixed property of the
hardware that you're wanting to assume in iommu-parent.
> If you suggest we can re-use the iommu-map property. What is your opinion?
I think it makes a lot more sense to directly use the property which
already exists, than to introduce a new one to merely assume one
hard-coded value of the existing one. Extending msi-parent to msi-map
was a case of "oops, it turns out we need more flexibility here"; for
the case of iommu-map I can't imagine any justification for saying
"oops, we need less flexibility here" (saving 9 whole bytes in the DT
really is irrelevant).
Robin.
^ permalink raw reply
* Re: [PATCH 5/6] dma-mapping: support fsl-mc bus
From: Christoph Hellwig @ 2018-03-05 15:08 UTC (permalink / raw)
To: Nipun Gupta
Cc: will.deacon, robin.murphy, mark.rutland, catalin.marinas, iommu,
robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li, shawnguo,
linux-kernel, devicetree, linux-arm-kernel, linuxppc-dev,
bharat.bhushan, stuyoder, laurentiu.tudor
In-Reply-To: <1520260166-29387-6-git-send-email-nipun.gupta@nxp.com>
We should not add any new hardocded busses here. Please mark them in
OF/ACPI.
^ permalink raw reply
* RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
From: Nipun Gupta @ 2018-03-05 15:00 UTC (permalink / raw)
To: Robin Murphy, will.deacon@arm.com, mark.rutland@arm.com,
catalin.marinas@arm.com
Cc: iommu@lists.linux-foundation.org, robh+dt@kernel.org, hch@lst.de,
m.szyprowski@samsung.com, gregkh@linuxfoundation.org,
joro@8bytes.org, Leo Li, shawnguo@kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, Bharat Bhushan, stuyoder@gmail.com,
Laurentiu Tudor
In-Reply-To: <5cdeded1-ca3c-339a-bf73-73401e7dd4ed@arm.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iaW4gTXVycGh5IFtt
YWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMDUsIDIw
MTggMjA6MjMNCj4gVG86IE5pcHVuIEd1cHRhIDxuaXB1bi5ndXB0YUBueHAuY29tPjsgd2lsbC5k
ZWFjb25AYXJtLmNvbTsNCj4gbWFyay5ydXRsYW5kQGFybS5jb207IGNhdGFsaW4ubWFyaW5hc0Bh
cm0uY29tDQo+IENjOiBpb21tdUBsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgcm9iaCtkdEBr
ZXJuZWwub3JnOyBoY2hAbHN0LmRlOw0KPiBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207IGdyZWdr
aEBsaW51eGZvdW5kYXRpb24ub3JnOyBqb3JvQDhieXRlcy5vcmc7DQo+IExlbyBMaSA8bGVveWFu
Zy5saUBueHAuY29tPjsgc2hhd25ndW9Aa2VybmVsLm9yZzsgbGludXgtDQo+IGtlcm5lbEB2Z2Vy
Lmtlcm5lbC5vcmc7IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eC1hcm0tDQo+IGtl
cm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsg
QmhhcmF0IEJodXNoYW4NCj4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+OyBzdHV5b2RlckBnbWFp
bC5jb207IExhdXJlbnRpdSBUdWRvcg0KPiA8bGF1cmVudGl1LnR1ZG9yQG54cC5jb20+DQo+IFN1
YmplY3Q6IFJlOiBbUEFUQ0ggMS82XSBEb2NzOiBkdDogYWRkIGZzbC1tYyBpb21tdS1wYXJlbnQg
ZGV2aWNlLXRyZWUgYmluZGluZw0KPiANCj4gT24gMDUvMDMvMTggMTQ6MjksIE5pcHVuIEd1cHRh
IHdyb3RlOg0KPiA+IFRoZSBleGlzdGluZyBJT01NVSBiaW5kaW5ncyBjYW5ub3QgYmUgdXNlZCB0
byBzcGVjaWZ5IHRoZSByZWxhdGlvbnNoaXANCj4gPiBiZXR3ZWVuIGZzbC1tYyBkZXZpY2VzIGFu
ZCBJT01NVXMuIFRoaXMgcGF0Y2ggYWRkcyBhIGJpbmRpbmcgZm9yDQo+ID4gbWFwcGluZyBmc2wt
bWMgZGV2aWNlcyB0byBJT01NVXMsIHVzaW5nIGEgbmV3IGlvbW11LXBhcmVudCBwcm9wZXJ0eS4N
Cj4gDQo+IEdpdmVuIHRoYXQgYWxsb3dpbmcgIm1zaS1wYXJlbnQiIGZvciAjbXNpLWNlbGxzID4g
MSBpcyBtZXJlbHkgYQ0KPiBiYWNrd2FyZC1jb21wYXRpYmlsaXR5IGJvZGdlIGZ1bGwgb2YgaGFy
ZC1jb2RlZCBhc3N1bXB0aW9ucywgd2h5IHdvdWxkDQo+IHdlIHdhbnQgdG8ga25vd2luZ2x5IGlu
dHJvZHVjZSBhIHNpbWlsYXJseSB1bnBsZWFzYW50IGVxdWl2YWxlbnQgZm9yDQo+IElPTU1Vcz8g
V2hhdCdzIHdyb25nIHdpdGggImlvbW11LW1hcCI/DQoNCkhpIFJvYmluLA0KDQpXaXRoICdtc2kt
cGFyZW50JyB0aGUgcHJvcGVydHkgaXMgZml4ZWQgdXAgdG8gaGF2ZSBtc2ktbWFwLiBJbiB0aGlz
IGNhc2UgdGhlcmUgaXMNCm5vIGZpeHVwIHJlcXVpcmVkIGFuZCBzaW1wbGUgJ2lvbW11LXBhcmVu
dCcgcHJvcGVydHkgY2FuIGJlIHVzZWQsIHdpdGggTUMgYnVzDQppdHNlbGYgcHJvdmlkaW5nIHRo
ZSBzdHJlYW0taWQncyAoaW4gdGhlIGNvZGUgZXhlY3V0aW9uIHZpYSBGVykuDQoNCldlIGNhbiBh
bHNvIHVzZSB0aGUgaW9tbXUtbWFwIHByb3BlcnR5IHNpbWlsYXIgdG8gUENJLCB3aGljaCB3aWxs
IHJlcXVpcmUgdS1ib290DQpmaXh1cC4gQnV0IHRoZW4gaXQgbGVhZHMgdG8gbGl0dGxlIGJpdCBj
b21wbGljYXRpb25zIG9mIHUtYm9vdCAtIGtlcm5lbCBjb21wYXRpYmlsaXR5Lg0KDQpJZiB5b3Ug
c3VnZ2VzdCB3ZSBjYW4gcmUtdXNlIHRoZSBpb21tdS1tYXAgcHJvcGVydHkuIFdoYXQgaXMgeW91
ciBvcGluaW9uPw0KDQpUaGFua3MsDQpOaXB1bg0KDQo+IA0KPiA+IFNpZ25lZC1vZmYtYnk6IE5p
cHVuIEd1cHRhIDxuaXB1bi5ndXB0YUBueHAuY29tPg0KPiA+IC0tLQ0KPiA+ICAgLi4uL2Rldmlj
ZXRyZWUvYmluZGluZ3MvbWlzYy9mc2wscW9yaXEtbWMudHh0ICAgICAgfCAzMQ0KPiArKysrKysr
KysrKysrKysrKysrKysrDQo+ID4gICAxIGZpbGUgY2hhbmdlZCwgMzEgaW5zZXJ0aW9ucygrKQ0K
PiA+DQo+ID4gZGlmZiAtLWdpdCBhL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9t
aXNjL2ZzbCxxb3JpcS1tYy50eHQNCj4gYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGlu
Z3MvbWlzYy9mc2wscW9yaXEtbWMudHh0DQo+ID4gaW5kZXggNjYxMWE3Yy4uMDExYzdkNiAxMDA2
NDQNCj4gPiAtLS0gYS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvbWlzYy9mc2ws
cW9yaXEtbWMudHh0DQo+ID4gKysrIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdz
L21pc2MvZnNsLHFvcmlxLW1jLnR4dA0KPiA+IEBAIC05LDYgKzksMjQgQEAgYmxvY2tzIHRoYXQg
Y2FuIGJlIHVzZWQgdG8gY3JlYXRlIGZ1bmN0aW9uYWwgaGFyZHdhcmUNCj4gb2JqZWN0cy9kZXZp
Y2VzDQo+ID4gICBzdWNoIGFzIG5ldHdvcmsgaW50ZXJmYWNlcywgY3J5cHRvIGFjY2VsZXJhdG9y
IGluc3RhbmNlcywgTDIgc3dpdGNoZXMsDQo+ID4gICBldGMuDQo+ID4NCj4gPiArRm9yIGFuIG92
ZXJ2aWV3IG9mIHRoZSBEUEFBMiBhcmNoaXRlY3R1cmUgYW5kIGZzbC1tYyBidXMgc2VlOg0KPiA+
ICtkcml2ZXJzL3N0YWdpbmcvZnNsLW1jL1JFQURNRS50eHQNCj4gPiArDQo+ID4gK0FzIGRlc2Ny
aWJlZCBpbiB0aGUgYWJvdmUgb3ZlcnZpZXcsIGFsbCBEUEFBMiBvYmplY3RzIGluIGEgRFBSQyBz
aGFyZSB0aGUNCj4gPiArc2FtZSBoYXJkd2FyZSAiaXNvbGF0aW9uIGNvbnRleHQiIGFuZCBhIDEw
LWJpdCB2YWx1ZSBjYWxsZWQgYW4gSUNJRA0KPiA+ICsoaXNvbGF0aW9uIGNvbnRleHQgaWQpIGlz
IGV4cHJlc3NlZCBieSB0aGUgaGFyZHdhcmUgdG8gaWRlbnRpZnkNCj4gPiArdGhlIHJlcXVlc3Rl
ci4NCj4gDQo+IElPVywgcHJlY2lzZWx5IHRoZSBjYXNlIGZvciB3aGljaCAie21zaSxpb21tdX0t
bWFwIiBleGlzdC4gWWVzLCBJIGtub3cNCj4gdGhleSdyZSBjdXJyZW50bHkgZG9jdW1lbnRlZCB1
bmRlciBiaW5kaW5ncy9wY2ksIGJ1dCB0aGV5J3JlIG5vdCByZWFsbHkNCj4gaW50ZW5kZWQgdG8g
YmUgYWJzb2x1dGVseSBQQ0ktc3BlY2lmaWMuDQo+IA0KPiBSb2Jpbi4NCj4gDQo+ID4gK1RoZSBn
ZW5lcmljICdpb21tdXMnIHByb3BlcnR5IGlzIGNhbm5vdCBiZSB1c2VkIHRvIGRlc2NyaWJlIHRo
ZSByZWxhdGlvbnNoaXANCj4gPiArYmV0d2VlbiBmc2wtbWMgYW5kIElPTU1Vcywgc28gYW4gaW9t
bXUtcGFyZW50IHByb3BlcnR5IGlzIHVzZWQgdG8gZGVmaW5lDQo+ID4gK3RoZSBzYW1lLg0KPiA+
ICsNCj4gPiArRm9yIGdlbmVyaWMgSU9NTVUgYmluZGluZ3MsIHNlZQ0KPiA+ICtEb2N1bWVudGF0
aW9uL2RldmljZXRyZWUvYmluZGluZ3MvaW9tbXUvaW9tbXUudHh0Lg0KPiA+ICsNCj4gPiArRm9y
IGFybS1zbW11IGJpbmRpbmcsIHNlZToNCj4gPiArRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2Jp
bmRpbmdzL2lvbW11L2FybSxzbW11LnR4dC4NCj4gPiArDQo+ID4gICBSZXF1aXJlZCBwcm9wZXJ0
aWVzOg0KPiA+DQo+ID4gICAgICAgLSBjb21wYXRpYmxlDQo+ID4gQEAgLTg4LDE0ICsxMDYsMjcg
QEAgU3ViLW5vZGVzOg0KPiA+ICAgICAgICAgICAgICAgICBWYWx1ZSB0eXBlOiA8cGhhbmRsZT4N
Cj4gPiAgICAgICAgICAgICAgICAgRGVmaW5pdGlvbjogU3BlY2lmaWVzIHRoZSBwaGFuZGxlIHRv
IHRoZSBQSFkgZGV2aWNlIG5vZGUgYXNzb2NpYXRlZA0KPiA+ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB3aXRoIHRoZSB0aGlzIGRwbWFjLg0KPiA+ICtPcHRpb25hbCBwcm9wZXJ0aWVzOg0K
PiA+ICsNCj4gPiArLSBpb21tdS1wYXJlbnQ6IE1hcHMgdGhlIGRldmljZXMgb24gZnNsLW1jIGJ1
cyB0byBhbiBJT01NVS4NCj4gPiArICBUaGUgcHJvcGVydHkgc3BlY2lmaWVzIHRoZSBJT01NVSBi
ZWhpbmQgd2hpY2ggdGhlIGRldmljZXMgb24NCj4gPiArICBmc2wtbWMgYnVzIGFyZSByZXNpZGlu
Zy4NCj4gPg0KPiA+ICAgRXhhbXBsZToNCj4gPg0KPiA+ICsgICAgICAgIHNtbXU6IGlvbW11QDUw
MDAwMDAgew0KPiA+ICsgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxtbXUtNTAwIjsN
Cj4gPiArICAgICAgICAgICAgICAgI2lvbW11LWNlbGxzID0gPDE+Ow0KPiA+ICsgICAgICAgICAg
ICAgICBzdHJlYW0tbWF0Y2gtbWFzayA9IDwweDdDMDA+Ow0KPiA+ICsgICAgICAgICAgICAgICAu
Li4NCj4gPiArICAgICAgICB9Ow0KPiA+ICsNCj4gPiAgICAgICAgICAgZnNsX21jOiBmc2wtbWNA
ODBjMDAwMDAwIHsNCj4gPiAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImZzbCxxb3Jp
cS1tYyI7DQo+ID4gICAgICAgICAgICAgICAgICAgcmVnID0gPDB4MDAwMDAwMDggMHgwYzAwMDAw
MCAwIDB4NDA+LCAgICAvKiBNQyBwb3J0YWwgYmFzZSAqLw0KPiA+ICAgICAgICAgICAgICAgICAg
ICAgICAgIDwweDAwMDAwMDAwIDB4MDgzNDAwMDAgMCAweDQwMDAwPjsgLyogTUMgY29udHJvbCBy
ZWcgKi8NCj4gPiAgICAgICAgICAgICAgICAgICBtc2ktcGFyZW50ID0gPCZpdHM+Ow0KPiA+ICsg
ICAgICAgICAgICAgICAgaW9tbXUtcGFyZW50ID0gPCZzbW11PjsNCj4gPiAgICAgICAgICAgICAg
ICAgICAjYWRkcmVzcy1jZWxscyA9IDwzPjsNCj4gPiAgICAgICAgICAgICAgICAgICAjc2l6ZS1j
ZWxscyA9IDwxPjsNCj4gPg0KPiA+DQo=
^ permalink raw reply
* Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
From: Robin Murphy @ 2018-03-05 14:53 UTC (permalink / raw)
To: Nipun Gupta, will.deacon, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor
In-Reply-To: <1520260166-29387-2-git-send-email-nipun.gupta@nxp.com>
On 05/03/18 14:29, Nipun Gupta wrote:
> The existing IOMMU bindings cannot be used to specify the relationship
> between fsl-mc devices and IOMMUs. This patch adds a binding for
> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
Given that allowing "msi-parent" for #msi-cells > 1 is merely a
backward-compatibility bodge full of hard-coded assumptions, why would
we want to knowingly introduce a similarly unpleasant equivalent for
IOMMUs? What's wrong with "iommu-map"?
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
> .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> index 6611a7c..011c7d6 100644
> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices
> such as network interfaces, crypto accelerator instances, L2 switches,
> etc.
>
> +For an overview of the DPAA2 architecture and fsl-mc bus see:
> +drivers/staging/fsl-mc/README.txt
> +
> +As described in the above overview, all DPAA2 objects in a DPRC share the
> +same hardware "isolation context" and a 10-bit value called an ICID
> +(isolation context id) is expressed by the hardware to identify
> +the requester.
IOW, precisely the case for which "{msi,iommu}-map" exist. Yes, I know
they're currently documented under bindings/pci, but they're not really
intended to be absolutely PCI-specific.
Robin.
> +The generic 'iommus' property is cannot be used to describe the relationship
> +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> +the same.
> +
> +For generic IOMMU bindings, see
> +Documentation/devicetree/bindings/iommu/iommu.txt.
> +
> +For arm-smmu binding, see:
> +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> +
> Required properties:
>
> - compatible
> @@ -88,14 +106,27 @@ Sub-nodes:
> Value type: <phandle>
> Definition: Specifies the phandle to the PHY device node associated
> with the this dpmac.
> +Optional properties:
> +
> +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> + The property specifies the IOMMU behind which the devices on
> + fsl-mc bus are residing.
>
> Example:
>
> + smmu: iommu@5000000 {
> + compatible = "arm,mmu-500";
> + #iommu-cells = <1>;
> + stream-match-mask = <0x7C00>;
> + ...
> + };
> +
> fsl_mc: fsl-mc@80c000000 {
> compatible = "fsl,qoriq-mc";
> reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
> <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
> msi-parent = <&its>;
> + iommu-parent = <&smmu>;
> #address-cells = <3>;
> #size-cells = <1>;
>
>
^ permalink raw reply
* [PATCH 0/6] Support for fsl-mc bus and its devices in SMMU
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.
These patches
- Define the new property 'iommu-parent' for fsl-mc bus (patch 1)
- Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3)
- Adds the dma-mapping support for fsl-mc bus (patch 4,5)
- Updates the fsl-mc device node with iommu/dma related changes
This patchset is based on staging-testing tree where fsl-mc bus is out
from staging
This patchset is dependent on patch https://patchwork.kernel.org/patch/10207507/;
otherwise DPAA2 Ethernet driver functionality will break.
Nipun Gupta (6):
Docs: dt: add fsl-mc iommu-parent device-tree binding
iommu: support iommu configuration for fsl-mc devices
iommu: arm-smmu: Add support for the fsl-mc bus
bus: fsl-mc: remove dma ops setup from driver
dma-mapping: support fsl-mc bus
dts: fsl-ls208x: updated DT with SMMU support for fsl-mc
.../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 ++++-
drivers/base/dma-mapping.c | 7 +++++
drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +---
drivers/iommu/arm-smmu.c | 7 +++++
drivers/iommu/iommu.c | 21 +++++++++++++++
drivers/iommu/of_iommu.c | 23 ++++++++++++++++
include/linux/fsl/mc.h | 8 ++++++
include/linux/iommu.h | 2 ++
9 files changed, 105 insertions(+), 5 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 6/6] dts: fsl-ls208x: updated DT with SMMU support for fsl-mc
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
In-Reply-To: <1520260166-29387-1-git-send-email-nipun.gupta@nxp.com>
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f3a40af..1f15492 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -135,6 +135,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+ dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
clockgen: clocking@1300000 {
compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
<0x00000000 0x08340000 0 0x40000>; /* MC control reg */
msi-parent = <&its>;
+ iommu-parent = <&smmu>;
+ dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
@@ -460,6 +463,8 @@
compatible = "arm,mmu-500";
reg = <0 0x5000000 0 0x800000>;
#global-interrupts = <12>;
+ stream-match-mask = <0x7C00>;
+ dma-coherent;
interrupts = <0 13 4>, /* global secure fault */
<0 14 4>, /* combined secure interrupt */
<0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
<0 204 4>, <0 205 4>,
<0 206 4>, <0 207 4>,
<0 208 4>, <0 209 4>;
- mmu-masters = <&fsl_mc 0x300 0>;
};
dspi: dspi@2100000 {
--
1.9.1
^ permalink raw reply related
* [PATCH 5/6] dma-mapping: support fsl-mc bus
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
In-Reply-To: <1520260166-29387-1-git-send-email-nipun.gupta@nxp.com>
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
drivers/base/dma-mapping.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..2279c4d 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -334,6 +334,7 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
* Common configuration to enable DMA API use for a device
*/
#include <linux/pci.h>
+#include <linux/fsl/mc.h>
int dma_configure(struct device *dev)
{
@@ -349,6 +350,12 @@ int dma_configure(struct device *dev)
dma_dev = dma_dev->parent;
}
+ if (dev_is_fsl_mc(dev)) {
+ dma_dev = dev;
+ while (dev_is_fsl_mc(dma_dev))
+ dma_dev = dma_dev->parent;
+ }
+
if (dma_dev->of_node) {
ret = of_dma_configure(dev, dma_dev->of_node);
} else if (has_acpi_companion(dma_dev)) {
--
1.9.1
^ permalink raw reply related
* [PATCH 4/6] bus: fsl-mc: remove dma ops setup from driver
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
In-Reply-To: <1520260166-29387-1-git-send-email-nipun.gupta@nxp.com>
The dma setup for fsl-mc devices is being done from device_add()
function. So, no need to call in mc bus driver.
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 1b333c4..c9a239a 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -616,6 +616,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
mc_dev->icid = parent_mc_dev->icid;
mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
mc_dev->dev.dma_mask = &mc_dev->dma_mask;
+ mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
dev_set_msi_domain(&mc_dev->dev,
dev_get_msi_domain(&parent_mc_dev->dev));
}
@@ -633,10 +634,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
- /* Objects are coherent, unless 'no shareability' flag set. */
- if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
- arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
-
/*
* The device-specific probe callback will get invoked by device_add()
*/
--
1.9.1
^ permalink raw reply related
* [PATCH 3/6] iommu: arm-smmu: Add support for the fsl-mc bus
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
In-Reply-To: <1520260166-29387-1-git-send-email-nipun.gupta@nxp.com>
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
drivers/iommu/arm-smmu.c | 7 +++++++
drivers/iommu/iommu.c | 21 +++++++++++++++++++++
include/linux/fsl/mc.h | 8 ++++++++
include/linux/iommu.h | 2 ++
4 files changed, 38 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
#include <linux/spinlock.h>
#include <linux/amba/bus.h>
+#include <linux/fsl/mc.h>
#include "io-pgtable.h"
#include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
if (dev_is_pci(dev))
group = pci_device_group(dev);
+ else if (dev_is_fsl_mc(dev))
+ group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
}
#endif
+#ifdef CONFIG_FSL_MC_BUS
+ if (!iommu_present(&fsl_mc_bus_type))
+ bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops);
+#endif
}
static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 69fef99..fbeebb2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
#include <linux/pci.h>
#include <linux/bitops.h>
#include <linux/property.h>
+#include <linux/fsl/mc.h>
#include <trace/events/iommu.h>
static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
}
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+ struct device *cont_dev = fsl_mc_cont_dev(dev);
+ struct iommu_group *group;
+
+ /* Container device is responsible for creating the iommu group */
+ if (fsl_mc_is_cont_dev(dev)) {
+ group = iommu_group_alloc();
+ if (IS_ERR(group))
+ return NULL;
+ } else {
+ get_device(cont_dev);
+ group = iommu_group_get(cont_dev);
+ put_device(cont_dev);
+ }
+
+ return group;
+}
+
/**
* iommu_group_get_for_dev - Find or create the IOMMU group for a device
* @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index 765ba41..ae9382b 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
#define dev_is_fsl_mc(_dev) (0)
#endif
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+ FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+ (_dev) : (_dev)->parent)
+
/*
* module_fsl_mc_driver() - Helper macro for drivers that don't do
* anything special in module init/exit. This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 41b8c57..00a460b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain,
extern struct iommu_group *pci_device_group(struct device *dev);
/* Generic device grouping function */
extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
/**
* struct iommu_fwspec - per-device IOMMU instance data
--
1.9.1
^ permalink raw reply related
* [PATCH 2/6] iommu: support iommu configuration for fsl-mc devices
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
In-Reply-To: <1520260166-29387-1-git-send-email-nipun.gupta@nxp.com>
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
drivers/iommu/of_iommu.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..cc2fb9c 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
#include <linux/of_iommu.h>
#include <linux/of_pci.h>
#include <linux/slab.h>
+#include <linux/fsl/mc.h>
#define NO_IOMMU 1
@@ -160,6 +161,26 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
return err;
}
+static int
+of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+ struct device_node *master_np)
+{
+ struct of_phandle_args iommu_spec;
+ int err;
+
+ iommu_spec.np = of_parse_phandle(master_np, "iommu-parent", 0);
+ if (!iommu_spec.np)
+ return NO_IOMMU;
+
+ iommu_spec.args[0] = mc_dev->icid;
+ iommu_spec.args_count = 1;
+
+ err = of_iommu_xlate(&mc_dev->dev, &iommu_spec);
+ of_node_put(iommu_spec.np);
+
+ return err;
+}
+
const struct iommu_ops *of_iommu_configure(struct device *dev,
struct device_node *master_np)
{
@@ -191,6 +212,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
err = pci_for_each_dma_alias(to_pci_dev(dev),
of_pci_iommu_init, &info);
+ } else if (dev_is_fsl_mc(dev)) {
+ err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
From: Nipun Gupta @ 2018-03-05 14:29 UTC (permalink / raw)
To: will.deacon, robin.murphy, mark.rutland, catalin.marinas
Cc: iommu, robh+dt, hch, m.szyprowski, gregkh, joro, leoyang.li,
shawnguo, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, bharat.bhushan, stuyoder, laurentiu.tudor,
Nipun Gupta
In-Reply-To: <1520260166-29387-1-git-send-email-nipun.gupta@nxp.com>
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a binding for
mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
.../devicetree/bindings/misc/fsl,qoriq-mc.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..011c7d6 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices
such as network interfaces, crypto accelerator instances, L2 switches,
etc.
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is cannot be used to describe the relationship
+between fsl-mc and IOMMUs, so an iommu-parent property is used to define
+the same.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
Required properties:
- compatible
@@ -88,14 +106,27 @@ Sub-nodes:
Value type: <phandle>
Definition: Specifies the phandle to the PHY device node associated
with the this dpmac.
+Optional properties:
+
+- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
+ The property specifies the IOMMU behind which the devices on
+ fsl-mc bus are residing.
Example:
+ smmu: iommu@5000000 {
+ compatible = "arm,mmu-500";
+ #iommu-cells = <1>;
+ stream-match-mask = <0x7C00>;
+ ...
+ };
+
fsl_mc: fsl-mc@80c000000 {
compatible = "fsl,qoriq-mc";
reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
<0x00000000 0x08340000 0 0x40000>; /* MC control reg */
msi-parent = <&its>;
+ iommu-parent = <&smmu>;
#address-cells = <3>;
#size-cells = <1>;
--
1.9.1
^ permalink raw reply related
* barrier_nospec for POWER
From: Michal Suchánek @ 2018-03-05 13:13 UTC (permalink / raw)
To: linuxppc-dev
Hello,
there is x86 barrier_nospec which implements the same barrier as the
earlier out-of-tree gmb() barrier but instead of sprinkling the barrier
randomly in kernel code it put it in copy_from_user. We have the
firmware support for barrier_nospec already reported from the hcall
which is used for RFI flushes. So copy-pasting this from x86 should not
be that difficult.
However, there is separate patch which protects the NR_syscalls check of
syscall entry which does not apply on powerpc because the check is done
in assembly. I did not manage to write a barrier_nospec that compiles
both in C and asm so you are spared a RFC patch.
Is there some work in progress on addressing this?
Thanks
Michal
^ permalink raw reply
* Re: [v2] selftests/powerpc: Skip the subpage_prot tests if the syscall is unavailable
From: Michael Ellerman @ 2018-03-05 12:36 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: aneesh.kumar
In-Reply-To: <20180302020108.22174-1-mpe@ellerman.id.au>
On Fri, 2018-03-02 at 02:01:08 UTC, Michael Ellerman wrote:
> The subpage_prot syscall is only functional when the system is using
> the Hash MMU. Since commit 5b2b80714796 ("powerpc/mm: Invalidate
> subpage_prot() system call on radix platforms") it returns ENOENT when
> the Radix MMU is active. Currently this just makes the test fail.
>
> Additionally the syscall is not available if the kernel is built with
> 4K pages, or if CONFIG_PPC_SUBPAGE_PROT=n, in which case it returns
> ENOSYS because the syscall is missing entirely.
>
> So check explicitly for ENOENT and ENOSYS and skip if we see either of
> those.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/cd4a6f3ab4d80cb919d15897eb3cbc
cheers
^ permalink raw reply
* Re: selftests/powerpc: Fix missing clean of pmu/lib.o
From: Michael Ellerman @ 2018-03-05 12:36 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20180228093257.13049-1-mpe@ellerman.id.au>
On Wed, 2018-02-28 at 09:32:57 UTC, Michael Ellerman wrote:
> The tm-resched-dscr test links against pmu/lib.o, but we don't have a
> rule to clean pmu/lib.o. This can lead to a build break if you build
> for big endian and then little, or vice versa.
>
> Fix it by making tm-resched-dscr depend on pmu/lib.c, causing the code
> to be built directly in, meaning no .o is generated.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/b7abbd5a3533a31a1e7d4696ea275d
cheers
^ permalink raw reply
* Re: selftests/powerpc: Skip tm-trap if transactional memory is not enabled
From: Michael Ellerman @ 2018-03-05 12:36 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: gromero
In-Reply-To: <20180226021926.32513-1-mpe@ellerman.id.au>
On Mon, 2018-02-26 at 02:19:26 UTC, Michael Ellerman wrote:
> Some processor revisions do not support transactional memory, and
> additionally kernel support can be disabled. In either case the
> tm-trap test should be skipped, otherwise it will fail with a SIGILL.
>
> Fixes: a08082f8e4e1 ("powerpc/selftests: Check endianness on trap in TM")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/192b2e742c06af399e8eecb4a17265
cheers
^ permalink raw reply
* Re: powerpc/boot: Fix random build errors
From: Michael Ellerman @ 2018-03-05 12:36 UTC (permalink / raw)
To: Guenter Roeck, Benjamin Herrenschmidt
Cc: Paul Mackerras, linuxppc-dev, Guenter Roeck, linux-kernel
In-Reply-To: <1519419359-19163-1-git-send-email-linux@roeck-us.net>
On Fri, 2018-02-23 at 20:55:59 UTC, Guenter Roeck wrote:
> Once in a while I see build errors similar to the following
> when building images from a clean tree.
>
> Building powerpc:virtex-ml507:44x/virtex5_defconfig ... failed
> ------------
> Error log:
> arch/powerpc/boot/treeboot-akebono.c:37:20: fatal error:
> libfdt.h: No such file or directory
>
> Building powerpc:bamboo:smpdev:44x/bamboo_defconfig ... failed
> ------------
> Error log:
> arch/powerpc/boot/treeboot-akebono.c:37:20: fatal error:
> libfdt.h: No such file or directory
>
> arch/powerpc/boot/treeboot-currituck.c:35:20: fatal error:
> libfdt.h: No such file or directory
>
> Rebuilds will succeed.
>
> Turns out that several source files in arch/powerpc/boot/ include
> libfdt.h, but Makefile dependencies are incomplete. Let's fix that.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/64c3f648c25d108f346fdc96c15180
cheers
^ permalink raw reply
* Re: [v3, 1/2] ocxl: Add get_metadata IOCTL to share OCXL information to userspace
From: Michael Ellerman @ 2018-03-05 12:36 UTC (permalink / raw)
To: Alastair D'Silva, linuxppc-dev, linux-kernel
Cc: alastair, arnd, frederic.barrat, gregkh, andrew.donnellan,
Alastair D'Silva
In-Reply-To: <20180222041739.27899-2-alastair@au1.ibm.com>
On Thu, 2018-02-22 at 04:17:38 UTC, "Alastair D'Silva" wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> Some required information is not exposed to userspace currently (eg. the
> PASID), pass this information back, along with other information which
> is currently communicated via sysfs, which saves some parsing effort in
> userspace.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Series applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/07c5ccd70ad702e561fcda8e4df494
cheers
^ permalink raw reply
* Re: [PATCH v8 18/24] mm: Provide speculative fault infrastructure
From: Laurent Dufour @ 2018-03-05 10:50 UTC (permalink / raw)
To: Daniel Jordan, paulmck, peterz, akpm, kirill, ak, mhocko, dave,
jack, Matthew Wilcox, benh, mpe, paulus, Thomas Gleixner,
Ingo Molnar, hpa, Will Deacon, Sergey Senozhatsky,
Andrea Arcangeli, Alexei Starovoitov, kemi.wang,
sergey.senozhatsky.work
Cc: linux-kernel, linux-mm, haren, khandual, npiggin, bsingharora,
Tim Chen, linuxppc-dev, x86
In-Reply-To: <5b16d6ce-6b62-e4ca-2d78-c25bb008e27e@oracle.com>
Hi Jordan,
Thanks for reporting this.
On 26/02/2018 18:16, Daniel Jordan wrote:
> Hi Laurent,
>
> This series doesn't build for me[*] when CONFIG_TRANSPARENT_HUGEPAGE is unset.
>
> The problem seems to be that the BUILD_BUG() version of pmd_same is called in
> pte_map_lock:
>
> On 02/16/2018 10:25 AM, Laurent Dufour wrote:
>> +static bool pte_map_lock(struct vm_fault *vmf)
>> +{
> ...snip...
>> + if (!pmd_same(pmdval, vmf->orig_pmd))
>> + goto out;
>
> Since SPF can now call pmd_same without THP, maybe the way to fix it is just
>
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 2cfa3075d148..e130692db24a 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -375,7 +375,8 @@ static inline int pte_unused(pte_t pte)
> #endif
>
> #ifndef __HAVE_ARCH_PMD_SAME
> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +#if defined(CONFIG_TRANSPARENT_HUGEPAGE) || \
> + defined(CONFIG_SPECULATIVE_PAGE_FAULT)
> static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
> {
> return pmd_val(pmd_a) == pmd_val(pmd_b);
We can't fix that this way because some architectures define their own
pmd_same() function (like ppc64), thus forcing the define here will be useless
since __HAVE_ARCH_PMD_SAME is set in that case.
The right way to fix that is to _not check_ for the PMD value in pte_spinlock()
when CONFIG_TRANSPARENT_HUGEPAGE is not set since there is no risk of
collapsing operation in our back if THP are disabled.
I'll fix that in the next version.
Laurent.
> ?
>
> Daniel
>
>
> [*] The errors are:
>
> In file included from /home/dmjordan/src/linux/include/linux/kernel.h:10:0,
> from /home/dmjordan/src/linux/include/linux/list.h:9,
> from /home/dmjordan/src/linux/include/linux/smp.h:12,
> from /home/dmjordan/src/linux/include/linux/kernel_stat.h:5,
> from /home/dmjordan/src/linux/mm/memory.c:41:
> In function ‘pmd_same.isra.104’,
> inlined from ‘pte_map_lock’ at /home/dmjordan/src/linux/mm/memory.c:2380:7:
> /home/dmjordan/src/linux/include/linux/compiler.h:324:38: error: call to
> ‘__compiletime_assert_391’ declared with attribute error: BUILD_BUG failed
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^
> /home/dmjordan/src/linux/include/linux/compiler.h:304:4: note: in definition of
> macro ‘__compiletime_assert’
> prefix ## suffix(); \
> ^~~~~~
> /home/dmjordan/src/linux/include/linux/compiler.h:324:2: note: in expansion of
> macro ‘_compiletime_assert’
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^~~~~~~~~~~~~~~~~~~
> /home/dmjordan/src/linux/include/linux/build_bug.h:45:37: note: in expansion of
> macro ‘compiletime_assert’
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^~~~~~~~~~~~~~~~~~
> /home/dmjordan/src/linux/include/linux/build_bug.h:79:21: note: in expansion of
> macro ‘BUILD_BUG_ON_MSG’
> #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
> ^~~~~~~~~~~~~~~~
> /home/dmjordan/src/linux/include/asm-generic/pgtable.h:391:2: note: in
> expansion of macro ‘BUILD_BUG’
> BUILD_BUG();
> ^~~~~~~~~
> CC block/elevator.o
> CC crypto/crypto_wq.o
> In function ‘pmd_same.isra.104’,
> inlined from ‘pte_spinlock’ at /home/dmjordan/src/linux/mm/memory.c:2326:7,
> inlined from ‘handle_pte_fault’ at
> /home/dmjordan/src/linux/mm/memory.c:4181:7:
> /home/dmjordan/src/linux/include/linux/compiler.h:324:38: error: call to
> ‘__compiletime_assert_391’ declared with attribute error: BUILD_BUG failed
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^
> /home/dmjordan/src/linux/include/linux/compiler.h:304:4: note: in definition of
> macro ‘__compiletime_assert’
> prefix ## suffix(); \
> ^~~~~~
> /home/dmjordan/src/linux/include/linux/compiler.h:324:2: note: in expansion of
> macro ‘_compiletime_assert’
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^~~~~~~~~~~~~~~~~~~
> /home/dmjordan/src/linux/include/linux/build_bug.h:45:37: note: in expansion of
> macro ‘compiletime_assert’
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^~~~~~~~~~~~~~~~~~
> /home/dmjordan/src/linux/include/linux/build_bug.h:79:21: note: in expansion of
> macro ‘BUILD_BUG_ON_MSG’
> #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
> ^~~~~~~~~~~~~~~~
> /home/dmjordan/src/linux/include/asm-generic/pgtable.h:391:2: note: in
> expansion of macro ‘BUILD_BUG’
> BUILD_BUG();
> ^~~~~~~~~
> ...
> make[2]: *** [/home/dmjordan/src/linux/scripts/Makefile.build:316: mm/memory.o]
> Error 1
> make[1]: *** [/home/dmjordan/src/linux/Makefile:1047: mm] Error 2
>
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/64s/idle: POWER9 ESL=0 stop avoid save/restore overhead
From: Nicholas Piggin @ 2018-03-05 9:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Vaidyanathan Srinivasan, linuxppc-dev, Gautham R . Shenoy
In-Reply-To: <20180304230101.GC14569@fergus.ozlabs.ibm.com>
On Mon, 5 Mar 2018 10:01:01 +1100
Paul Mackerras <paulus@ozlabs.org> wrote:
> On Thu, Mar 01, 2018 at 09:57:34PM +1000, Nicholas Piggin wrote:
> > On Thu, 1 Mar 2018 00:04:39 +0530
> > Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> wrote:
> >
> > > * Nicholas Piggin <npiggin@gmail.com> [2017-11-18 00:08:07]:
> [snip]
> > > > diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c
> > > > index a921d5428d76..610b1637c16f 100644
> > > > --- a/arch/powerpc/platforms/powernv/idle.c
> > > > +++ b/arch/powerpc/platforms/powernv/idle.c
> > > > @@ -621,7 +621,12 @@ static int __init pnv_power9_idle_init(struct device_node *np, u32 *flags,
> > > > continue;
> > > > }
> > > >
> > > > - if (max_residency_ns < residency_ns[i]) {
> > > > + /*
> > > > + * Deepest stop for unplug must be PSSCR[EC]=1 (wakeup at
> > > > + * 0x100.
> > > > + */
> > > > + if ((max_residency_ns < residency_ns[i])&&
> > > > + (psscr_val[i] & PSSCR_EC)) {
> > > > max_residency_ns = residency_ns[i];
> > > > pnv_deepest_stop_psscr_val = psscr_val[i];
> > > > pnv_deepest_stop_psscr_mask = psscr_mask[i];
> > >
> > > If firmware did not provide any ESL=EC=1 state, we can still leave
> > > threads in stop ESL=0 state. This is just a corner case or random
> > > test scenario. Why do we want to enforce that offline cpus really use
> > > a ESL=0 state or just spin?
> >
> > It's because power9_offline_stop only has cases for EC=ESL=1
> > states now.
> >
> > It actually looks like EC=ESL=0 unplug today is broken KVM, because
> > the wakeup side does not check HWTHREAD_REQ, and yet they do set
> > HWTHREAD_IN_IDLE. That would probably hang in KVM if we run with
> > dependent threads, wouldn't it?
>
> Right. KVM with indep_threads_mode=N is broken at the moment if you
> run with powersave=off or if firmware provides no stop states with
> EC=ESL=1. I'm not sure what's the best way to fix that.
For EC=ESL=1, would it be enough to do a test and branch right
after the stop instruction?
> > I think banning it for now should be okay.
>
> Banning what exactly?
power9 CPU unplug using a EC=ESL=0 stop state.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v3 02/10] include: Move compat_timespec/ timeval to compat_time.h
From: Christian Borntraeger @ 2018-03-05 9:30 UTC (permalink / raw)
To: Deepa Dinamani, tglx, john.stultz
Cc: linux-kernel, arnd, y2038, acme, benh, catalin.marinas, cmetcalf,
cohuck, davem, deller, devel, gerald.schaefer, gregkh,
heiko.carstens, hoeppner, hpa, jejb, jwi, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, mark.rutland, mingo, mpe,
oberpar, oprofile-list, paulus, peterz, ralf, rostedt, rric,
schwidefsky, sebott, sparclinux, sth, ubraun, will.deacon, x86
In-Reply-To: <20180116021818.24791-3-deepa.kernel@gmail.com>
On 01/16/2018 03:18 AM, Deepa Dinamani wrote:
> All the current architecture specific defines for these
> are the same. Refactor these common defines to a common
> header file.
>
> The new common linux/compat_time.h is also useful as it
> will eventually be used to hold all the defines that
> are needed for compat time types that support non y2038
> safe types. New architectures need not have to define these
> new types as they will only use new y2038 safe syscalls.
> This file can be deleted after y2038 when we stop supporting
> non y2038 safe syscalls.
You are now include a <linux/*.h> from several asm files
(
arch/arm64/include/asm/stat.h
arch/s390/include/asm/elf.h
arch/x86/include/asm/ftrace.h
arch/x86/include/asm/sys_ia32.h
)
It works, and it is done in many places, but it looks somewhat weird.
Would it make sense to have an asm-generic/compate-time.h instead? Asking for
opinions here.
>
> The patch also requires an operation similar to:
>
> git grep "asm/compat\.h" | cut -d ":" -f 1 | xargs -n 1 sed -i -e "s%asm/compat.h%linux/compat.h%g"
some comments from the s390 perspective:
> --- a/arch/s390/hypfs/hypfs_sprp.c
> +++ b/arch/s390/hypfs/hypfs_sprp.c
ok.
[...]
> --- a/arch/s390/include/asm/elf.h
> +++ b/arch/s390/include/asm/elf.h
> @@ -126,7 +126,7 @@
> */
>
> #include <asm/ptrace.h>
> -#include <asm/compat.h>
> +#include <linux/compat.h>
> #include <asm/syscall.h>
> #include <asm/user.h>
see above.
[...]
> --- a/arch/s390/kvm/priv.c
> +++ b/arch/s390/kvm/priv.c
ok
> --- a/arch/s390/pci/pci_clp.c
> +++ b/arch/s390/pci/pci_clp.c
ok
> --- a/drivers/s390/block/dasd_ioctl.c
> +++ b/drivers/s390/block/dasd_ioctl.c
ok
> --- a/drivers/s390/char/fs3270.c
> +++ b/drivers/s390/char/fs3270.c
ok
> --- a/drivers/s390/char/sclp_ctl.c
> +++ b/drivers/s390/char/sclp_ctl.c
ok
> --- a/drivers/s390/char/vmcp.c
> +++ b/drivers/s390/char/vmcp.c
ok
> --- a/drivers/s390/cio/chsc_sch.c
> +++ b/drivers/s390/cio/chsc_sch.c
ok
> --- a/drivers/s390/net/qeth_core_main.c
> +++ b/drivers/s390/net/qeth_core_main.c
> @@ -32,7 +32,7 @@
> #include <asm/chpid.h>
> #include <asm/io.h>
> #include <asm/sysinfo.h>
> -#include <asm/compat.h>
> +#include <linux/compat.h>
> #include <asm/diag.h>
> #include <asm/cio.h>
> #include <asm/ccwdev.h>
Can you move that into the other includes (where all the other <linux/*> includes are.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/perf: Fix the kernel address leak to userspace via SDAR
From: Naveen N. Rao @ 2018-03-05 8:21 UTC (permalink / raw)
To: Madhavan Srinivasan, mpe; +Cc: linuxppc-dev
In-Reply-To: <1520164518-19097-2-git-send-email-maddy@linux.vnet.ibm.com>
Madhavan Srinivasan wrote:
> Sampled Data Address Register (SDAR) is a 64-bit
> register that contains the effective address of
> the storage operand of an instruction that was
> being executed, possibly out-of-order, at or around
> the time that the Performance Monitor alert occurred.
>=20
> In certain scenario SDAR happen to contain the kernel
> address even for userspace only sampling. Add checks
> to prevent it.
>=20
> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> ---
> arch/powerpc/perf/core-book3s.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>=20
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-boo=
k3s.c
> index 337db5831749..c4525323d691 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -95,7 +95,7 @@ static inline unsigned long perf_ip_adjust(struct pt_re=
gs *regs)
> {
> return 0;
> }
> -static inline void perf_get_data_addr(struct pt_regs *regs, u64 *addrp) =
{ }
> +static inline void perf_get_data_addr(struct pt_regs *regs, u64 *addrp, =
struct perf_event *event) { }
> static inline u32 perf_get_misc_flags(struct pt_regs *regs)
> {
> return 0;
> @@ -174,7 +174,7 @@ static inline unsigned long perf_ip_adjust(struct pt_=
regs *regs)
> * pointed to by SIAR; this is indicated by the [POWER6_]MMCRA_SDSYNC, t=
he
> * [POWER7P_]MMCRA_SDAR_VALID bit in MMCRA, or the SDAR_VALID bit in SIE=
R.
> */
> -static inline void perf_get_data_addr(struct pt_regs *regs, u64 *addrp)
> +static inline void perf_get_data_addr(struct pt_regs *regs, u64 *addrp, =
struct perf_event *event)
> {
> unsigned long mmcra =3D regs->dsisr;
> bool sdar_valid;
> @@ -198,6 +198,11 @@ static inline void perf_get_data_addr(struct pt_regs=
*regs, u64 *addrp)
>=20
> if (!(mmcra & MMCRA_SAMPLE_ENABLE) || sdar_valid)
> *addrp =3D mfspr(SPRN_SDAR);
> +
> + if (perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN) &&
> + (event->attr.exclude_kernel || event->attr.exclude_hv) &&
I may be missing something, but if !capable(CAP_SYS_ADMIN), should we=20
still check the exclude_kernel/exclude_hv fields in the event attribute? =20
Aren't those user controlled?
- Naveen
> + is_kernel_addr(mfspr(SPRN_SDAR)))
> + *addrp =3D 0;
> }
>=20
> static bool regs_sihv(struct pt_regs *regs)
> @@ -2054,7 +2059,7 @@ static void record_and_restart(struct perf_event *e=
vent, unsigned long val,
>=20
> if (event->attr.sample_type &
> (PERF_SAMPLE_ADDR | PERF_SAMPLE_PHYS_ADDR))
> - perf_get_data_addr(regs, &data.addr);
> + perf_get_data_addr(regs, &data.addr, event);
>=20
> if (event->attr.sample_type & PERF_SAMPLE_BRANCH_STACK) {
> struct cpu_hw_events *cpuhw;
> --=20
> 2.7.4
>=20
>=20
=
^ 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