* [PATCH v4.4 backport 05/16] powerpc/pseries: Add H_GET_CPU_CHARACTERISTICS flags & wrapper
From: Michael Ellerman @ 2018-02-04 4:59 UTC (permalink / raw)
To: stable, greg; +Cc: linuxppc-dev
In-Reply-To: <20180204050010.13669-1-mpe@ellerman.id.au>
From: Michael Neuling <mikey@neuling.org>
commit 191eccb1580939fb0d47deb405b82a85b0379070 upstream.
A new hypervisor call has been defined to communicate various
characteristics of the CPU to guests. Add definitions for the hcall
number, flags and a wrapper function.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[Balbir fixed conflicts in backport]
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
---
arch/powerpc/include/asm/hvcall.h | 17 +++++++++++++++++
arch/powerpc/include/asm/plpar_wrappers.h | 14 ++++++++++++++
2 files changed, 31 insertions(+)
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index 85bc8c0d257b..51adbde09845 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -239,6 +239,7 @@
#define H_GET_HCA_INFO 0x1B8
#define H_GET_PERF_COUNT 0x1BC
#define H_MANAGE_TRACE 0x1C0
+#define H_GET_CPU_CHARACTERISTICS 0x1C8
#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
#define H_QUERY_INT_STATE 0x1E4
#define H_POLL_PENDING 0x1D8
@@ -285,6 +286,17 @@
#define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE 3
#define H_SET_MODE_RESOURCE_LE 4
+/* H_GET_CPU_CHARACTERISTICS return values */
+#define H_CPU_CHAR_SPEC_BAR_ORI31 (1ull << 63) // IBM bit 0
+#define H_CPU_CHAR_BCCTRL_SERIALISED (1ull << 62) // IBM bit 1
+#define H_CPU_CHAR_L1D_FLUSH_ORI30 (1ull << 61) // IBM bit 2
+#define H_CPU_CHAR_L1D_FLUSH_TRIG2 (1ull << 60) // IBM bit 3
+#define H_CPU_CHAR_L1D_THREAD_PRIV (1ull << 59) // IBM bit 4
+
+#define H_CPU_BEHAV_FAVOUR_SECURITY (1ull << 63) // IBM bit 0
+#define H_CPU_BEHAV_L1D_FLUSH_PR (1ull << 62) // IBM bit 1
+#define H_CPU_BEHAV_BNDS_CHK_SPEC_BAR (1ull << 61) // IBM bit 2
+
#ifndef __ASSEMBLY__
/**
@@ -423,6 +435,11 @@ extern long pseries_big_endian_exceptions(void);
#endif /* CONFIG_PPC_PSERIES */
+struct h_cpu_char_result {
+ u64 character;
+ u64 behaviour;
+};
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h b/arch/powerpc/include/asm/plpar_wrappers.h
index 67859edbf8fd..6e05cb397a5c 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -323,4 +323,18 @@ static inline long plapr_set_watchpoint0(unsigned long dawr0, unsigned long dawr
return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR, dawr0, dawrx0);
}
+static inline long plpar_get_cpu_characteristics(struct h_cpu_char_result *p)
+{
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+ long rc;
+
+ rc = plpar_hcall(H_GET_CPU_CHARACTERISTICS, retbuf);
+ if (rc == H_SUCCESS) {
+ p->character = retbuf[0];
+ p->behaviour = retbuf[1];
+ }
+
+ return rc;
+}
+
#endif /* _ASM_POWERPC_PLPAR_WRAPPERS_H */
--
2.14.1
^ permalink raw reply related
* [PATCH v4.4 backport 04/16] powerpc: Simplify module TOC handling
From: Michael Ellerman @ 2018-02-04 4:59 UTC (permalink / raw)
To: stable, greg; +Cc: linuxppc-dev
In-Reply-To: <20180204050010.13669-1-mpe@ellerman.id.au>
From: Alan Modra <amodra@gmail.com>
commit c153693d7eb9eeb28478aa2deaaf0b4e7b5ff5e9 upstream.
PowerPC64 uses the symbol .TOC. much as other targets use
_GLOBAL_OFFSET_TABLE_. It identifies the value of the GOT pointer (or in
powerpc parlance, the TOC pointer). Global offset tables are generally
local to an executable or shared library, or in the kernel, module. Thus
it does not make sense for a module to resolve a relocation against
.TOC. to the kernel's .TOC. value. A module has its own .TOC., and
indeed the powerpc64 module relocation processing ignores the kernel
value of .TOC. and instead calculates a module-local value.
This patch removes code involved in exporting the kernel .TOC., tweaks
modpost to ignore an undefined .TOC., and the module loader to twiddle
the section symbol so that .TOC. isn't seen as undefined.
Note that if the kernel was compiled with -msingle-pic-base then ELFv2
would not have function global entry code setting up r2. In that case
the module call stubs would need to be modified to set up r2 using the
kernel .TOC. value, requiring some of this code to be reinstated.
mpe: Furthermore a change in binutils master (not yet released) causes
the current way we handle the TOC to no longer work when building with
MODVERSIONS=y and RELOCATABLE=n. The symptom is that modules can not be
loaded due to there being no version found for TOC.
Cc: stable@vger.kernel.org # 3.16+
Signed-off-by: Alan Modra <amodra@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/misc_64.S | 28 ----------------------------
arch/powerpc/kernel/module_64.c | 12 +++++++++---
scripts/mod/modpost.c | 3 ++-
3 files changed, 11 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index 415e58565745..107588295b39 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -701,31 +701,3 @@ _GLOBAL(kexec_sequence)
li r5,0
blr /* image->start(physid, image->start, 0); */
#endif /* CONFIG_KEXEC */
-
-#ifdef CONFIG_MODULES
-#if defined(_CALL_ELF) && _CALL_ELF == 2
-
-#ifdef CONFIG_MODVERSIONS
-.weak __crc_TOC.
-.section "___kcrctab+TOC.","a"
-.globl __kcrctab_TOC.
-__kcrctab_TOC.:
- .llong __crc_TOC.
-#endif
-
-/*
- * Export a fake .TOC. since both modpost and depmod will complain otherwise.
- * Both modpost and depmod strip the leading . so we do the same here.
- */
-.section "__ksymtab_strings","a"
-__kstrtab_TOC.:
- .asciz "TOC."
-
-.section "___ksymtab+TOC.","a"
-/* This symbol name is important: it's used by modpost to find exported syms */
-.globl __ksymtab_TOC.
-__ksymtab_TOC.:
- .llong 0 /* .value */
- .llong __kstrtab_TOC.
-#endif /* ELFv2 */
-#endif /* MODULES */
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index e4f7d4eed20c..08b7a40de5f8 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -326,7 +326,10 @@ static void dedotify_versions(struct modversion_info *vers,
}
}
-/* Undefined symbols which refer to .funcname, hack to funcname (or .TOC.) */
+/*
+ * Undefined symbols which refer to .funcname, hack to funcname. Make .TOC.
+ * seem to be defined (value set later).
+ */
static void dedotify(Elf64_Sym *syms, unsigned int numsyms, char *strtab)
{
unsigned int i;
@@ -334,8 +337,11 @@ static void dedotify(Elf64_Sym *syms, unsigned int numsyms, char *strtab)
for (i = 1; i < numsyms; i++) {
if (syms[i].st_shndx == SHN_UNDEF) {
char *name = strtab + syms[i].st_name;
- if (name[0] == '.')
+ if (name[0] == '.') {
+ if (strcmp(name+1, "TOC.") == 0)
+ syms[i].st_shndx = SHN_ABS;
syms[i].st_name++;
+ }
}
}
}
@@ -351,7 +357,7 @@ static Elf64_Sym *find_dot_toc(Elf64_Shdr *sechdrs,
numsyms = sechdrs[symindex].sh_size / sizeof(Elf64_Sym);
for (i = 1; i < numsyms; i++) {
- if (syms[i].st_shndx == SHN_UNDEF
+ if (syms[i].st_shndx == SHN_ABS
&& strcmp(strtab + syms[i].st_name, "TOC.") == 0)
return &syms[i];
}
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index e080746e1a6b..48958d3cec9e 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -594,7 +594,8 @@ static int ignore_undef_symbol(struct elf_info *info, const char *symname)
if (strncmp(symname, "_restgpr0_", sizeof("_restgpr0_") - 1) == 0 ||
strncmp(symname, "_savegpr0_", sizeof("_savegpr0_") - 1) == 0 ||
strncmp(symname, "_restvr_", sizeof("_restvr_") - 1) == 0 ||
- strncmp(symname, "_savevr_", sizeof("_savevr_") - 1) == 0)
+ strncmp(symname, "_savevr_", sizeof("_savevr_") - 1) == 0 ||
+ strcmp(symname, ".TOC.") == 0)
return 1;
/* Do not ignore this symbol */
return 0;
--
2.14.1
^ permalink raw reply related
* [PATCH v4.4 backport 03/16] powerpc: Fix VSX enabling/flushing to also test MSR_FP and MSR_VEC
From: Michael Ellerman @ 2018-02-04 4:59 UTC (permalink / raw)
To: stable, greg; +Cc: linuxppc-dev
In-Reply-To: <20180204050010.13669-1-mpe@ellerman.id.au>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
commit 5a69aec945d27e78abac9fd032533d3aaebf7c1e upstream.
VSX uses a combination of the old vector registers, the old FP
registers and new "second halves" of the FP registers.
Thus when we need to see the VSX state in the thread struct
(flush_vsx_to_thread()) or when we'll use the VSX in the kernel
(enable_kernel_vsx()) we need to ensure they are all flushed into
the thread struct if either of them is individually enabled.
Unfortunately we only tested if the whole VSX was enabled, not if they
were individually enabled.
Fixes: 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx() routine available")
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[mpe: Backported due to changed context]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/process.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index cf788d7d7e56..a9b10812cbfd 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -209,7 +209,8 @@ void enable_kernel_vsx(void)
WARN_ON(preemptible());
#ifdef CONFIG_SMP
- if (current->thread.regs && (current->thread.regs->msr & MSR_VSX))
+ if (current->thread.regs &&
+ (current->thread.regs->msr & (MSR_VSX|MSR_VEC|MSR_FP)))
giveup_vsx(current);
else
giveup_vsx(NULL); /* just enable vsx for kernel - force */
@@ -231,7 +232,7 @@ void flush_vsx_to_thread(struct task_struct *tsk)
{
if (tsk->thread.regs) {
preempt_disable();
- if (tsk->thread.regs->msr & MSR_VSX) {
+ if (tsk->thread.regs->msr & (MSR_VSX|MSR_VEC|MSR_FP)) {
#ifdef CONFIG_SMP
BUG_ON(tsk != current);
#endif
--
2.14.1
^ permalink raw reply related
* [PATCH v4.4 backport 02/16] powerpc/64: Fix flush_(d|i)cache_range() called from modules
From: Michael Ellerman @ 2018-02-04 4:59 UTC (permalink / raw)
To: stable, greg; +Cc: linuxppc-dev
In-Reply-To: <20180204050010.13669-1-mpe@ellerman.id.au>
From: Oliver O'Halloran <oohall@gmail.com>
commit 8f5f525d5b83f7d76a6baf9c4e94d4bf312ea7f6 upstream.
When the kernel is compiled to use 64bit ABIv2 the _GLOBAL() macro does
not include a global entry point. A function's global entry point is
used when the function is called from a different TOC context and in the
kernel this typically means a call from a module into the vmlinux (or
vice-versa).
There are a few exported asm functions declared with _GLOBAL() and
calling them from a module will likely crash the kernel since any TOC
relative load will yield garbage.
flush_icache_range() and flush_dcache_range() are both exported to
modules, and use the TOC, so must use _GLOBAL_TOC().
[mpe: We can't use _GLOBAL_TOC() in 4.4 for flush_icache_range() because
the function needs to be in the .kprobes.text section, which is done by the
_KPROBE() macro. So we have to add a _KPROBE_TOC() macro, which does the TOC
setup and also puts the function in the .kprobes.text section]
Fixes: 721aeaa9fdf3 ("powerpc: Build little endian ppc64 kernel with ABIv2")
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/ppc_asm.h | 12 ++++++++++++
arch/powerpc/kernel/misc_64.S | 4 ++--
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
index dd0fc18d8103..160bb2311bbb 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -224,6 +224,16 @@ name: \
.globl name; \
name:
+#define _KPROBE_TOC(name) \
+ .section ".kprobes.text","a"; \
+ .align 2 ; \
+ .type name,@function; \
+ .globl name; \
+name: \
+0: addis r2,r12,(.TOC.-0b)@ha; \
+ addi r2,r2,(.TOC.-0b)@l; \
+ .localentry name,.-name
+
#define DOTSYM(a) a
#else
@@ -261,6 +271,8 @@ name: \
.type GLUE(.,name),@function; \
GLUE(.,name):
+#define _KPROBE_TOC(n) _KPROBE(n)
+
#define DOTSYM(a) GLUE(.,a)
#endif
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index db475d41b57a..415e58565745 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -66,7 +66,7 @@ PPC64_CACHES:
* flush all bytes from start through stop-1 inclusive
*/
-_KPROBE(flush_icache_range)
+_KPROBE_TOC(flush_icache_range)
BEGIN_FTR_SECTION
PURGE_PREFETCHED_INS
blr
@@ -117,7 +117,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
*
* flush all bytes from start to stop-1 inclusive
*/
-_GLOBAL(flush_dcache_range)
+_GLOBAL_TOC(flush_dcache_range)
/*
* Flush the data cache to memory
--
2.14.1
^ permalink raw reply related
* [PATCH v4.4 backport 01/16] powerpc/bpf/jit: Disable classic BPF JIT on ppc64le
From: Michael Ellerman @ 2018-02-04 4:59 UTC (permalink / raw)
To: stable, greg; +Cc: linuxppc-dev
In-Reply-To: <20180204050010.13669-1-mpe@ellerman.id.au>
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
commit 844e3be47693f92a108cb1fb3b0606bf25e9c7a6 upstream.
Backport required due to rename of HAVE_BPF_JIT to HAVE_CBPF_JIT
upstream - mpe.
Classic BPF JIT was never ported completely to work on little endian
powerpc. However, it can be enabled and will crash the system when used.
As such, disable use of BPF JIT on ppc64le.
Fixes: 7c105b63bd98 ("powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option.")
Reported-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index dfb1ee8c3e06..0c26025e18f9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -129,7 +129,7 @@ config PPC
select IRQ_FORCED_THREADING
select HAVE_RCU_TABLE_FREE if SMP
select HAVE_SYSCALL_TRACEPOINTS
- select HAVE_BPF_JIT
+ select HAVE_BPF_JIT if CPU_BIG_ENDIAN
select HAVE_ARCH_JUMP_LABEL
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_HAS_GCOV_PROFILE_ALL
--
2.14.1
^ permalink raw reply related
* [PATCH v4.4 backport 00/16] powerpc stable backports for v4.4
From: Michael Ellerman @ 2018-02-04 4:59 UTC (permalink / raw)
To: stable, greg; +Cc: linuxppc-dev
Hi Greg,
This is a backport to v4.4 of the RFI flush series that went upstream recently.
There's also a few other commits I noticed had not made it to v4.4 due to
needing manual backports.
cheers
^ permalink raw reply
* [PATCH v6 1/1] KVM: PPC: Book3S: Add MMIO emulation for VMX instructions
From: Jose Ricardo Ziviani @ 2018-02-03 20:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc, paulus, lvivier
In-Reply-To: <20180203202426.5782-1-joserz@linux.vnet.ibm.com>
This patch provides the MMIO load/store vector indexed
X-Form emulation.
Instructions implemented:
lvx: the quadword in storage addressed by the result of EA &
0xffff_ffff_ffff_fff0 is loaded into VRT.
stvx: the contents of VRS are stored into the quadword in storage
addressed by the result of EA & 0xffff_ffff_ffff_fff0.
Reported-by: Gopesh Kumar Chaudhary <gopchaud@in.ibm.com>
Reported-by: Balamuruhan S <bala24@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/kvm_host.h | 2 +
arch/powerpc/include/asm/kvm_ppc.h | 4 +
arch/powerpc/include/asm/ppc-opcode.h | 6 ++
arch/powerpc/kvm/emulate_loadstore.c | 34 ++++++++
arch/powerpc/kvm/powerpc.c | 150 ++++++++++++++++++++++++++++++++++
5 files changed, 196 insertions(+)
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 3aa5b577cd60..045acc843e98 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -690,6 +690,7 @@ struct kvm_vcpu_arch {
u8 mmio_vsx_offset;
u8 mmio_vsx_copy_type;
u8 mmio_vsx_tx_sx_enabled;
+ u8 mmio_vmx_copy_nums;
u8 osi_needed;
u8 osi_enabled;
u8 papr_enabled;
@@ -800,6 +801,7 @@ struct kvm_vcpu_arch {
#define KVM_MMIO_REG_QPR 0x0040
#define KVM_MMIO_REG_FQPR 0x0060
#define KVM_MMIO_REG_VSX 0x0080
+#define KVM_MMIO_REG_VMX 0x00c0
#define __KVM_HAVE_ARCH_WQP
#define __KVM_HAVE_CREATE_DEVICE
diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index 9db18287b5f4..7765a800ddae 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -81,6 +81,10 @@ extern int kvmppc_handle_loads(struct kvm_run *run, struct kvm_vcpu *vcpu,
extern int kvmppc_handle_vsx_load(struct kvm_run *run, struct kvm_vcpu *vcpu,
unsigned int rt, unsigned int bytes,
int is_default_endian, int mmio_sign_extend);
+extern int kvmppc_handle_load128_by2x64(struct kvm_run *run,
+ struct kvm_vcpu *vcpu, unsigned int rt, int is_default_endian);
+extern int kvmppc_handle_store128_by2x64(struct kvm_run *run,
+ struct kvm_vcpu *vcpu, unsigned int rs, int is_default_endian);
extern int kvmppc_handle_store(struct kvm_run *run, struct kvm_vcpu *vcpu,
u64 val, unsigned int bytes,
int is_default_endian);
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index ab5c1588b487..f1083bcf449c 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -156,6 +156,12 @@
#define OP_31_XOP_LFDX 599
#define OP_31_XOP_LFDUX 631
+/* VMX Vector Load Instructions */
+#define OP_31_XOP_LVX 103
+
+/* VMX Vector Store Instructions */
+#define OP_31_XOP_STVX 231
+
#define OP_LWZ 32
#define OP_STFS 52
#define OP_STFSU 53
diff --git a/arch/powerpc/kvm/emulate_loadstore.c b/arch/powerpc/kvm/emulate_loadstore.c
index af833531af31..332b82eafd48 100644
--- a/arch/powerpc/kvm/emulate_loadstore.c
+++ b/arch/powerpc/kvm/emulate_loadstore.c
@@ -58,6 +58,18 @@ static bool kvmppc_check_vsx_disabled(struct kvm_vcpu *vcpu)
}
#endif /* CONFIG_VSX */
+#ifdef CONFIG_ALTIVEC
+static bool kvmppc_check_altivec_disabled(struct kvm_vcpu *vcpu)
+{
+ if (!(kvmppc_get_msr(vcpu) & MSR_VEC)) {
+ kvmppc_core_queue_vec_unavail(vcpu);
+ return true;
+ }
+
+ return false;
+}
+#endif /* CONFIG_ALTIVEC */
+
/*
* XXX to do:
* lfiwax, lfiwzx
@@ -98,6 +110,7 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
vcpu->arch.mmio_vsx_copy_type = KVMPPC_VSX_COPY_NONE;
vcpu->arch.mmio_sp64_extend = 0;
vcpu->arch.mmio_sign_extend = 0;
+ vcpu->arch.mmio_vmx_copy_nums = 0;
switch (get_op(inst)) {
case 31:
@@ -459,6 +472,27 @@ int kvmppc_emulate_loadstore(struct kvm_vcpu *vcpu)
rs, 4, 1);
break;
#endif /* CONFIG_VSX */
+
+#ifdef CONFIG_ALTIVEC
+ case OP_31_XOP_LVX:
+ if (kvmppc_check_altivec_disabled(vcpu))
+ return EMULATE_DONE;
+ vcpu->arch.vaddr_accessed &= ~0xFULL;
+ vcpu->arch.mmio_vmx_copy_nums = 2;
+ emulated = kvmppc_handle_load128_by2x64(run, vcpu,
+ KVM_MMIO_REG_VMX|rt, 1);
+ break;
+
+ case OP_31_XOP_STVX:
+ if (kvmppc_check_altivec_disabled(vcpu))
+ return EMULATE_DONE;
+ vcpu->arch.vaddr_accessed &= ~0xFULL;
+ vcpu->arch.mmio_vmx_copy_nums = 2;
+ emulated = kvmppc_handle_store128_by2x64(run, vcpu,
+ rs, 1);
+ break;
+#endif /* CONFIG_ALTIVEC */
+
default:
emulated = EMULATE_FAIL;
break;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 1915e86cef6f..866e66010303 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -925,6 +925,34 @@ static inline void kvmppc_set_vsr_word(struct kvm_vcpu *vcpu,
}
#endif /* CONFIG_VSX */
+#ifdef CONFIG_ALTIVEC
+static inline void kvmppc_set_vmx_dword(struct kvm_vcpu *vcpu,
+ u64 gpr)
+{
+ int index = vcpu->arch.io_gpr & KVM_MMIO_REG_MASK;
+ u32 hi, lo;
+ u32 di;
+
+#ifdef __BIG_ENDIAN
+ hi = gpr >> 32;
+ lo = gpr & 0xffffffff;
+#else
+ lo = gpr >> 32;
+ hi = gpr & 0xffffffff;
+#endif
+
+ di = 2 - vcpu->arch.mmio_vmx_copy_nums; /* doubleword index */
+ if (di > 1)
+ return;
+
+ if (vcpu->arch.mmio_host_swabbed)
+ di = 1 - di;
+
+ VCPU_VSX_VR(vcpu, index).u[di * 2] = hi;
+ VCPU_VSX_VR(vcpu, index).u[di * 2 + 1] = lo;
+}
+#endif /* CONFIG_ALTIVEC */
+
#ifdef CONFIG_PPC_FPU
static inline u64 sp_to_dp(u32 fprs)
{
@@ -1027,6 +1055,11 @@ static void kvmppc_complete_mmio_load(struct kvm_vcpu *vcpu,
KVMPPC_VSX_COPY_DWORD_LOAD_DUMP)
kvmppc_set_vsr_dword_dump(vcpu, gpr);
break;
+#endif
+#ifdef CONFIG_ALTIVEC
+ case KVM_MMIO_REG_VMX:
+ kvmppc_set_vmx_dword(vcpu, gpr);
+ break;
#endif
default:
BUG();
@@ -1307,6 +1340,111 @@ static int kvmppc_emulate_mmio_vsx_loadstore(struct kvm_vcpu *vcpu,
}
#endif /* CONFIG_VSX */
+#ifdef CONFIG_ALTIVEC
+/* handle quadword load access in two halves */
+int kvmppc_handle_load128_by2x64(struct kvm_run *run, struct kvm_vcpu *vcpu,
+ unsigned int rt, int is_default_endian)
+{
+ enum emulation_result emulated;
+
+ while (vcpu->arch.mmio_vmx_copy_nums) {
+ emulated = __kvmppc_handle_load(run, vcpu, rt, 8,
+ is_default_endian, 0);
+
+ if (emulated != EMULATE_DONE)
+ break;
+
+ vcpu->arch.paddr_accessed += run->mmio.len;
+ vcpu->arch.mmio_vmx_copy_nums--;
+ }
+
+ return emulated;
+}
+
+static inline int kvmppc_get_vmx_data(struct kvm_vcpu *vcpu, int rs, u64 *val)
+{
+ vector128 vrs = VCPU_VSX_VR(vcpu, rs);
+ u32 di;
+ u64 w0, w1;
+
+ di = 2 - vcpu->arch.mmio_vmx_copy_nums; /* doubleword index */
+ if (di > 1)
+ return -1;
+
+ if (vcpu->arch.mmio_host_swabbed)
+ di = 1 - di;
+
+ w0 = vrs.u[di * 2];
+ w1 = vrs.u[di * 2 + 1];
+
+#ifdef __BIG_ENDIAN
+ *val = (w0 << 32) | w1;
+#else
+ *val = (w1 << 32) | w0;
+#endif
+ return 0;
+}
+
+/* handle quadword store in two halves */
+int kvmppc_handle_store128_by2x64(struct kvm_run *run, struct kvm_vcpu *vcpu,
+ unsigned int rs, int is_default_endian)
+{
+ u64 val = 0;
+ enum emulation_result emulated = EMULATE_DONE;
+
+ vcpu->arch.io_gpr = rs;
+
+ while (vcpu->arch.mmio_vmx_copy_nums) {
+ if (kvmppc_get_vmx_data(vcpu, rs, &val) == -1)
+ return EMULATE_FAIL;
+
+ emulated = kvmppc_handle_store(run, vcpu, val, 8,
+ is_default_endian);
+ if (emulated != EMULATE_DONE)
+ break;
+
+ vcpu->arch.paddr_accessed += run->mmio.len;
+ vcpu->arch.mmio_vmx_copy_nums--;
+ }
+
+ return emulated;
+}
+
+static int kvmppc_emulate_mmio_vmx_loadstore(struct kvm_vcpu *vcpu,
+ struct kvm_run *run)
+{
+ enum emulation_result emulated = EMULATE_FAIL;
+ int r;
+
+ vcpu->arch.paddr_accessed += run->mmio.len;
+
+ if (!vcpu->mmio_is_write) {
+ emulated = kvmppc_handle_load128_by2x64(run, vcpu,
+ vcpu->arch.io_gpr, 1);
+ } else {
+ emulated = kvmppc_handle_store128_by2x64(run, vcpu,
+ vcpu->arch.io_gpr, 1);
+ }
+
+ switch (emulated) {
+ case EMULATE_DO_MMIO:
+ run->exit_reason = KVM_EXIT_MMIO;
+ r = RESUME_HOST;
+ break;
+ case EMULATE_FAIL:
+ pr_info("KVM: MMIO emulation failed (VMX repeat)\n");
+ run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
+ run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION;
+ r = RESUME_HOST;
+ break;
+ default:
+ r = RESUME_GUEST;
+ break;
+ }
+ return r;
+}
+#endif /* CONFIG_ALTIVEC */
+
int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
{
int r = 0;
@@ -1425,6 +1563,18 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
return r;
}
}
+#endif
+#ifdef CONFIG_ALTIVEC
+ if (vcpu->arch.mmio_vmx_copy_nums > 0)
+ vcpu->arch.mmio_vmx_copy_nums--;
+
+ if (vcpu->arch.mmio_vmx_copy_nums > 0) {
+ r = kvmppc_emulate_mmio_vmx_loadstore(vcpu, run);
+ if (r == RESUME_HOST) {
+ vcpu->mmio_needed = 1;
+ return r;
+ }
+ }
#endif
} else if (vcpu->arch.osi_needed) {
u64 *gprs = run->osi.gprs;
--
2.14.3
^ permalink raw reply related
* [PATCH v6 0/1] Implements MMIO emulation for lvx/stvx instructions
From: Jose Ricardo Ziviani @ 2018-02-03 20:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc, paulus, lvivier
v6:
- Applied Paul's code suggestion to fix endianess
- Moved kvmppc_get_vsr_dword_offset() back to #ifdef CONFIG_VSX
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).
Results:
HOST LE - GUEST BE
address: 0x10034850010
0x21436587bbbbaaaa4444555578563412
io_address: 0x3fff89a20000
0x21436587bbbbaaaa4444555578563412
HOST LE - GUEST LE
address: 0x10033a20010
0x1234567855554444aaaabbbb87654321
io_address: 0x3fffb5380000
0x1234567855554444aaaabbbb87654321
HOST BE - GUEST BE
address: 0x1002c4a0010
0x21436587bbbbaaaa4444555578563412
io_address: 0x3ffface40000
0x21436587bbbbaaaa4444555578563412
HOST BR - GUEST LE
address: 0x100225e0010
0x1234567855554444aaaabbbb87654321
io_address: 0x3fff7fcb0000
0x1234567855554444aaaabbbb87654321
This patch implements MMIO emulation for two instructions: lvx and stvx.
Jose Ricardo Ziviani (1):
KVM: PPC: Book3S: Add MMIO emulation for VMX instructions
arch/powerpc/include/asm/kvm_host.h | 2 +
arch/powerpc/include/asm/kvm_ppc.h | 4 +
arch/powerpc/include/asm/ppc-opcode.h | 6 ++
arch/powerpc/kvm/emulate_loadstore.c | 34 ++++++++
arch/powerpc/kvm/powerpc.c | 150 ++++++++++++++++++++++++++++++++++
5 files changed, 196 insertions(+)
--
2.14.3
^ permalink raw reply
* Re: [PATCH (skiboot)] dt: add /cpus/ibm, powerpc-cpu-features device tree bindings
From: Segher Boessenkool @ 2018-02-03 15:36 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: skiboot, linuxppc-dev
In-Reply-To: <20180203042732.27980-1-npiggin@gmail.com>
Hi! Some remarks:
On Sat, Feb 03, 2018 at 02:27:32PM +1000, Nicholas Piggin wrote:
> + /*
> + * ISAv3.0B deliver a random number instruction (darn)
> + */
> + { "random-number-generator",
That's not such a great name... "darn-instruction" maybe? Just "wait"
as a name is a bit too short too I guess (and there is "wait-v3", so
that could be "wait-v2" or so? Or "wait-instruction").
> + /*
> + * ISAv3.0B branch instruction and register additions
> + * CA32, OV32, mcrxrx, setb
> + */
> + { "branch-v3",
Those aren't branch instructions, they are integer instructions. Some
of which use the XER, some of which use CR fields.
> +- isa
> + Usage: required
> + Value type: <u32>
> + Definition:
> +
> + isa that the CPU is currently running in. This provides instruction set
> + compatibility, less the individual feature nodes. For example, an ISA v3.0
> + implementation that lacks the "transactional-memory" cpufeature node
> + should not use transactional memory facilities.
> +
> + Value corresponds to the "Power ISA Version" multiplied by 1000.
> + For example, <3000> corresponds to Version 3.0, <2070> to Version 2.07.
> + The minor digit is available for revisions.
So the 2.07B, 3.0B (in the code above) should really be 2071 and 3001
(instead of 2070 and 3000)? Or you could make it hex and have 0x207B :-)
> +The policy for seleting and configuring which features to advertise and use
Typo ("selecting").
Segher
^ permalink raw reply
* Re: macintosh: change some data types from int to bool
From: Gustavo A. R. Silva @ 2018-02-03 12:11 UTC (permalink / raw)
To: Michael Ellerman
Cc: Michael Ellerman, Colin Leroy, linuxppc-dev, linux-kernel,
Gustavo A. R. Silva
In-Reply-To: <87shao8da3.fsf@concordia.ellerman.id.au>
Hi Michael,
Quoting Michael Ellerman <mpe@ellerman.id.au>:
> "Gustavo A. R. Silva" <garsilva@embeddedor.com> writes:
>
>> Hi Michael,
>>
>> Quoting Michael Ellerman <patch-notifications@ellerman.id.au>:
>>
>>> On Wed, 2018-01-24 at 01:42:28 UTC, "Gustavo A. R. Silva" wrote:
>>>> Change the data type of the following variables from int to bool
>>>> across all macintosh drivers:
>>>>
>>>> started
>>>> slots_started
>>>> pm121_started
>>>> wf_smu_started
>>>>
>>>> Some of these issues were detected with the help of Coccinelle.
>>>>
>>>> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
>>>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>>>
>>> Applied to powerpc next, thanks.
>>>
>>> https://git.kernel.org/powerpc/c/4f256d561447c6e1bf8b70e19daae0
>>>
>>> cheers
>>
>> Awesome.
>>
>> If I can help out with anything else, please let me know.
>
> Sure thing.
>
> We have a TODO list of sorts on github, some of them are easy, some are
> not, feel free to ask here or on an individual issue for help:
>
> https://github.com/linuxppc/linux/issues
>
I'm sorry for the late reply. I was addressing some issues on DRM and
NET components.
I already took a look into the TODO list. I'll ask you about some of
the issues on github.
Thanks!
--
Gustavo
^ permalink raw reply
* Re: DPAA Ethernet traffice troubles with Linux kernel
From: mad skateman @ 2018-02-03 11:54 UTC (permalink / raw)
To: Madalin-cristian Bucur
Cc: linuxppc-dev@lists.ozlabs.org, Andrew Lunn, Joakim Tjernlund,
Christian Zigotzky, Jamie Krueger
In-Reply-To: <DB3PR0402MB38494AC5EE923A10053745DDECE90@DB3PR0402MB3849.eurprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2898 bytes --]
For those interested... i have recorded a video of my X5000 DPAA Ethernet,
and the weird problems..
In this Video i am also transfering hundereds of megabytes from my NAS to
the X5000.
You will also see pings die... mostly after the 12th packet and giving the
no buffer space error..
Hopefully someone might have a clue about what is happening.
https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view
On Wed, Jan 17, 2018 at 3:43 PM, Madalin-cristian Bucur <
madalin.bucur@nxp.com> wrote:
> > -----Original Message-----
> > From: Madalin-cristian Bucur
> > Sent: Wednesday, January 17, 2018 4:25 PM
> > To: David S . Miller <davem@davemloft.net>
> > Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> > madskateman@gmail.com; 'Madalin-cristian Bucur' <madalin.bucur@nxp.com>;
> > Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> > <Joakim.Tjernlund@infinera.com>
> > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> >
> > > -----Original Message-----
> > > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.
> kernel.org]
> > > On Behalf Of Madalin-cristian Bucur
> > > Sent: Wednesday, January 17, 2018 4:16 PM
> > > To: Andrew Lunn <andrew@lunn.ch>; Joakim Tjernlund
> > > <Joakim.Tjernlund@infinera.com>
> > > Cc: linuxppc-dev@lists.ozlabs.org; netdev@vger.kernel.org;
> > > madskateman@gmail.com; David S . Miller <davem@davemloft.net>
> > > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> > >
> > > > -----Original Message-----
> > > > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > > > Sent: Wednesday, January 17, 2018 3:44 PM
> > > > To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > > >
> > > > > That doesn't work really, having users to hit the bug, debug it,
> fix
> > > it
> > > > and then
> > > > > find it fixed already in upstream, then specifically request it to
> > be
> > > > backported to stable.
> > > > > I don't need this fix to be backported, already got it. Someone
> else
> > > > might though.
> > > >
> > > > The "someone else might though" is a big point of asking for it to
> > > > added to stable. The other reason is it means one less patch you need
> > > > to maintain in your build.
> > >
> > > I've sent that patch [1] for net but I guess the timing was wrong and
> > > it was merged to net-next.
> > >
> > > > > I would be interested in bug fixes upstream which fixes:
> > > >
> > > > Did you try upstream? Does it give the same errors?
> > > >
> > > > Andrew
> > >
> > > [1] https://patchwork.kernel.org/patch/10146119/
> > >
> > > Madalin
> >
> > Hi Dave,
> >
> > Can you please add the fix [1] to stable?
> >
> > Thank you,
> > Madalin
>
> Sorry,
>
> I've provided the wrong link towards the patch (v1 instead of v3),
> here's the correct one:
>
> https://patchwork.kernel.org/patch/10151969/
>
> Madalin
>
[-- Attachment #2: Type: text/html, Size: 5049 bytes --]
^ permalink raw reply
* [PATCH] powerpc/64s: fix may_hard_irq_enable for PMI soft masking
From: Nicholas Piggin @ 2018-02-03 7:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin, Madhavan Srinivasan
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 <maddy@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
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,0xffff; \
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; \
xori r10,r10,MSR_EE; /* clear MSR_EE */ \
mtspr SPRN_##_H##SRR1,r10; \
--
2.15.1
^ permalink raw reply related
* [PATCH] powerpc/64s/radix: remove unused flush_tlb_lpid variants
From: Nicholas Piggin @ 2018-02-03 6:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin, Aneesh Kumar K . V
These were intended for use by KVM, but it has its own LPID
flushing code and never used these.
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
.../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
^ permalink raw reply related
* Re: [PATCH (skiboot)] dt: add /cpus/ibm,powerpc-cpu-features device tree bindings
From: Nicholas Piggin @ 2018-02-03 4:31 UTC (permalink / raw)
To: skiboot; +Cc: linuxppc-dev
In-Reply-To: <20180203042732.27980-1-npiggin@gmail.com>
On Sat, 3 Feb 2018 14:27:32 +1000
Nicholas Piggin <npiggin@gmail.com> wrote:
> diff --git a/core/cpufeatures.c b/core/cpufeatures.c
> new file mode 100644
> index 000000000..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 <skiboot.h>
> +#include <cpu.h>
> +#include <processor.h>
> +#include <ccan/str/str.h>
> +#include <device.h>
> +
> +#define DEBUG
Sorry, didn't send the right version after testing. This line should be
deleted before going upstream.
Thanks,
Nick
^ permalink raw reply
* [PATCH (skiboot)] dt: add /cpus/ibm, powerpc-cpu-features device tree bindings
From: Nicholas Piggin @ 2018-02-03 4:27 UTC (permalink / raw)
To: skiboot; +Cc: Nicholas Piggin, linuxppc-dev
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 <npiggin@gmail.com>
---
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 000000000..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 <skiboot.h>
+#include <cpu.h>
+#include <processor.h>
+#include <ccan/str/str.h>
+#include <device.h>
+
+#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_NONE 0
+#define HV_CUSTOM 1
+#define HV_HFSCR 2
+
+#define OS_NONE 0
+#define OS_CUSTOM 1
+#define OS_FSCR 2
+
+/* 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.
+ */
+ { "little-endian",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * MSR_HV=1 mode as in ISAv2.07B (i.e., hypervisor privileged
+ * instructions and registers).
+ */
+ { "hypervisor",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV,
+ HV_CUSTOM, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B interrupt vectors, registers, and control registers
+ * (e.g., AIL, ILE, HV, etc LPCR bits).
+ *
+ * This does not necessarily specify all possible interrupt types.
+ * floating-point, for example requires some ways to handle floating
+ * point exceptions, but the low level details of interrupt handler
+ * is not a dependency there. There will always be *some* interrupt
+ * handler, (and some way to provide memory magagement, etc.).
+ */
+ { "interrupt-facilities",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ { "smt",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, 14,
+ NULL, },
+
+ /*
+ * ISAv2.07B Program Priority Registers (PPR)
+ * PPR and associated control registers (e.g. RPR, PSPB),
+ * priority "or" instructions, etc.
+ */
+ { "program-priority-register",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B Book3S Chapter 5.7.9.1. Virtual Page Class Key Protecion
+ * AMR, IAMR, AMOR, UAMOR, etc registers and MMU key bits.
+ */
+ { "virtual-page-class-key-protection",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B SAO storage control attribute
+ */
+ { "strong-access-ordering",
+ CPU_ALL & ~CPU_P9_DD1,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B no-execute storage control attribute
+ */
+ { "no-execute",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * Cache inhibited attribute supported on large pages.
+ */
+ { "cache-inhibited-large-page",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B Book3S Chapter 8. Debug Facilities
+ * CIEA, CIABR, DEAW, MEte, trace interrupt, etc.
+ * Except CFAR, branch tracing.
+ */
+ { "debug-facilities",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B CFAR
+ */
+ { "come-from-address-register",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ "debug-facilities", },
+
+ /*
+ * ISAv2.07B Branch tracing (optional in ISA)
+ */
+ { "branch-tracing",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ "debug-facilities", },
+
+ /*
+ * ISAv2.07B Floating-point Facility
+ */
+ { "floating-point",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_CUSTOM, OS_CUSTOM,
+ PPC_BITLSHIFT(63), -1, 27,
+ NULL, },
+
+ /*
+ * ISAv2.07B Vector Facility (VMX)
+ */
+ { "vector",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_CUSTOM, OS_CUSTOM,
+ PPC_BITLSHIFT(62), -1, 28,
+ "floating-point", },
+
+ /*
+ * ISAv2.07B Vector-scalar Facility (VSX)
+ */
+ { "vector-scalar",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, 7,
+ "vector", },
+
+ { "vector-crypto",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, 57,
+ "vector", },
+
+ /*
+ * ISAv2.07B Quadword Load and Store instructions
+ * including lqarx/stdqcx. instructions.
+ */
+ { "quadword-load-store",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B Binary Coded Decimal (BCD)
+ * BCD fixed point instructions
+ */
+ { "decimal-integer",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B Decimal floating-point Facility (DFP)
+ */
+ { "decimal-floating-point",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, 10,
+ "floating-point", },
+
+ /*
+ * ISAv2.07B
+ * DSCR, default data prefetch LPCR, etc
+ */
+ { "data-stream-control-register",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_CUSTOM, OS_CUSTOM,
+ PPC_BITLSHIFT(61), PPC_BITLSHIFT(61), 61,
+ NULL, },
+
+ /*
+ * ISAv2.07B Branch History Rolling Buffer (BHRB)
+ */
+ { "branch-history-rolling-buffer",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_CUSTOM, OS_CUSTOM,
+ PPC_BITLSHIFT(59), -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B Transactional Memory Facility (TM or HTM)
+ */
+ { "transactional-memory",
+ CPU_P8, /* P9 support is not enabled yet */
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_CUSTOM, OS_CUSTOM,
+ PPC_BITLSHIFT(58), -1, 62,
+ NULL, },
+
+ /*
+ * ISAv3.0B TM additions
+ * TEXASR bit 17, self-induced vs external footprint overflow
+ */
+ { "transactional-memory-v3",
+ 0,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ "transactional-memory", },
+
+ /*
+ * ISAv2.07B Event-Based Branch Facility (EBB)
+ */
+ { "event-based-branch",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_CUSTOM, OS_CUSTOM,
+ PPC_BITLSHIFT(56), PPC_BITLSHIFT(56), 60,
+ NULL, },
+
+ /*
+ * ISAv2.07B Target Address Register (TAR)
+ */
+ { "target-address-register",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_CUSTOM, OS_CUSTOM,
+ PPC_BITLSHIFT(55), PPC_BITLSHIFT(55), 58,
+ NULL, },
+
+ /*
+ * ISAv2.07B Control Register (CTRL)
+ */
+ { "control-register",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B Book3S Chapter 11. Processor Control.
+ * msgsnd, msgsndp, doorbell, etc.
+ *
+ * ISAv3.0B is not compatible (different addressing, HFSCR required
+ * for msgsndp).
+ */
+ { "processor-control-facility",
+ CPU_P8_DD2, /* P8 DD1 has no dbell */
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B PURR, SPURR registers
+ */
+ { "processor-utilization-of-resources-register",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * POWER8 initiate coprocessor store word indexed (icswx) instruction
+ */
+ { "coprocessor-icswx",
+ CPU_P8,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B hash based MMU and all instructions, registers,
+ * data structures, exceptions, etc.
+ */
+ { "mmu-hash",
+ CPU_P8,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * POWER8 MCE / machine check exception.
+ */
+ { "machine-check-power8",
+ CPU_P8,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * POWER8 PMU / performance monitor unit.
+ */
+ { "performance-monitor-power8",
+ CPU_P8,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B alignment interrupts set DSISR register
+ *
+ * POWER CPUs do not used this, and it's removed from ISAv3.0B.
+ */
+ { "alignment-interrupt-dsisr",
+ 0,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B / POWER8 doze, nap, sleep, winkle instructions
+ * XXX: is Linux we using some BookIV specific implementation details
+ * in nap handling? We have no POWER8 specific key here.
+ */
+ { "idle-nap",
+ CPU_P8,
+ ISA_BASE, USABLE_HV,
+ HV_CUSTOM, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B wait instruction
+ */
+ { "wait",
+ CPU_P8,
+ ISA_BASE, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ { "subcore",
+ CPU_P8,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ "smt", },
+
+ /*
+ * ISAv3.0B radix based MMU
+ */
+ { "mmu-radix",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv3.0B hash based MMU, new hash pte format, PCTR, etc
+ */
+ { "mmu-hash-v3",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv3.0B wait instruction
+ */
+ { "wait-v3",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv3.0B stop idle instructions and registers
+ * XXX: Same question as for idle-nap
+ */
+ { "idle-stop",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv3.0B Hypervisor Virtualization Interrupt
+ * Also associated system registers, LPCR EE, HEIC, HVICE,
+ * system reset SRR1 reason, etc.
+ */
+ { "hypervisor-virtualization-interrupt",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV,
+ HV_CUSTOM, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * POWER9 MCE / machine check exception.
+ */
+ { "machine-check-power9",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * POWER9 PMU / performance monitor unit.
+ */
+ { "performance-monitor-power9",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_CUSTOM,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv3.0B scv/rfscv system call instructions and exceptions, fscr bit
+ * etc.
+ */
+ { "system-call-vectored",
+ CPU_P9,
+ ISA_V3_0B, USABLE_OS|USABLE_PR,
+ HV_NONE, OS_CUSTOM,
+ -1, PPC_BITLSHIFT(51), -1,
+ NULL, },
+
+ /*
+ * ISAv3.0B Book3S Chapter 10. Processor Control.
+ * global msgsnd, msgsndp, msgsync, doorbell, etc.
+ */
+ { "processor-control-facility-v3",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS,
+ HV_CUSTOM, OS_NONE,
+ PPC_BITLSHIFT(53), -1, -1,
+ NULL, },
+
+ /*
+ * ISAv3.0B addpcis instruction
+ */
+ { "pc-relative-addressing",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv2.07B Book3S Chapter 7. Timer Facilities
+ * TB, VTB, DEC, HDEC, IC, etc registers and exceptions.
+ * Not including PURR or SPURR registers.
+ */
+ { "timer-facilities",
+ CPU_ALL,
+ ISA_BASE, USABLE_HV|USABLE_OS,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv3.0B Book3S Chapter 7. Timer Facilities
+ * Large decrementer and hypervisor decrementer
+ */
+ { "timer-facilities-v3",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ "timer-facilities", },
+
+ /*
+ * ISAv3.0B deliver a random number instruction (darn)
+ */
+ { "random-number-generator",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv3.0B fixed point instructions
+ * multiply-add, modulo, count trailing zeroes, cmprb, cmpeqb,
+ * extswsli, mfvsrld, mtvsrdd, mtvsrws, addex
+ */
+ { "fixed-point-v3",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ { "decimal-integer-v3",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ "fixed-point-v3 decimal-integer", },
+
+ /*
+ * ISAv3.0B lightweight mffs
+ */
+ { "floating-point-v3",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ "floating-point", },
+
+ { "decimal-floating-point-v3",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ "floating-point-v3 decimal-floating-point", },
+
+ { "vector-v3",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ "vector", },
+
+ { "vector-scalar-v3",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ "vector-v3 vector-scalar" },
+
+ { "vector-binary128",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, 54,
+ "vector-scalar-v3", },
+
+ { "vector-binary16",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ "vector-v3", },
+
+ /*
+ * ISAv3.0B branch instruction and register additions
+ * CA32, OV32, mcrxrx, setb
+ */
+ { "branch-v3",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv3.0B external exception for EBB
+ */
+ { "event-based-branch-v3",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ "event-based-branch", },
+
+ /*
+ * ISAv3.0B Atomic Memory Operations (AMO)
+ */
+ { "atomic-memory-operations",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv3.0B Copy-Paste Facility
+ */
+ { "copy-paste",
+ CPU_P9,
+ ISA_V3_0B, USABLE_HV|USABLE_OS|USABLE_PR,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+
+ /*
+ * ISAv3.0B GSR SPR register
+ * POWER9 does not implement it
+ */
+ { "group-start-register",
+ 0,
+ ISA_V3_0B, USABLE_HV|USABLE_OS,
+ HV_NONE, OS_NONE,
+ -1, -1, -1,
+ NULL, },
+};
+
+static void add_cpu_feature_nodeps(struct dt_node *features,
+ const struct cpu_feature *f)
+{
+ struct dt_node *feature;
+
+ feature = dt_new(features, f->name);
+ assert(feature);
+
+ dt_add_property_cells(feature, "isa", f->isa);
+ dt_add_property_cells(feature, "usable-privilege", f->usable_privilege);
+
+ if (f->usable_privilege & USABLE_HV) {
+ if (f->hv_support != HV_NONE) {
+ uint32_t s = 0;
+ if (f->hv_support == HV_HFSCR)
+ s |= HV_SUPPORT_HFSCR;
+
+ dt_add_property_cells(feature, "hv-support", s);
+ if (f->hfscr_bit_nr != -1)
+ dt_add_property_cells(feature, "hfscr-bit-nr", f->hfscr_bit_nr);
+ } else {
+ assert(f->hfscr_bit_nr == -1);
+ }
+ }
+
+ if (f->usable_privilege & USABLE_OS) {
+ if (f->os_support != OS_NONE) {
+ uint32_t s = 0;
+ if (f->os_support == OS_FSCR)
+ s |= OS_SUPPORT_FSCR;
+ dt_add_property_cells(feature, "os-support", s);
+ if (f->fscr_bit_nr != -1)
+ dt_add_property_cells(feature, "fscr-bit-nr", f->fscr_bit_nr);
+ } else {
+ assert(f->fscr_bit_nr == -1);
+ }
+ }
+
+ if (f->usable_privilege & USABLE_PR) {
+ if (f->hwcap_bit_nr != -1)
+ dt_add_property_cells(feature, "hwcap-bit-nr", f->hwcap_bit_nr);
+ }
+
+ if (f->dependencies_names)
+ dt_add_property(feature, "dependencies", NULL, 0);
+}
+
+static void add_cpufeatures_dependencies(struct dt_node *features)
+{
+ struct dt_node *feature;
+
+ dt_for_each_node(features, feature) {
+ const struct cpu_feature *f;
+ const char *deps_names;
+ struct dt_property *deps;
+ int nr_deps;
+ int i;
+
+ /* Find features with dependencies */
+
+ deps = __dt_find_property(feature, "dependencies");
+ if (!deps)
+ continue;
+
+ /* Find the matching cpu table */
+ for (i = 0; i < ARRAY_SIZE(cpu_features_table); i++) {
+ f = &cpu_features_table[i];
+ if (!strcmp(f->name, feature->name))
+ break;
+ }
+ assert(f->dependencies_names);
+
+ /*
+ * Count number of depended features and allocate space
+ * for phandles in the property.
+ */
+ deps_names = f->dependencies_names;
+ nr_deps = strcount(deps_names, " ") + 1;
+ dt_resize_property(&deps, nr_deps * sizeof(u32));
+ deps->len = nr_deps * sizeof(u32);
+
+ DBG("feature %s has %d dependencies (%s)\n", f->name, nr_deps, deps_names);
+ /*
+ * For each one, find the depended feature then advance to
+ * next name.
+ */
+ for (i = 0; i < nr_deps; i++) {
+ struct dt_node *dep;
+ int len;
+
+ if (nr_deps - i == 1)
+ len = strlen(deps_names);
+ else
+ len = strchr(deps_names, ' ') - deps_names;
+
+ dt_for_each_node(features, dep) {
+ if (!strncmp(deps_names, dep->name, len))
+ goto found_dep;
+ }
+
+ prlog(PR_ERR, "CPUFT: feature %s dependencies not found\n", f->name);
+ break;
+found_dep:
+ DBG(" %s found dep (%s)\n", f->name, dep->name);
+ dt_property_set_cell(deps, i, dep->phandle);
+
+ /* Advance over the name + delimiter */
+ deps_names += len + 1;
+ }
+ }
+}
+
+static void add_cpufeatures(struct dt_node *cpus,
+ uint32_t cpu_feature_isa, uint32_t cpu_feature_cpu,
+ const char *cpu_name)
+{
+ struct dt_node *features;
+ int i;
+
+ DBG("creating cpufeatures for cpu:%d isa:%d\n", cpu_feature_cpu, cpu_feature_isa);
+
+ features = dt_new(cpus, "ibm,powerpc-cpu-features");
+ assert(features);
+
+ dt_add_property_cells(features, "isa", cpu_feature_isa);
+
+ dt_add_property_string(features, "device_type", "cpu-features");
+ dt_add_property_string(features, "compatible", "ibm,powerpc-cpu-features");
+ dt_add_property_string(features, "display-name", cpu_name);
+
+ /* add without dependencies */
+ for (i = 0; i < ARRAY_SIZE(cpu_features_table); i++) {
+ const struct cpu_feature *f = &cpu_features_table[i];
+
+ if (f->cpus_supported & cpu_feature_cpu) {
+ DBG(" '%s'\n", f->name);
+ add_cpu_feature_nodeps(features, f);
+ }
+ }
+
+ /* dependency construction pass */
+ add_cpufeatures_dependencies(features);
+}
+
+void dt_add_cpufeatures(struct dt_node *root)
+{
+ int version;
+ uint32_t cpu_feature_isa = 0;
+ uint32_t cpu_feature_cpu = 0;
+ struct dt_node *cpus;
+ const char *cpu_name = NULL;
+
+ version = mfspr(SPR_PVR);
+ switch(PVR_TYPE(version)) {
+ case PVR_TYPE_P8:
+ if (!cpu_name)
+ cpu_name = "POWER8";
+ /* fallthrough */
+ case PVR_TYPE_P8E:
+ if (!cpu_name)
+ cpu_name = "POWER8E";
+ /* fallthrough */
+ case PVR_TYPE_P8NVL:
+ if (!cpu_name)
+ cpu_name = "POWER8NVL";
+
+ cpu_feature_isa = ISA_V2_07B;
+ if (PVR_VERS_MAJ(version) == 1)
+ cpu_feature_cpu = CPU_P8_DD1;
+ else
+ cpu_feature_cpu = CPU_P8_DD2;
+ break;
+ case PVR_TYPE_P9:
+ if (!cpu_name)
+ cpu_name = "POWER9";
+
+ cpu_feature_isa = ISA_V3_0B;
+ if (is_power9n(version) && (PVR_VERS_MAJ(version) == 1)) {
+ /* P9N DD1 */
+ cpu_feature_cpu = CPU_P9_DD1;
+ } else if (is_power9n(version) &&
+ (PVR_VERS_MAJ(version) == 2)) {
+ /* P9N DD2.x */
+ cpu_feature_cpu = CPU_P9_DD2;
+ } else {
+ assert(0);
+ }
+
+ break;
+ default:
+ return;
+ }
+
+ cpus = dt_new_check(root, "cpus");
+
+ add_cpufeatures(cpus, cpu_feature_isa, cpu_feature_cpu, cpu_name);
+}
diff --git a/core/device.c b/core/device.c
index fc1db5689..11c50af3f 100644
--- a/core/device.c
+++ b/core/device.c
@@ -598,6 +598,13 @@ u32 dt_property_get_cell(const struct dt_property *prop, u32 index)
return fdt32_to_cpu(((const u32 *)prop->prop)[index]);
}
+void dt_property_set_cell(struct dt_property *prop, u32 index, u32 val)
+{
+ assert(prop->len >= (index+1)*sizeof(u32));
+ /* Always aligned, so this works. */
+ ((u32 *)prop->prop)[index] = cpu_to_fdt32(val);
+}
+
/* First child of this node. */
struct dt_node *dt_first(const struct dt_node *root)
{
diff --git a/core/init.c b/core/init.c
index ec9f32981..cf99e5f4f 100644
--- a/core/init.c
+++ b/core/init.c
@@ -860,6 +860,7 @@ void __noreturn __nomcount main_cpu_entry(const void *fdt)
} else {
dt_expand(fdt);
}
+ dt_add_cpufeatures(dt_root);
/* Now that we have a full devicetree, verify that we aren't on fire. */
per_thread_sanity_checks();
diff --git a/doc/device-tree/ibm,powerpc-cpu-features/binding.txt b/doc/device-tree/ibm,powerpc-cpu-features/binding.txt
new file mode 100644
index 000000000..4dd327ff4
--- /dev/null
+++ b/doc/device-tree/ibm,powerpc-cpu-features/binding.txt
@@ -0,0 +1,245 @@
+ibm,powerpc-cpu-features binding
+================================
+
+This device tree binding describes CPU features available to software, with
+enablement, privilege, and compatibility metadata.
+
+More general description of design and implementation of this binding is
+found in design.txt, which also points to documentation of specific features.
+
+
+/cpus/ibm,powerpc-cpu-features node binding
+-------------------------------------------
+
+Node: ibm,powerpc-cpu-features
+
+Description: Container of CPU feature nodes.
+
+The node name must be "ibm,powerpc-cpu-features".
+
+It is implemented as a child of the node "/cpus", but this must not be
+assumed by parsers.
+
+The node is optional but should be provided by new OPAL firmware.
+
+Properties:
+
+- device_type
+ Usage: required
+ Value type: string
+ Definition: "cpu-features"
+
+- compatible
+ Usage: required
+ Value type: string
+ Definition: "ibm,powerpc-cpu-features"
+
+ This compatibility refers to backwards compatibility of the overall
+ design with parsers that behave according to these guidelines. This can
+ be extended in a backward compatible manner which would not warrant a
+ revision of the compatible property.
+
+- isa
+ Usage: required
+ Value type: <u32>
+ Definition:
+
+ isa that the CPU is currently running in. This provides instruction set
+ compatibility, less the individual feature nodes. For example, an ISA v3.0
+ implementation that lacks the "transactional-memory" cpufeature node
+ should not use transactional memory facilities.
+
+ Value corresponds to the "Power ISA Version" multiplied by 1000.
+ For example, <3000> corresponds to Version 3.0, <2070> to Version 2.07.
+ The minor digit is available for revisions.
+
+/cpus/ibm,powerpc-cpu-features/example-feature node bindings
+----------------------------------------------------------------
+
+Each child node of cpu-features represents a CPU feature / capability.
+
+Node: A string describing an architected CPU feature, e.g., "floating-point".
+
+Description: A feature or capability supported by the CPUs.
+
+The name of the node is a human readable string that forms the interface
+used to describe features to software. Features are currently documented
+in the code where they are implemented in skiboot/core/cpufeatures.c
+
+Presence of the node indicates the feature is available.
+
+Properties:
+
+- isa
+ Usage: required
+ Value type: <u32>
+ Definition:
+
+ First level of the Power ISA that the feature appears in.
+ Software should filter out features when constraining the
+ environment to a particular ISA version.
+
+ Value is defined similarly to /cpus/features/isa
+
+- usable-privilege
+ Usage: required
+ Value type: <u32> bit mask
+ Definition:
+ Bit numbers are LSB0
+ bit 0 - PR (problem state / user mode)
+ bit 1 - OS (privileged state)
+ bit 2 - HV (hypervisor state)
+ All other bits reserved and should be zero.
+
+ This property describes the privilege levels and/or software components
+ that can use the feature.
+
+ If bit 0 is set, then the hwcap-bit-nr property will exist.
+
+
+- hv-support
+ Usage: optional
+ Value type: <u32> bit mask
+ Definition:
+ Bit numbers are LSB0
+ bit 0 - HFSCR
+ All other bits reserved and should be zero.
+
+ This property describes the HV privilege support required to enable the
+ feature to lesser privilege levels. If the property does not exist then no
+ support is required.
+
+ If no bits are set, the hypervisor must have explicit/custom support for
+ this feature.
+
+ If the HFSCR bit is set, then the hfscr-bit-nr property will exist and
+ the feature may be enabled by setting this bit in the HFSCR register.
+
+
+- os-support
+ Usage: optional
+ Value type: <u32> bit mask
+ Definition:
+ Bit numbers are LSB0
+ bit 0 - FSCR
+ All other bits reserved and should be zero.
+
+ This property describes the OS privilege support required to enable the
+ feature to lesser privilege levels. If the property does not exist then no
+ support is required.
+
+ If no bits are set, the operating system must have explicit/custom support
+ for this feature.
+
+ If the FSCR bit is set, then the fscr-bit-nr property will exist and
+ the feature may be enabled by setting this bit in the FSCR register.
+
+
+- hfscr-bit-nr
+ Usage: optional
+ Value type: <u32>
+ Definition: HFSCR bit position (LSB0)
+
+ This property exists when the hv-support property HFSCR bit is set. This
+ property describes the bit number in the HFSCR register that the
+ hypervisor must set in order to enable this feature.
+
+ This property also exists if an HFSCR bit corresponds with this feature.
+ This makes CPU feature parsing slightly simpler.
+
+
+- fscr-bit-nr
+ Usage: optional
+ Value type: <u32>
+ Definition: FSCR bit position (LSB0)
+
+ This property exists when the os-support property FSCR bit is set. This
+ property describes the bit number in the FSCR register that the
+ operating system must set in order to enable this feature.
+
+ This property also exists if an FSCR bit corresponds with this feature.
+ This makes CPU feature parsing slightly simpler.
+
+
+- hwcap-bit-nr
+ Usage: optional
+ Value type: <u32>
+ Definition: Linux ELF AUX vector bit position (LSB0)
+
+ This property may exist when the usable-privilege property value has PR bit set.
+ This property describes the bit number that should be set in the ELF AUX
+ hardware capability vectors in order to advertise this feature to userspace.
+ Bits 0-31 correspond to bits 0-31 in AT_HWCAP vector. Bits 32-63 correspond
+ to 0-31 in AT_HWCAP2 vector, and so on. Missing AT_HWCAPx vectors implies
+ that the feature is not enabled or can not be advertised. Operating systems
+ may provide a number of unassigned hardware capability bits to allow for new
+ features to be advertised.
+
+ Some properties representing features created before this binding are
+ advertised to userspace without a one-to-one hwcap bit number may not specify
+ this bit. Operating system will handle those bits specifically. All new
+ features usable by userspace will have a hwcap-bit-nr property.
+
+
+- dependencies
+ Usage: optional
+ Value type: <prop-encoded-array>
+ Definition:
+
+ If this property exists then it is a list of phandles to cpu feature
+ nodes that must be enabled for this feature to be enabled.
+
+
+- Custom properties of the feature
+ Usage: optional
+ Definition:
+
+ Particular features may define their own properties.
+
+
+Example
+-------
+
+ /cpus/ibm,powerpc-cpu-features {
+ device_type = "ibm,powerpc-cpu-features";
+
+ isa = <3020>;
+
+ darn {
+ isa = <3000>;
+ usable-privilege = <1 | 2 | 4>;
+ hwcap-bit-nr = <xx>;
+ };
+
+ scv {
+ isa = <3000>;
+ usable-privilege = <1 | 2>;
+ os-support = <0>;
+ hwcap-bit-nr = <xx>;
+ };
+
+ stop {
+ isa = <3000>;
+ usable-privilege = <2 | 4>;
+ hv-support = <0>;
+ os-support = <0>;
+ };
+
+ vsx2 (hypothetical) {
+ isa = <3010>;
+ usable-privilege = <1 | 2 | 4>;
+ hv-support = <0>;
+ os-support = <0>;
+ hwcap-bit-nr = <xx>;
+ };
+
+ vsx2-newinsns {
+ isa = <3020>;
+ usable-privilege = <1 | 2 | 4>;
+ os-support = <1>;
+ fscr-bit-nr = <xx>;
+ hwcap-bit-nr = <xx>;
+ dependencies = <&vsx2>;
+ };
+
+ };
diff --git a/doc/device-tree/ibm,powerpc-cpu-features/design.txt b/doc/device-tree/ibm,powerpc-cpu-features/design.txt
new file mode 100644
index 000000000..8f1dae17b
--- /dev/null
+++ b/doc/device-tree/ibm,powerpc-cpu-features/design.txt
@@ -0,0 +1,157 @@
+ibm,powerpc-cpu-features binding
+================================
+
+The OPAL / skiboot code is the canonical location for this specification. All
+definitions of features, constant, bit positions, etc. must be documented here
+before being deployed in Linux. This is not presently part of LoPAPR.
+
+
+Interfaces
+----------
+This specification describes the ibm,powerpc-cpu-features binding (the formal
+definition of binding can be found in binding.txt in this directory).
+
+This specification also involves the Linux ELF AUXV AT_HWCAP and AT_HWCAP2
+interfaces for PPC_FEATURE* bits. Allocation of new AT_HWCAP bits should be
+done in coordination with OPAL / skiboot, Linux, and glibc projects.
+
+The binding is passed to the hypervisor by firmware. The hypervisor may
+build a subset with unsupported/disabled features and hypervisor specifics
+removed, and pass that to a guest OS. The OS may advertise features to
+userspace.
+
+
+Background
+----------
+The cpu-features binding (subsequently "cpu-features") aims to provide an
+extensible metadata and protocol between different levels of system software
+(firmware, hypervisor, OS/guest, userspace) to advertise the CPU features
+available on the system. With each level able to shape the features available
+to the next.
+
+The binding specifies features common to all CPUs in the system. Heterogeneous
+CPU features are not supported at present (such could be added by providing
+additional cpu-features nodes and linking those to particular CPUs with
+additional features).
+
+There is no strict definition for what a CPU feature must be, but an
+architectural behaviour or performance characteristic (or group of related
+behaviours). They must be documented in skiboot/core/cpufeatures.c sufficiently
+precisely. More guidelines for feature definitions below.
+
+cpu-features is intended to provide fine grained control of CPU features at
+all levels of the stack (firmware, hypervisor, OS, userspace), with the
+ability for new CPU features to be used by some components without all
+components being upgraded (e.g., a new floating point instruction could be
+used by userspace math library without upgrading kernel and hypervisor).
+
+
+Overview
+--------
+
+The cpu-features node is created by firmware and passed to the hypervisor.
+The hypervisor may create cpu-features node to be passed to guest, based on
+the features that have been enabled, and policy decisions. Hypervisor specific
+features, and hypervisor bits and properties should not be advertised to
+guests. Guest OS may advertise features to userspace using another method
+(e.g., using AUXV vectors, userspace typically does not parse DT).
+
+When the cpu-features node is present, ibm,pa-features and individual feature
+properties (e.g., "ibm,vsx"), and cpu-version under the "cpu" compatible nodes
+can be ignored by the consumer. For compatibility, the provider must continue
+to provide those older properties and the consumer must not assume cpu-features
+exists.
+
+When this node exists, software may assume a base feature set which is ISA
+v2.07B (BookS) minus the explicit features listed in core/cpufeatures.c
+entries in this source tree.
+
+Each feature is advertised as a node underneath the cpu-features node, named
+with a human-readable string name that uniquely identifies specification of
+that capability.
+
+A feature node has a number of metadata properties describing privilege levels
+a feature may be used (HV, OS, PR/user), and information about how it is to
+be enabled and advertised to lesser privilege levels. Enabling means to make
+it available at a lesser privilege level, (how to enable a given feature
+for this privilege level is implicit: if the software know how to use a
+feature, it also knows how to enable it).
+
+Feature node properties:
+
+- "isa", the Power ISA version where this feature first became available.
+ In case of an implementation specific feature
+
+- "usable-privilege", a bitmask (HV, OS, PR/user) specifying which privilege
+ levels this feature may be used in.
+
+- "hv-support", a bitmask. If this exists, the hypervisor must do some work
+ to enable support for lesser privilege levels. Bits can be set in this mask
+ to specify prescription/recipes to enable the feature without custom code.
+ If no bits are set, no recipe exists and custom code must be used. HFSCR
+ register enable bit is the only such recipe currently.
+
+- "os-support", similar to hv-support. FSCR recipe.
+
+- Features may have additional properties associated, must be documented with
+ the feature.
+
+- Recipes may have additional properties associated. HFSCR recipe has
+ hfscr-bit-nr, and FSCR recipe has fscr-bit-nr.
+
+- "dependencies" array of phandles. If this exists, it links to the
+ features that must be enabled in order for this feature to be enabled.
+
+- "hwcap-bit-nr" if it exists provides a Linux ELF AUXV HWCAP bit number that
+ can be used to advertise this feature to userspace.
+
+Together, these compatibility, support, and dependencies properties allow
+unknown features to be enabled and advertised to lesser privilege levels
+(when possible).
+
+All bits not defined in usable, support masks must be 0, and should be ignored
+by consumers. This allows extensibility to add new privilege levels and new
+recipes. Unknown properties should also be ignored. This allows extensibility
+for additional methods and metadata for enablement and advertisement.
+
+The policy for seleting and configuring which features to advertise and use
+is left for implementations.
+
+
+Guidelines for defining features
+--------------------------------
+
+As a rough guide, features should be based on functional groups of changes
+to the ISA, or related performance characteristics.
+
+Grouping should be made by one or a combination of those that:
+- Share common enablement requirements (e.g., share particular registers or
+ firmware setup requirements).
+- Share common usage patterns (e..g, likely to be used together).
+- Are implemented with a particular new hardware unit.
+- Are optional in the ISA.
+
+Granularity can be debated, but fine grained and encompassing is generally
+preferable. For example, memory management unit may be considered fundamental,
+but the MMU in POWER9 is very different and in many ways incompatible from
+that in POWER8 even in hash mode.
+
+For example, "POWER9" would be too general, but a new feature for every
+instruction would be too specific. The "summary of changes" preface in Power
+ISA specification is a good starting point to give a guideline for granularity
+of the architected features.
+
+New features that offer additional or incompatible functionality beyond
+an existing feature may contain an ISA version postfix.
+
+Implementation specific behaviour should contain a CPU type postfix. E.g.,
+"machine-check-power9" gives exact MCE properties. If a future CPU has the same
+MCE architecture, it should define the same property. If it has a
+backward-compatible superset, it could additionally define
+"machine-check-newcpu".
+
+Features should be "positive" as much as possible. That is, the presence of
+a feature should indicate the presence of an additional CPU feature (e.g., a
+new instruction or register). This requires some anticipation and foresight
+for defining CPU features. "Negative" features may be unavoidable in some
+cases.
diff --git a/include/device.h b/include/device.h
index 1e5875dca..fd66df11a 100644
--- a/include/device.h
+++ b/include/device.h
@@ -141,6 +141,7 @@ void dt_check_del_prop(struct dt_node *node, const char *name);
/* Warning: moves *prop! */
void dt_resize_property(struct dt_property **prop, size_t len);
+void dt_property_set_cell(struct dt_property *prop, u32 index, u32 val);
u32 dt_property_get_cell(const struct dt_property *prop, u32 index);
/* First child of this node. */
diff --git a/include/skiboot.h b/include/skiboot.h
index e94f21212..bcbdb4829 100644
--- a/include/skiboot.h
+++ b/include/skiboot.h
@@ -195,6 +195,11 @@ extern void start_kernel_secondary(uint64_t entry) __noreturn;
/* Get description of machine from HDAT and create device-tree */
extern int parse_hdat(bool is_opal);
+struct dt_node;
+
+/* Add /cpus/features node for boot environment that passes an fdt */
+extern void dt_add_cpufeatures(struct dt_node *root);
+
/* Root of device tree. */
extern struct dt_node *dt_root;
--
2.15.1
^ permalink raw reply related
* Re: [PATCH v5 0/1] Implements MMIO emulation for lvx/stvx instructions
From: joserz @ 2018-02-03 0:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: lvivier, linuxppc-dev, kvm-ppc
In-Reply-To: <20180202003018.GA27665@fergus.ozlabs.ibm.com>
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 = 0x1234567855554444aaaabbbb87654321, 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
0x1234567855554444aaaabbbb87654321
====> VR0 after lvx from MMIO
(gdb) p $vr0
$3 = {uint128 = 0x1234567855554444aaaabbbb87654321, 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: 0x3fffb7f70000
0x1234567855554444aaaabbbb87654321
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
0x1234567855554444aaaabbbb87654321
io_address: 0x3fff811a0000
0xaaaabbbb876543211234567855554444
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.
>
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.16-1 tag
From: Linus Torvalds @ 2018-02-02 18:23 UTC (permalink / raw)
To: Michael Ellerman
Cc: aik, Alan Modra, Andrew Donnellan, Aneesh Kumar K. V, anju,
Anton Blanchard, Arnd Bergmann, Thiago Jung Bauermann,
Benjamin Herrenschmidt, bhaktipriya96, Bjorn Helgaas, bryantly,
Balbir Singh, Christophe Leroy, clombard, Cyril Bur,
Daniel Thompson, david, Dmitry Torokhov, fbarrat,
Geert Uytterhoeven, geoff, gomonovych, gpiccoli, gromero,
Gustavo A. R. Silva, ivan, Jeremy Kerr, joakim.tjernlund,
Joe Perches, Josh Poimboeuf, jsperbeck, julia, kamalesh, khandual,
leoyang.li, Linux Kernel Mailing List, ppc-dev, Ram Pai, maddy,
mahesh, Mathieu Malaterre, mwb, naveen.n.rao, nfont, Nick Piggin,
oss, Paul Mackerras, Rob Herring, ruscur, santosh, Andreas Schwab,
Stewart Smith, sukadev, Tejun Heo, wei.guo.simon,
Greg Kroah-Hartman, Dan Williams
In-Reply-To: <87y3kbpkxy.fsf@concordia.ellerman.id.au>
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
^ permalink raw reply
* Re: [ppc32] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dmam_alloc_coherent+0xd8/0x118
From: Christoph Hellwig @ 2018-02-02 18:07 UTC (permalink / raw)
To: Mathieu Malaterre; +Cc: Christoph Hellwig, linuxppc-dev
In-Reply-To: <CA+7wUsw6jee9+PT0JUQ-gSL=A79d-uxSqgNd4LsHkUYn+zXPyw@mail.gmail.com>
On Fri, Feb 02, 2018 at 07:06:14PM +0100, Mathieu Malaterre wrote:
> On Fri, Feb 2, 2018 at 6:46 PM, Christoph Hellwig <hch@lst.de> 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.
^ permalink raw reply
* Re: [ppc32] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dmam_alloc_coherent+0xd8/0x118
From: Mathieu Malaterre @ 2018-02-02 18:06 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20180202174622.GA7996@lst.de>
On Fri, Feb 2, 2018 at 6:46 PM, Christoph Hellwig <hch@lst.de> 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
^ permalink raw reply
* Re: [PATCH, net] ibmvnic: fix firmware version when no firmware level has been provided by the VIOS server
From: Tyrel Datwyler @ 2018-02-02 17:55 UTC (permalink / raw)
To: Desnes Augusto Nunes do Rosário, netdev
Cc: linuxppc-dev, jallen, tlfalcon, nfont
In-Reply-To: <8528e0fe-30d8-9ce9-b791-62a76179666d@linux.vnet.ibm.com>
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 <desnesn@linux.vnet.ibm.com>
>>> ---
>>> 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;
>>> }
>>>
>>
>
^ permalink raw reply
* Re: [PATCH 22/34] dma-mapping: add an arch_dma_supported hook
From: Randy Dunlap @ 2018-02-02 17:47 UTC (permalink / raw)
To: Christoph Hellwig, iommu
Cc: Konrad Rzeszutek Wilk, linux-alpha, linux-snps-arc,
linux-arm-kernel, linux-c6x-dev, linux-cris-kernel, linux-hexagon,
linux-ia64, linux-m68k, linux-metag, Michal Simek, linux-mips,
linux-parisc, linuxppc-dev, patches, linux-s390, linux-sh,
sparclinux, Guan Xuetao, x86, linux-arch, linux-kernel
In-Reply-To: <20180112084232.2857-23-hch@lst.de>
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 <hch@lst.de>
> ---
> 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
^ permalink raw reply
* Re: [ppc32] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 dmam_alloc_coherent+0xd8/0x118
From: Christoph Hellwig @ 2018-02-02 17:46 UTC (permalink / raw)
To: Mathieu Malaterre; +Cc: linuxppc-dev, Christoph Hellwig
In-Reply-To: <CA+7wUsybeT=pdkX7AkiC=JsG2ShDMZF+Z_anxryeJ=UJFHkSYQ@mail.gmail.com>
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?
^ permalink raw reply
* Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7
From: Steven Sistare @ 2018-02-02 14:13 UTC (permalink / raw)
To: Eric W. Biederman, Khalid Aziz
Cc: davem, dave.hansen, aarcange, akpm, allen.pais, anthony.yznaga,
arnd, babu.moger, benh, bob.picco, bsingharora, corbet,
dan.j.williams, dave.jiang, david.j.aldridge, elena.reshetova,
glx, gregkh, hannes, hillf.zj, hpa, hughd, imbrenda, jack,
jag.raman, jane.chu, jglisse, jroedel, khalid, khandual,
kirill.shutemov, kstewart, ktkhai, liam.merwick, linux-arch,
linux-doc, linux-kernel, linux-mm, linuxppc-dev, linux, me,
mgorman, mgorman, mhocko, mike.kravetz, minchan, mingo, mingo,
mpe, nadav.amit, nagarathnam.muthusamy, nborisov, n-horiguchi,
nick.alcock, nitin.m.gupta, ombredanne, pasha.tatashin, paulus,
pombredanne, punit.agrawal, rob.gardner, ross.zwisler,
shannon.nelson, shli, sparclinux, tglx, thomas.tai, tklauser,
tom.hromatka, vegard.nossum, vijay.ac.kumar, willy, x86, zi.yan
In-Reply-To: <87wozwi0p1.fsf@xmission.com>
On 2/1/2018 9:29 PM, ebiederm@xmission.com wrote:
> Khalid Aziz <khalid.aziz@oracle.com> 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
^ permalink raw reply
* Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7
From: Khalid Aziz @ 2018-02-02 14:59 UTC (permalink / raw)
To: Eric W. Biederman
Cc: davem, dave.hansen, aarcange, akpm, allen.pais, anthony.yznaga,
arnd, babu.moger, benh, bob.picco, bsingharora, corbet,
dan.j.williams, dave.jiang, david.j.aldridge, elena.reshetova,
glx, gregkh, hannes, hillf.zj, hpa, hughd, imbrenda, jack,
jag.raman, jane.chu, jglisse, jroedel, khalid, khandual,
kirill.shutemov, kstewart, ktkhai, liam.merwick, linux-arch,
linux-doc, linux-kernel, linux-mm, linuxppc-dev, linux, me,
mgorman, mgorman, mhocko, mike.kravetz, minchan, mingo, mingo,
mpe, nadav.amit, nagarathnam.muthusamy, nborisov, n-horiguchi,
nick.alcock, nitin.m.gupta, ombredanne, pasha.tatashin, paulus,
pombredanne, punit.agrawal, rob.gardner, ross.zwisler,
shannon.nelson, shli, sparclinux, steven.sistare, tglx,
thomas.tai, tklauser, tom.hromatka, vegard.nossum, vijay.ac.kumar,
willy, x86, zi.yan
In-Reply-To: <87wozwi0p1.fsf@xmission.com>
On 02/01/2018 07:29 PM, ebiederm@xmission.com wrote:
> Khalid Aziz <khalid.aziz@oracle.com> 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
^ permalink raw reply
* Re: [PATCH, net] ibmvnic: fix firmware version when no firmware level has been provided by the VIOS server
From: Desnes Augusto Nunes do Rosário @ 2018-02-02 14:37 UTC (permalink / raw)
To: Tyrel Datwyler, netdev; +Cc: tlfalcon, linuxppc-dev, nfont, jallen
In-Reply-To: <e82c4a78-37b3-afc5-6250-8ce8bb2ec5ce@linux.vnet.ibm.com>
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 <desnesn@linux.vnet.ibm.com>
>> ---
>> 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
^ 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