[PATCH] powerpc/64s: fix may_hard_irq_enable for PMI soft masking
The soft IRQ masking code has to hard-disable interrupts in cases
where the exception is not cleared by the masked handler. External
interrupts used this approach for soft masking. Now recently PMU
interrupts do the same thing.
The soft IRQ masking code additionally allowed for interrupt handlers
to hard-enable interrupts after soft-disabling them. The idea is to
allow PMU interrupts through to profile interrupt handlers.
So when interrupts are being replayed when there is a pending
interrupt that requires hard-disabling, there is a test to prevent
those handlers from hard-enabling them if there is a pending external
interrupt. may_hard_irq_enable() handles this.
After f442d00480 ("powerpc/64s: Add support to mask perf interrupts
and replay them"), may_hard_irq_enable() could prematurely enable
MSR[EE] when a PMU exception exists, which would result in the
interrupt firing again while masked, and MSR[EE] being disabled again.
I haven't seen that this could cause a serious problem, but it's
more consistent to handle these soft-masked interrupts in the same
way. So introduce a define for all types of interrupts that require
MSR[EE] masking in their soft-disable handlers, and use that in
may_hard_irq_enable().
Cc: Madhavan Srinivasan
Signed-off-by: Nicholas Piggin
---
Hi,
A review of this would be helpful. I think it probably might as well
go into 4.16 unless I misunderstood the code. My changelog got a bit
long-winded in the end, I could try improve it if it's hard to
understand.
Thanks,
Nick
arch/powerpc/include/asm/hw_irq.h| 12 +++-
arch/powerpc/kernel/exceptions-64e.S | 2 ++
arch/powerpc/kernel/exceptions-64s.S | 6 +++---
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/hw_irq.h
b/arch/powerpc/include/asm/hw_irq.h
index 88e5e8f17e98..855e17d158b1 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -29,6 +29,16 @@
#define PACA_IRQ_HMI 0x20
#define PACA_IRQ_PMI 0x40
+/*
+ * Some soft-masked interrupts must be hard masked until they are replayed
+ * (e.g., because the soft-masked handler does not clear the exception).
+ */
+#ifdef CONFIG_PPC_BOOK3S
+#define PACA_IRQ_MUST_HARD_MASK(PACA_IRQ_EE|PACA_IRQ_PMI)
+#else
+#define PACA_IRQ_MUST_HARD_MASK(PACA_IRQ_EE)
+#endif
+
/*
* flags for paca->irq_soft_mask
*/
@@ -244,7 +254,7 @@ static inline bool lazy_irq_pending(void)
static inline void may_hard_irq_enable(void)
{
get_paca()->irq_happened &= ~PACA_IRQ_HARD_DIS;
- if (!(get_paca()->irq_happened & PACA_IRQ_EE))
+ if (!(get_paca()->irq_happened & PACA_IRQ_MUST_HARD_MASK))
__hard_irq_enable();
}
diff --git a/arch/powerpc/kernel/exceptions-64e.S
b/arch/powerpc/kernel/exceptions-64e.S
index ee832d344a5a..9b6e653e501a 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -943,6 +943,8 @@ kernel_dbg_exc:
/*
* An interrupt came in while soft-disabled; We mark paca->irq_happened
* accordingly and if the interrupt is level sensitive, we hard disable
+ * hard disable (full_mask) corresponds to PACA_IRQ_MUST_HARD_MASK, so
+ * keep these in synch.
*/
.macro masked_interrupt_book3e paca_irq full_mask
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index 243d072a225a..3ac87e53b3da 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1426,7 +1426,7 @@ EXC_COMMON_BEGIN(soft_nmi_common)
* triggered and won't automatically refire.
* - If it was a HMI we return immediately since we handled it in realmode
* and it won't refire.
- * - else we hard disable and return.
+ * - Else it is one of PACA_IRQ_MUST_HARD_MASK, so hard disable and return.
* This is called with r10 containing the value to OR to the paca field.
*/
#define MASKED_INTERRUPT(_H) \
@@ -1441,8 +1441,8 @@ masked_##_H##interrupt:
\
ori r10,r10,0x; \
mtspr SPRN_DEC,r10; \
b MASKED_DEC_HANDLER_LABEL; \
-1: andi. r10,r10,(PACA_IRQ_DBELL|PACA_IRQ_HMI); \
- bne 2f; \
+1: andi. r10,r10,PACA_IRQ_MUST_HARD_MASK;\
+ beq 2f; \
mfspr r10,SPRN_##_H##SRR1;\
xorir10,r10,MSR_EE; /* clear MSR_EE */ \
mtspr SPRN_##_H##SRR1,r10;\
--
2.15.1
[PATCH] powerpc/64s/radix: remove unused flush_tlb_lpid variants
These were intended for use by KVM, but it has its own LPID
flushing code and never used these.
Cc: Aneesh Kumar K.V
Signed-off-by: Nicholas Piggin
---
.../powerpc/include/asm/book3s/64/tlbflush-radix.h | 3 --
arch/powerpc/mm/tlb-radix.c| 40 --
2 files changed, 43 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
index 8eea90f80e45..19b45ba6caf9 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
@@ -47,9 +47,6 @@ extern void radix__flush_tlb_page_psize(struct mm_struct *mm,
unsigned long vmad
#endif
extern void radix__flush_tlb_pwc(struct mmu_gather *tlb, unsigned long addr);
extern void radix__flush_tlb_collapsed_pmd(struct mm_struct *mm, unsigned long
addr);
-extern void radix__flush_tlb_lpid_va(unsigned long lpid, unsigned long gpa,
-unsigned long page_size);
-extern void radix__flush_tlb_lpid(unsigned long lpid);
extern void radix__flush_tlb_all(void);
extern void radix__flush_tlb_pte_p9_dd1(unsigned long old_pte, struct
mm_struct *mm,
unsigned long address);
diff --git a/arch/powerpc/mm/tlb-radix.c b/arch/powerpc/mm/tlb-radix.c
index 71d1b19ad1c0..8ce858ec59e1 100644
--- a/arch/powerpc/mm/tlb-radix.c
+++ b/arch/powerpc/mm/tlb-radix.c
@@ -603,46 +603,6 @@ void radix__flush_tlb_collapsed_pmd(struct mm_struct *mm,
unsigned long addr)
}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
-void radix__flush_tlb_lpid_va(unsigned long lpid, unsigned long gpa,
- unsigned long page_size)
-{
- unsigned long rb,rs,prs,r;
- unsigned long ap;
- unsigned long ric = RIC_FLUSH_TLB;
-
- ap = mmu_get_ap(radix_get_mmu_psize(page_size));
- rb = gpa & ~(PPC_BITMASK(52, 63));
- rb |= ap << PPC_BITLSHIFT(58);
- rs = lpid & ((1UL << 32) - 1);
- prs = 0; /* process scoped */
- r = 1; /* raidx format */
-
- asm volatile("ptesync": : :"memory");
- asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
-: : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(rs) :
"memory");
- asm volatile("eieio; tlbsync; ptesync": : :"memory");
- trace_tlbie(lpid, 0, rb, rs, ric, prs, r);
-}
-EXPORT_SYMBOL(radix__flush_tlb_lpid_va);
-
-void radix__flush_tlb_lpid(unsigned long lpid)
-{
- unsigned long rb,rs,prs,r;
- unsigned long ric = RIC_FLUSH_ALL;
-
- rb = 0x2 << PPC_BITLSHIFT(53); /* IS = 2 */
- rs = lpid & ((1UL << 32) - 1);
- prs = 0; /* partition scoped */
- r = 1; /* raidx format */
-
- asm volatile("ptesync": : :"memory");
- asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
-: : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(rs) :
"memory");
- asm volatile("eieio; tlbsync; ptesync": : :"memory");
- trace_tlbie(lpid, 0, rb, rs, ric, prs, r);
-}
-EXPORT_SYMBOL(radix__flush_tlb_lpid);
-
void radix__flush_pmd_tlb_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end)
{
--
2.15.1
Re: [PATCH (skiboot)] dt: add /cpus/ibm,powerpc-cpu-features device tree bindings
On Sat, 3 Feb 2018 14:27:32 +1000 Nicholas Piggin wrote: > diff --git a/core/cpufeatures.c b/core/cpufeatures.c > new file mode 100644 > index 0..ca9df91f0 > --- /dev/null > +++ b/core/cpufeatures.c > @@ -0,0 +1,932 @@ > +/* Copyright 2017 IBM Corp. > + * > + * Licensed under the Apache License, Version 2.0 (the "License"); > + * you may not use this file except in compliance with the License. > + * You may obtain a copy of the License at > + * > + * http://www.apache.org/licenses/LICENSE-2.0 > + * > + * Unless required by applicable law or agreed to in writing, software > + * distributed under the License is distributed on an "AS IS" BASIS, > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > + * implied. > + * See the License for the specific language governing permissions and > + * limitations under the License. > + */ > + > +/* > + * This file deals with setup of /cpus/ibm,powerpc-cpu-features dt > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#define DEBUG Sorry, didn't send the right version after testing. This line should be deleted before going upstream. Thanks, Nick
[PATCH (skiboot)] dt: add /cpus/ibm, powerpc-cpu-features device tree bindings
This is a new CPU feature advertising interface that is fine-grained,
extensible, aware of privilege levels, and gives control of features
to all levels of the stack (firmware, hypervisor, and OS).
The design and binding specification is described in detail in doc/.
Signed-off-by: Nicholas Piggin
---
core/Makefile.inc | 2 +-
core/cpufeatures.c | 932 +
core/device.c | 7 +
core/init.c| 1 +
.../ibm,powerpc-cpu-features/binding.txt | 245 ++
.../ibm,powerpc-cpu-features/design.txt| 157
include/device.h | 1 +
include/skiboot.h | 5 +
8 files changed, 1349 insertions(+), 1 deletion(-)
create mode 100644 core/cpufeatures.c
create mode 100644 doc/device-tree/ibm,powerpc-cpu-features/binding.txt
create mode 100644 doc/device-tree/ibm,powerpc-cpu-features/design.txt
diff --git a/core/Makefile.inc b/core/Makefile.inc
index d6a7269fa..5c1205646 100644
--- a/core/Makefile.inc
+++ b/core/Makefile.inc
@@ -9,7 +9,7 @@ CORE_OBJS += vpd.o hostservices.o platform.o nvram.o
nvram-format.o hmi.o
CORE_OBJS += console-log.o ipmi.o time-utils.o pel.o pool.o errorlog.o
CORE_OBJS += timer.o i2c.o rtc.o flash.o sensor.o ipmi-opal.o
CORE_OBJS += flash-subpartition.o bitmap.o buddy.o pci-quirk.o powercap.o psr.o
-CORE_OBJS += pci-dt-slot.o direct-controls.o
+CORE_OBJS += pci-dt-slot.o direct-controls.o cpufeatures.o
ifeq ($(SKIBOOT_GCOV),1)
CORE_OBJS += gcov-profiling.o
diff --git a/core/cpufeatures.c b/core/cpufeatures.c
new file mode 100644
index 0..ca9df91f0
--- /dev/null
+++ b/core/cpufeatures.c
@@ -0,0 +1,932 @@
+/* Copyright 2017 IBM Corp.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ * implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/*
+ * This file deals with setup of /cpus/ibm,powerpc-cpu-features dt
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define DEBUG
+#ifdef DEBUG
+#define DBG(fmt, a...) prlog(PR_DEBUG, "CPUFT: " fmt, ##a)
+#else
+#define DBG(fmt, a...)
+#endif
+
+/* Device-tree visible constants follow */
+#define ISA_V2_07B 2070
+#define ISA_V3_0B 3000
+
+#define USABLE_PR (1U << 0)
+#define USABLE_OS (1U << 1)
+#define USABLE_HV (1U << 2)
+
+#define HV_SUPPORT_HFSCR (1U << 0)
+#define OS_SUPPORT_FSCR(1U << 0)
+
+/* Following are definitions for the match tables, not the DT binding itself */
+#define ISA_BASE 0
+
+#define HV_NONE0
+#define HV_CUSTOM 1
+#define HV_HFSCR 2
+
+#define OS_NONE0
+#define OS_CUSTOM 1
+#define OS_FSCR2
+
+/* CPU bitmasks for match table */
+#define CPU_P8_DD1 (1U << 0)
+#define CPU_P8_DD2 (1U << 1)
+#define CPU_P9_DD1 (1U << 2)
+#define CPU_P9_DD2 (1U << 3)
+
+#define CPU_P8 (CPU_P8_DD1|CPU_P8_DD2)
+#define CPU_P9 (CPU_P9_DD1|CPU_P9_DD2)
+#define CPU_ALL(CPU_P8|CPU_P9)
+
+struct cpu_feature {
+ const char *name;
+ uint32_t cpus_supported;
+ uint32_t isa;
+ uint32_t usable_privilege;
+ uint32_t hv_support;
+ uint32_t os_support;
+ uint32_t hfscr_bit_nr;
+ uint32_t fscr_bit_nr;
+ uint32_t hwcap_bit_nr;
+ const char *dependencies_names; /* space-delimited names */
+};
+
+/*
+ * The base (or NULL) cpu feature set is the CPU features available
+ * when no child nodes of the /cpus/ibm,powerpc-cpu-features node exist. The
+ * base feature set is POWER8 (ISAv2.07B), less features that are listed
+ * explicitly.
+ *
+ * XXX: currently, the feature dependencies are not necessarily captured
+ * exactly or completely. This is somewhat acceptable because all
+ * implementations must be aware of all these features.
+ */
+static const struct cpu_feature cpu_features_table[] = {
+ /*
+* Big endian as in ISAv2.07B, MSR_LE=0
+*/
+ { "big-endian",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+* Little endian as in ISAv2.07B, MSR_LE=1.
+*
+* When both big and little endian are defined, there is an LPCR ILE
+* bit and implementation specific way to switch HILE mode, MSR_SLE,
+* etc.
+*/
+ { "littl
Re: [PATCH v5 0/1] Implements MMIO emulation for lvx/stvx instructions
On Fri, Feb 02, 2018 at 11:30:18AM +1100, Paul Mackerras wrote:
> On Thu, Feb 01, 2018 at 04:15:38PM -0200, Jose Ricardo Ziviani wrote:
> > v5:
> > - Fixed the mask off of the effective address
> >
> > v4:
> > - Changed KVM_MMIO_REG_VMX to 0xc0 because there are 64 VSX registers
> >
> > v3:
> > - Added Reported-by in the commit message
> >
> > v2:
> > - kvmppc_get_vsr_word_offset() moved back to its original place
> > - EA AND ~0xF, following ISA.
> > - fixed BE/LE cases
> >
> > TESTS:
> >
> > For testing purposes I wrote a small program that performs stvx/lvx using
> > the
> > program's virtual memory and using MMIO. Load/Store into virtual memory is
> > the
> > model I use to check if MMIO results are correct (because only MMIO is
> > emulated
> > by KVM).
>
> I'd be interested to see your test program because in my testing it's
> still not right, unfortunately. Interestingly, it is right for the BE
> guest on LE host case. However, with a LE guest on a LE host the two
> halves are swapped, both for lvx and stvx:
Absolutely, here it's:
https://gist.github.com/jrziviani/a65e71c5d661bffa8afcd6710fedd520
It basically maps an IO region and also allocates some memory from the
program's address space. Then I store to/load from both addresses and
compare the results. Because only the mmio load/store are emulated, I
use the regular load/store as a model.
>
> error in lvx at byte 0
> was: -> 62 69 70 77 7e 85 8c 93 2a 31 38 3f 46 4d 54 5b
> ref: -> 2a 31 38 3f 46 4d 54 5b 62 69 70 77 7e 85 8c 93
> error in stvx at byte 0
> was: -> 49 50 57 5e 65 6c 73 7a 11 18 1f 26 2d 34 3b 42
> ref: -> 11 18 1f 26 2d 34 3b 42 49 50 57 5e 65 6c 73 7a
>
> The byte order within each 8-byte half is correct but the two halves
> are swapped. ("was" is what was in memory and "ref" is the correct
> value. For lvx it does lvx from emulated MMIO and stvx to ordinary
> memory, and for stvx it does lvx from ordinary memory and stvx to
> emulated MMIO. In both cases the checking is done with a byte by byte
> comparison.)
The funny thing is that I still see it right in both cases, so I believe
that my test case is incorrect. Example (host LE, guest LE):
> VR0 after lvx
(gdb) p $vr0
{uint128 = 0x1234567887654321, v4_float = {
-1.72477726e-34, -3.03283305e-13, 1.46555735e+13, 5.69045661e-28},
v4_int32 = {-2023406815, -1431651397, 1431651396, 305419896}, v8_int16 = {
17185, -30875, -17477, -21846, 17476, 21845, 22136, 4660}, v16_int8 = {33,
67, 101, -121, -69, -69, -86, -86, 68, 68, 85, 85, 120, 86, 52, 18}}
address: 0x10030010
0x1234567887654321
> VR0 after lvx from MMIO
(gdb) p $vr0
$3 = {uint128 = 0x1234567887654321, v4_float = {
-1.72477726e-34, -3.03283305e-13, 1.46555735e+13, 5.69045661e-28},
v4_int32 = {-2023406815, -1431651397, 1431651396, 305419896}, v8_int16 = {
17185, -30875, -17477, -21846, 17476, 21845, 22136, 4660}, v16_int8 = {33,
67, 101, -121, -69, -69, -86, -86, 68, 68, 85, 85, 120, 86, 52, 18}}
io_address: 0x3fffb7f7
0x1234567887654321
I only see it wrong when I mess with copy order:
if (vcpu->arch.mmio_vmx_copy_nums == /*from 1 to */ 2) {
VCPU_VSX_VR(vcpu, index).u[kvmppc_get_vsr_word_offset(2)] = lo;
VCPU_VSX_VR(vcpu, index).u[kvmppc_get_vsr_word_offset(3)] = hi;
} else if (vcpu->arch.mmio_vmx_copy_nums == /*from 2 to */ 1) {
VCPU_VSX_VR(vcpu, index).u[kvmppc_get_vsr_word_offset(0)] = lo;
VCPU_VSX_VR(vcpu, index).u[kvmppc_get_vsr_word_offset(1)] = hi;
}
then I get:
address: 0x1003b530010
0x1234567887654321
io_address: 0x3fff811a
0x8765432112345678
Anyway, your suggestion works great and it's a way more elegant/easy to
understand. I'll send the next version with it.
Thank you very much for your patience and hints that helped me to
understand KVM better. :-)
>
> Paul.
>
Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7
On 2/1/2018 9:29 PM, ebied...@xmission.com wrote: > Khalid Aziz writes: > >> V11 changes: >> This series is same as v10 and was simply rebased on 4.15 kernel. Can >> mm maintainers please review patches 2, 7, 8 and 9 which are arch >> independent, and include/linux/mm.h and mm/ksm.c changes in patch 10 >> and ack these if everything looks good? > > I am a bit puzzled how this differs from the pkey's that other > architectures are implementing to achieve a similar result. > > I am a bit mystified why you don't store the tag in a vma > instead of inventing a new way to store data on page out. > > Can you please use force_sig_fault to send these signals instead > of force_sig_info. Emperically I have found that it is very > error prone to generate siginfo's by hand, especially on code > paths where several different si_codes may apply. So it helps > to go through a helper function to ensure the fiddly bits are > all correct. AKA the unused bits all need to be set to zero before > struct siginfo is copied to userspace. > > Eric The ADI tag can be set at a cacheline (64B) granularity, as opposed to the per-page granularity of pkeys. This allows an object allocator to color each object differently within a page (rounding to 64B boundaries), such that a pointer overrun bug from one object to the next will cause a fault. When pages are paged out, the tags must be saved, hence the new scheme for storing them. One tag per vma is too coarse. The combination of fine granularity and pageability makes for a powerful memory-reference error-detection framework. This was discussed in more detail when earlier patches were submitted, but it's been a while, and the distribution was probably narrower. Khalid can respond to the sig_fault comment. - Steve
Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7
On 02/01/2018 07:29 PM, ebied...@xmission.com wrote: Khalid Aziz writes: V11 changes: This series is same as v10 and was simply rebased on 4.15 kernel. Can mm maintainers please review patches 2, 7, 8 and 9 which are arch independent, and include/linux/mm.h and mm/ksm.c changes in patch 10 and ack these if everything looks good? I am a bit puzzled how this differs from the pkey's that other architectures are implementing to achieve a similar result. I am a bit mystified why you don't store the tag in a vma instead of inventing a new way to store data on page out. Hello Eric, As Steven pointed out, sparc sets tags per cacheline unlike pkey. This results in much finer granularity for tags that pkey and hence requires larger tag storage than what we can do in a vma. Can you please use force_sig_fault to send these signals instead of force_sig_info. Emperically I have found that it is very error prone to generate siginfo's by hand, especially on code paths where several different si_codes may apply. So it helps to go through a helper function to ensure the fiddly bits are all correct. AKA the unused bits all need to be set to zero before struct siginfo is copied to userspace. What you say makes sense. I followed the same code as other fault handlers for sparc. I could change just the fault handlers for ADI related faults. Would it make more sense to change all the fault handlers in a separate patch and keep the code in arch/sparc/kernel/traps_64.c consistent? Dave M, do you have a preference? Thanks, Khalid
[GIT PULL] Please pull powerpc/linux.git powerpc-4.16-1 tag
Hi Linus,
Please pull powerpc updates for 4.16.
We've added a new driver in drivers/misc, which Greg was OK for us to
merge via powerpc, though it has still resulted in a trivial
conflict in the Makefile and Kconfig.
There's also a conflict with the nvdimm tree, which you haven't merged
yet AFIACS, but also trivial (just take our deletion), and Dan is aware
of it.
And there's one change to non-powerpc PCI code, in aerdrv_core.c, which
was acked by Bjorn.
cheers
The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215:
Linux 4.15-rc2 (2017-12-03 11:01:47 -0500)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
tags/powerpc-4.16-1
for you to fetch changes up to 015eb1b89e959c9349f0a01803fb8ed1ced36f09:
powerpc/mm/radix: Fix build error when RADIX_MMU=n (2018-01-30 20:41:30 +1100)
powerpc updates for 4.16
Highlights:
- Enable support for memory protection keys aka "pkeys" on Power7/8/9 when
using the hash table MMU.
- Extend our interrupt soft masking to support masking PMU interrupts as well
as "normal" interrupts, and then use that to implement local_t for a ~4x
speedup vs the current atomics-based implementation.
- A new driver "ocxl" for "Open Coherent Accelerator Processor Interface
(OpenCAPI)" devices.
- Support for new device tree properties on PowerVM to describe hotpluggable
memory and devices.
- Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE to the 64-bit VDSO.
- Freescale updates from Scott:
"Contains fixes for CPM GPIO and an FSL PCI erratum workaround, plus a
minor cleanup patch."
As well as quite a lot of other changes all over the place, and small fixes and
cleanups as always.
Thanks to:
Alan Modra, Alastair D'Silva, Alexey Kardashevskiy, Alistair Popple, Andreas
Schwab, Andrew Donnellan, Aneesh Kumar K.V, Anju T Sudhakar, Anshuman
Khandual, Anton Blanchard, Arnd Bergmann, Balbir Singh, Benjamin
Herrenschmidt, Bhaktipriya Shridhar, Bryant G. Ly, Cédric Le Goater,
Christophe Leroy, Christophe Lombard, Cyril Bur, David Gibson, Desnes A. Nunes
do Rosario, Dmitry Torokhov, Frederic Barrat, Geert Uytterhoeven, Guilherme G.
Piccoli, Gustavo A. R. Silva, Gustavo Romero, Ivan Mikhaylov, Joakim
Tjernlund, Joe Perches, Josh Poimboeuf, Juan J. Alvarez, Julia Cartwright,
Kamalesh Babulal, Madhavan Srinivasan, Mahesh Salgaonkar, Mathieu Malaterre,
Michael Bringmann, Michael Hanselmann, Michael Neuling, Nathan Fontenot,
Naveen N. Rao, Nicholas Piggin, Paul Mackerras, Philippe Bergheaud, Ram Pai,
Russell Currey, Santosh Sivaraj, Scott Wood, Seth Forshee, Simon Guo, Stewart
Smith, Sukadev Bhattiprolu, Thiago Jung Bauermann, Vaibhav Jain, Vasyl
Gomonovych.
Alan Modra (1):
powerpc/modules: Fix alignment of .toc section in kernel modules
Alexey Kardashevskiy (2):
powerpc/powernv/ioda: Finish removing explicit max window size check
powerpc/powernv/idoa: Remove unnecessary pcidev from pci_dn
Andreas Schwab (1):
macintosh/adb: Properly mark continued kernel messages
Andrew Donnellan (2):
selftests/powerpc: Add alignment handler selftest
powerpc/powernv: Set correct configuration space size for opencapi devices
Aneesh Kumar K.V (6):
powerpc/mm/hugetlb: Use pte_access_permitted for hugetlb access check
powerpc/mm/book3s/64: Add proper pte access check helper
powerpc/mm: Add proper pte access check helper for other platforms
powerpc/mm: Remove unused flag arg in global_invalidates
powerpc/hash: Skip non initialized page size in init_hpte_page_sizes
selftest/powerpc: Add additional option to mmap_bench test
Anju T Sudhakar (5):
powerpc/perf: Remove thread_imc_pmu global variable from
powerpc/perf: IMC code cleanup with some code refactoring
powerpc/perf: Pass struct imc_events as a parameter to imc_parse_event()
powerpc/powernv: Add debugfs interface for imc-mode and imc-command
powerpc/perf: Change the data type for the variable 'ncpu' in IMC code
Anshuman Khandual (1):
powerpc/mm: Invalidate subpage_prot() system call on radix platforms
Anton Blanchard (1):
powerpc: Expose TSCR via sysfs
Arnd Bergmann (2):
powerpc/mpic_timer: avoid struct timeval
powerpc/spufs: use timespec64 for timestamps
Balbir Singh (2):
powerpc/crash: Remove the test for cpu_online in the IPI callback
powernv/kdump: Fix cases where the kdump kernel can get HMI's
Benjamin Herrenschmidt (10):
powerpc: Remove DEBUG define in 64-bit early setup code
powerpc: Reduce log level of "OPAL detected !" message
powerpc/xive: Move definition of ESB bits
powerpc/xive: Add interrupt flag to disable automatic EOI
powerpc: Add aacraid and nvme to powernv_defconfig
powerpc: Make newline in c
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.16-1 tag
Hmm. This adds a static inline void pci_uevent_ers(struct pci_dev *pdev, .. to include/linux/pci.h. Why? You do realize that that header file is included by almost every driver out there. Why is that magical function *so* important that it needs to be an inline function, and those strings etc duplicated in every user? Yes, that header file is already full of random inline functions, but they are generally wrapper functions that don't really do anything, and in many cases ithey are also basically configurable to really do nothing at all so that the compiler can remove all trace of something that isn't enabled. This function, in contrast, is simply not that at all. I see literally _zero_ reason why it should be an inline in a really core file. It's not important. It's not performance critical. It's not even used by any core drivers. I pulled this, but honestly, this part was *GARBAGE*. I'm used to people always thinking that *their* code is so important that it needs to be front and center, but this is just ridiculous shit. Get it fixed. Linus
Re: [ppc32] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dmam_alloc_coherent+0xd8/0x118
On Fri, Feb 02, 2018 at 07:06:14PM +0100, Mathieu Malaterre wrote: > On Fri, Feb 2, 2018 at 6:46 PM, Christoph Hellwig wrote: > > On Fri, Feb 02, 2018 at 02:11:33PM +0100, Mathieu Malaterre wrote: > >> Hi there, > >> > >> What is this warning all about (system is Mac Mini G4) ? Thanks > > > > What kernel version is this? > > I've synced with git/master this morning Ok, that means it is the warning for the lack of a coherent dma mask. Seems like the macio bus isn't setting a proper coherent mask.
Re: [ppc32] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dmam_alloc_coherent+0xd8/0x118
On Fri, Feb 2, 2018 at 6:46 PM, Christoph Hellwig wrote: > On Fri, Feb 02, 2018 at 02:11:33PM +0100, Mathieu Malaterre wrote: >> Hi there, >> >> What is this warning all about (system is Mac Mini G4) ? Thanks > > What kernel version is this? I've synced with git/master this morning $ uname -a Linux debian 4.15.0+ #335 Fri Feb 2 15:17:38 CET 2018 ppc GNU/Linux
Re: [PATCH, net] ibmvnic: fix firmware version when no firmware level has been provided by the VIOS server
On 02/02/2018 06:37 AM, Desnes Augusto Nunes do Rosário wrote:
> Hello Tyrel,
>
> I concur with your observations, but since this patch has already been
> merged, I'll address them in another patch.
Fair enough. I didn't realize David had already merged it till after I sent my
review.
-Tyrel
>
> Thank you for your review,
>
> On 02/01/2018 07:02 PM, Tyrel Datwyler wrote:
>> On 02/01/2018 10:04 AM, Desnes Augusto Nunes do Rosario wrote:
>>> Older versions of VIOS servers do not send the firmware level in the VPD
>>> buffer for the ibmvnic driver. Thus, not only the current message is mis-
>>> leading but the firmware version in the ethtool will be NULL. Therefore,
>>> this patch fixes the firmware string and its warning.
>>>
>>> Fixes: 4e6759be28e4 ("ibmvnic: Feature implementation of VPD for the
>>> ibmvnic driver")
>>>
>>> Signed-off-by: Desnes A. Nunes do Rosario
>>> ---
>>> drivers/net/ethernet/ibm/ibmvnic.c | 6 +-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
>>> b/drivers/net/ethernet/ibm/ibmvnic.c
>>> index b65f5f3ac034..2b3e71b63a7a 100644
>>> --- a/drivers/net/ethernet/ibm/ibmvnic.c
>>> +++ b/drivers/net/ethernet/ibm/ibmvnic.c
>>> @@ -3290,7 +3290,11 @@ static void handle_vpd_rsp(union ibmvnic_crq *crq,
>>> */
>>> substr = strnstr(adapter->vpd->buff, "RM", adapter->vpd->len);
>>> if (!substr) {
>>> - dev_info(dev, "No FW level provided by VPD\n");
>>> + dev_info(dev, "Warning - No FW level has been provided in the VPD
>>> buffer by the VIOS Server\n");
>>> + ptr = strncpy((char *)adapter->fw_version, "N/A",
>>
>> Is "N/A" the right thing to report? Would something like "Unknown" or
>> "Unreported" be better?
>>
>>> + 3 * sizeof(char));
>>> + if (!ptr)
>>> + dev_err(dev, "Failed to inform that firmware version is
>>> unavailable to the adapter\n");
>>
>> The sentence structure here seems awkward. I would probably just get rid of
>> this error and this one later in the function.
>>
>> dev_err(dev, "Failed to isolate FW level string\n");
>>
>> Instead just check and report if adapter->fw_version == NULL in the
>> complete: label section.
>>
>> -Tyrel
>>
>>> goto complete;
>>> }
>>>
>>
>
Re: [PATCH 22/34] dma-mapping: add an arch_dma_supported hook
On 01/12/2018 12:42 AM, Christoph Hellwig wrote: > To implement the x86 forbid_dac and iommu_sac_force we want an arch hook > so that it can apply the global options across all dma_map_ops > implementations. > > Signed-off-by: Christoph Hellwig > --- > arch/x86/include/asm/dma-mapping.h | 3 +++ > arch/x86/kernel/pci-dma.c | 19 --- > include/linux/dma-mapping.h| 11 +++ > 3 files changed, 26 insertions(+), 7 deletions(-) > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > index 88bcb1a8211d..d67742dad904 100644 > --- a/include/linux/dma-mapping.h > +++ b/include/linux/dma-mapping.h > @@ -576,6 +576,14 @@ static inline int dma_mapping_error(struct device *dev, > dma_addr_t dma_addr) > return 0; > } > > +/* > + * This is a hack for the legacy x86 forbid_dac and iommu_sac_force. Please > + * don't use this is new code. in new code. > + */ > +#ifndef arch_dma_supported > +#define arch_dma_supported(dev, mask)(1) > +#endif -- ~Randy
Re: [ppc32] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dmam_alloc_coherent+0xd8/0x118
On Fri, Feb 02, 2018 at 02:11:33PM +0100, Mathieu Malaterre wrote: > Hi there, > > What is this warning all about (system is Mac Mini G4) ? Thanks What kernel version is this?
Re: [PATCH, net] ibmvnic: fix firmware version when no firmware level has been provided by the VIOS server
Hello Tyrel,
I concur with your observations, but since this patch has already been
merged, I'll address them in another patch.
Thank you for your review,
On 02/01/2018 07:02 PM, Tyrel Datwyler wrote:
On 02/01/2018 10:04 AM, Desnes Augusto Nunes do Rosario wrote:
Older versions of VIOS servers do not send the firmware level in the VPD
buffer for the ibmvnic driver. Thus, not only the current message is mis-
leading but the firmware version in the ethtool will be NULL. Therefore,
this patch fixes the firmware string and its warning.
Fixes: 4e6759be28e4 ("ibmvnic: Feature implementation of VPD for the ibmvnic
driver")
Signed-off-by: Desnes A. Nunes do Rosario
---
drivers/net/ethernet/ibm/ibmvnic.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/drivers/net/ethernet/ibm/ibmvnic.c
index b65f5f3ac034..2b3e71b63a7a 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -3290,7 +3290,11 @@ static void handle_vpd_rsp(union ibmvnic_crq *crq,
*/
substr = strnstr(adapter->vpd->buff, "RM", adapter->vpd->len);
if (!substr) {
- dev_info(dev, "No FW level provided by VPD\n");
+ dev_info(dev, "Warning - No FW level has been provided in the VPD
buffer by the VIOS Server\n");
+ ptr = strncpy((char *)adapter->fw_version, "N/A",
Is "N/A" the right thing to report? Would something like "Unknown" or
"Unreported" be better?
+ 3 * sizeof(char));
+ if (!ptr)
+ dev_err(dev, "Failed to inform that firmware version is
unavailable to the adapter\n");
The sentence structure here seems awkward. I would probably just get rid of
this error and this one later in the function.
dev_err(dev, "Failed to isolate FW level string\n");
Instead just check and report if adapter->fw_version == NULL in the complete:
label section.
-Tyrel
goto complete;
}
--
Desnes Augusto Nunes do Rosário
--
Linux Developer - IBM / Brazil
M.Sc. in Electrical and Computer Engineering - UFRN
Re: [PATCH, net] ibmvnic: fix firmware version when no firmware level has been provided by the VIOS server
Hello David,
Thank you for your review and the heads up about protocol.
On 02/01/2018 05:59 PM, David Miller wrote:
From: Desnes Augusto Nunes do Rosario
Date: Thu, 1 Feb 2018 16:04:30 -0200
Older versions of VIOS servers do not send the firmware level in the VPD
buffer for the ibmvnic driver. Thus, not only the current message is mis-
leading but the firmware version in the ethtool will be NULL. Therefore,
this patch fixes the firmware string and its warning.
Fixes: 4e6759be28e4 ("ibmvnic: Feature implementation of VPD for the ibmvnic
driver")
Signed-off-by: Desnes A. Nunes do Rosario
Applied.
Please do not put empty lines between Fixes: and Signed-off-by: and other
tags, all tags are equal and are placed together in an uninterrupted
sequences of consequetive lines.
Thank you.
--
Desnes Augusto Nunes do Rosário
--
Linux Developer - IBM / Brazil
M.Sc. in Electrical and Computer Engineering - UFRN
[ppc32] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dmam_alloc_coherent+0xd8/0x118
Hi there, What is this warning all about (system is Mac Mini G4) ? Thanks [3.265537] pata-macio 0.0002:ata-3: Activating pata-macio chipset KeyLargo ATA-3, Apple bus ID 0 [3.272686] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dmam_alloc_coherent+0xd8/0x118 [3.280031] Modules linked in: [3.283660] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0+ #333 [3.287314] NIP: c0643f5c LR: c0643ec8 CTR: [3.290920] REGS: df4f1c00 TRAP: 0700 Not tainted (4.15.0+) [3.294499] MSR: 00029032 CR: 28228428 XER: 2000 [3.298056] GPR00: c0643ec8 df4f1cb0 df4ee940 de15de50 de15de5c GPR08: c08e4d88 24228484 c0004cc8 GPR16: c0c9 GPR24: c0b4fdd0 c0c3d6e0 de00beec 1020 014000c0 de15de50 de017c18 [3.315308] NIP [c0643f5c] dmam_alloc_coherent+0xd8/0x118 [3.318724] LR [c0643ec8] dmam_alloc_coherent+0x44/0x118 [3.322073] Call Trace: [3.325399] [df4f1cb0] [c0643ec8] dmam_alloc_coherent+0x44/0x118 (unreliable) [3.328858] [df4f1cd0] [c06a5f4c] pata_macio_port_start+0x48/0x98 [3.332294] [df4f1cf0] [c068b25c] ata_host_start.part.9+0x108/0x220 [3.335706] [df4f1d10] [c06912d8] ata_host_activate+0x70/0x15c [3.339084] [df4f1d30] [c06a6a8c] pata_macio_common_init+0x300/0x568 [3.342459] [df4f1d90] [c06a6ef4] pata_macio_attach+0xe4/0x18c [3.345862] [df4f1db0] [c06582bc] macio_device_probe+0x64/0xf8 [3.349218] [df4f1dd0] [c062c5e8] driver_probe_device+0x334/0x4b4 [3.352537] [df4f1e00] [c062c884] __driver_attach+0x11c/0x120 [3.355822] [df4f1e20] [c0629a14] bus_for_each_dev+0x70/0xc0 [3.359074] [df4f1e50] [c062b338] bus_add_driver+0x180/0x2dc [3.362277] [df4f1e70] [c062d620] driver_register+0x94/0x13c [3.365415] [df4f1e80] [c0b937f8] pata_macio_init+0x68/0x90 [3.368474] [df4f1ea0] [c0004af4] do_one_initcall+0x4c/0x178 [3.371471] [df4f1f00] [c0b50774] kernel_init_freeable+0x138/0x1d0 [3.374421] [df4f1f30] [c0004cec] kernel_init+0x24/0x118 [3.377337] [df4f1f40] [c0018304] ret_from_kernel_thread+0x5c/0x64 [3.380249] --- interrupt: 0 at (null) LR = (null) [3.385965] Instruction dump: [3.388713] 7fc4f378 7fe3fb78 93be0004 913e0008 939e 4bfecd79 7fa3eb78 80010024 [3.391513] bb61000c 38210020 7c0803a6 4e800020 <0fe0> 812a 2f89 409eff98 [3.394280] ---[ end trace a4431b67b2b33261 ]--- [3.397425] scsi host1: pata_macio
