[PATCH 1/3] powerpc: Don't preempt_disable() in show_cpuinfo()

[Benjamin Herrenschmidt]

This causes warnings from cpufreq mutex code. This is also
rather unnecessary and ineffective. If we really want to
prevent concurrent unplug, we could take the unplug read
lock but I don't see this being critical.

Signed-off-by: Benjamin Herrenschmidt 
---
 arch/powerpc/kernel/setup-common.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index 9d213542a48b..8fd3a70047f1 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -242,14 +242,6 @@ static int show_cpuinfo(struct seq_file *m, void *v)
unsigned short maj;
unsigned short min;
 
-   /* We only show online cpus: disable preempt (overzealous, I
-* knew) to prevent cpu going down. */
-   preempt_disable();
-   if (!cpu_online(cpu_id)) {
-   preempt_enable();
-   return 0;
-   }
-
 #ifdef CONFIG_SMP
pvr = per_cpu(cpu_pvr, cpu_id);
 #else
@@ -358,9 +350,6 @@ static int show_cpuinfo(struct seq_file *m, void *v)
 #ifdef CONFIG_SMP
seq_printf(m, "\n");
 #endif
-
-   preempt_enable();
-
/* If this is the last cpu, print the summary */
if (cpumask_next(cpu_id, cpu_online_mask) >= nr_cpu_ids)
show_cpuinfo_summary(m);
-- 
2.14.3

[PATCH 3/3] powerpc: Cosmetic cleanup of cpuinfo_op

[Benjamin Herrenschmidt]

Signed-off-by: Benjamin Herrenschmidt 
---
 arch/powerpc/kernel/setup-common.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index c1df4ba0094c..9f9524bdd3f1 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -377,10 +377,10 @@ static void c_stop(struct seq_file *m, void *v)
 }
 
 const struct seq_operations cpuinfo_op = {
-   .start =c_start,
-   .next = c_next,
-   .stop = c_stop,
-   .show = show_cpuinfo,
+   .start  = c_start,
+   .next   = c_next,
+   .stop   = c_stop,
+   .show   = show_cpuinfo,
 };
 
 void __init check_for_initrd(void)
-- 
2.14.3

[PATCH 2/3] powerpc: Make newline in cpuinfo unconditional

[Benjamin Herrenschmidt]

We used to not put the newline between the CPU part and the summary
part on UP kernels. This is a rather pointless ifdef so take it out.

Signed-off-by: Benjamin Herrenschmidt 
---
 arch/powerpc/kernel/setup-common.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index 8fd3a70047f1..c1df4ba0094c 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -346,10 +346,8 @@ static int show_cpuinfo(struct seq_file *m, void *v)
   loops_per_jiffy / (50/HZ),
   (loops_per_jiffy / (5000/HZ)) % 100);
 #endif
-
-#ifdef CONFIG_SMP
seq_printf(m, "\n");
-#endif
+
/* If this is the last cpu, print the summary */
if (cpumask_next(cpu_id, cpu_online_mask) >= nr_cpu_ids)
show_cpuinfo_summary(m);
-- 
2.14.3

Re: [PATCH v2] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[David Gibson]

On Tue, Jan 09, 2018 at 08:21:20PM +1100, Paul Mackerras wrote:
> This adds three new capabilities that give userspace information about
> the underlying machine's level of vulnerability to the Meltdown and
> Spectre attacks, and what instructions the hardware implements to
> assist software to work around the vulnerabilities.
> 
> Each capability is a tri-state, where 0 indicates that the machine is
> vulnerable and no workarounds are implement, 1 indicates that the
> machine is vulnerable but workaround assist instructions are
> available, and 2 indicates that the machine is not vulnerable.
> 
> The capabilities are:
> 
> KVM_CAP_PPC_SAFE_CACHE reports the vulnerability of the machine to
> attacks based on using speculative loads to data in L1 cache which
> should not be addressable.  The workaround provided by hardware is an
> instruction to invalidate the entire L1 data cache.
> 
> KVM_CAP_PPC_SAFE_BOUNDS_CHECK reports the vulnerability of the machine
> to attacks based on using speculative loads behind mispredicted bounds
> checks.  The workaround provided by hardware is an instruction that
> acts as a speculation barrier.
> 
> KVM_CAP_PPC_SAFE_INDIRECT_BRANCH reports the vulnerability of the
> machine to attacks based on poisoning the indirect branch predictor.
> No workaround that requires software changes is provided; the current
> hardware fix is to prevent speculation past indirect branches.
> 
> Signed-off-by: Paul Mackerras 

Reviewed-by: David Gibson 

> ---
> Note: This patch depends on the patch "powerpc/pseries: Add
> H_GET_CPU_CHARACTERISTICS flags & wrapper" by Michael Ellerman,
> available at http://patchwork.ozlabs.org/patch/856914/ .
> 
>  Documentation/virtual/kvm/api.txt |  35 +++
>  arch/powerpc/kvm/powerpc.c| 202 
> ++
>  include/uapi/linux/kvm.h  |   3 +
>  3 files changed, 240 insertions(+)
> 
> diff --git a/Documentation/virtual/kvm/api.txt 
> b/Documentation/virtual/kvm/api.txt
> index 57d3ee9..7107e52 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -4369,3 +4369,38 @@ Parameters: none
>  This capability indicates if the flic device will be able to get/set the
>  AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows
>  to discover this without having to create a flic device.
> +
> +8.14 KVM_CAP_PPC_SAFE_CACHE
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the Meltdown attack.  Its value is a
> +tristate, where 0 indicates the machine is vulnerable, 1 indicates the
> +hardware is vulnerable but provides assistance to work around the
> +vulnerability (specifically by providing a fast L1 data cache flush
> +facility), and 2 indicates that the machine is not vulnerable.
> +
> +8.15 KVM_CAP_PPC_SAFE_BOUNDS_CHECK
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the bounds-check variant of the Spectre
> +attack.  Its value is a tristate, where 0 indicates the machine is
> +vulnerable, 1 indicates the hardware is vulnerable but provides
> +assistance to work around the vulnerability (specifically by providing
> +an instruction that acts as a speculation barrier), and 2 indicates
> +that the machine is not vulnerable.
> +
> +8.16 KVM_CAP_PPC_SAFE_INDIRECT_BRANCH
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the indirect branch variant of the Spectre
> +attack.  Its value is a tristate, where 0 indicates the machine is
> +vulnerable and 2 indicates that the machine is not vulnerable.
> +(1 would indicate the availability of a workaround that software
> +needs to implement, but there is currently no workaround that needs
> +software changes.)
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 1915e86..bef76f8 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -39,6 +39,10 @@
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_PPC_PSERIES
> +#include 
> +#include 
> +#endif
>  
>  #include "timing.h"
>  #include "irq.h"
> @@ -488,6 +492,193 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
>   module_put(kvm->arch.kvm_ops->owner);
>  }
>  
> +#ifdef CONFIG_PPC_BOOK3S_64
> +/*
> + * These functions check whether the underlying hardware is safe
> + * against the Meltdown/Spectre attacks and whether it supplies
> + * instructions for use in workarounds.  The information comes from
> + * firmware, either via the device tree on powernv platforms or
> + * from an hcall on pseries platforms.
> + *
> + * For check_safe_cache() and check_safe_bounds_check(), a return
> + * value of 0 means vulnerable, 1 means vulnerable but workaround
> + * instructions are provided, and 2 means not vulnerable (no workaround
> + * is needed).
> + * For check_safe_indirect_branch(), 0 

[RFC] powerpc/mm: Enable TLB flush during native_register_proc_table()

[Anshuman Khandual]

From: Anshuman Khandual 

Any changes to the partition table must be followed by appropriate TLB
flush which is not happening at present in native_register_proc_table()
path. Fix this by calling mmu_partition_table_set_entry() which does
take care of TLB flushing after the partition table update.

Signed-off-by: Anshuman Khandual 
---
- From code inspection
- Compile, boot tested without CONFIG_PPC_RADIX_MMU
- Though it seems to be not getting called from any where

 arch/powerpc/mm/hash_native_64.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index 640cf56..89be5a6 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -758,12 +758,14 @@ static void native_flush_hash_range(unsigned long number, 
int local)
 static int native_register_proc_table(unsigned long base, unsigned long 
page_size,
  unsigned long table_size)
 {
-   unsigned long patb1 = base << 25; /* VSID */
+   unsigned long patb0, patb1;
 
+   patb1 = base << 25; /* VSID */
patb1 |= (page_size << 5);  /* sllp */
patb1 |= table_size;
 
-   partition_tb->patb1 = cpu_to_be64(patb1);
+   patb0 = be64_to_cpu(partition_tb[0].patb0);
+   mmu_partition_table_set_entry(0, patb0, patb1);
return 0;
 }
 
-- 
1.8.3.1

Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[Suraj Jitindar Singh]

On Tue, 2018-01-09 at 23:44 +1100, Alexey Kardashevskiy wrote:
> On 09/01/18 19:39, Suraj Jitindar Singh wrote:
> > On Tue, 2018-01-09 at 15:48 +1100, Paul Mackerras wrote:
> > > This adds three new capabilities that give userspace information
> > > about
> > > the underlying machine's level of vulnerability to the Meltdown
> > > and
> > > Spectre attacks, and what instructions the hardware implements to
> > > assist software to work around the vulnerabilities.
> > > 
> > > Each capability is a tri-state, where 0 indicates that the
> > > machine is
> > > vulnerable and no workarounds are implement, 1 indicates that the
> > > machine is vulnerable but workaround assist instructions are
> > > available, and 2 indicates that the machine is not vulnerable.
> > > 
> > > The capabilities are:
> > > 
> > > KVM_CAP_PPC_SAFE_CACHE reports the vulnerability of the machine
> > > to
> > > attacks based on using speculative loads to data in L1 cache
> > > which
> > > should not be addressable.  The workaround provided by hardware
> > > is an
> > > instruction to invalidate the entire L1 data cache.
> > > 
> > > KVM_CAP_PPC_SAFE_BOUNDS_CHECK reports the vulnerability of the
> > > machine
> > > to attacks based on using speculative loads behind mispredicted
> > > bounds
> > > checks.  The workaround provided by hardware is an instruction
> > > that
> > > acts as a speculation barrier.
> > > 
> > > KVM_CAP_PPC_SAFE_INDIRECT_BRANCH reports the vulnerability of the
> > > machine to attacks based on poisoning the indirect branch
> > > predictor.
> > > No workaround that requires software changes is provided; the
> > > current
> > > hardware fix is to prevent speculation past indirect branches.
> > > 
> > > Signed-off-by: Paul Mackerras 
> > > ---
> > > Note: This patch depends on the patch "powerpc/pseries: Add
> > > H_GET_CPU_CHARACTERISTICS flags & wrapper" by Michael Ellerman,
> > > available at http://patchwork.ozlabs.org/patch/856914/ .
> > > 
> > >  Documentation/virtual/kvm/api.txt |  36 +++
> > >  arch/powerpc/kvm/powerpc.c| 202
> > > ++
> > >  include/uapi/linux/kvm.h  |   3 +
> > >  3 files changed, 241 insertions(+)
> > > 
> > > diff --git a/Documentation/virtual/kvm/api.txt
> > > b/Documentation/virtual/kvm/api.txt
> > > index 57d3ee9..8d76260 100644
> > > --- a/Documentation/virtual/kvm/api.txt
> > > +++ b/Documentation/virtual/kvm/api.txt
> > > @@ -4369,3 +4369,39 @@ Parameters: none
> > >  This capability indicates if the flic device will be able to
> > > get/set
> > > the
> > >  AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute
> > > and
> > > allows
> > >  to discover this without having to create a flic device.
> > > +
> > > +8.14 KVM_CAP_PPC_SAFE_CACHE
> > > +
> > > +Architectures: ppc
> > > +
> > > +This capability gives information about the underlying machine's
> > > +vulnerability or otherwise to the Meltdown attack.  Its value is
> > > a
> > > +tristate, where 0 indicates the machine is vulnerable, 1
> > > indicates
> > > the
> > > +hardware is vulnerable but provides assistance to work around
> > > the
> > > +vulnerability (specifically by providing a fast L1 data cache
> > > flush
> > > +facility), and 2 indicates that the machine is not vulnerable.
> > > +
> > > +8.15 KVM_CAP_PPC_SAFE_BOUNDS_CHECK
> > > +
> > > +Architectures: ppc
> > > +
> > > +This capability gives information about the underlying machine's
> > > +vulnerability or otherwise to the bounds-check variant of the
> > > Spectre
> > > +attack.  Its value is a tristate, where 0 indicates the machine
> > > is
> > > +vulnerable, 1 indicates the hardware is vulnerable but provides
> > > +assistance to work around the vulnerability (specifically by
> > > providing
> > > +an instruction that acts as a speculation barrier), and 2
> > > indicates
> > > +that the machine is not vulnerable.
> > > +
> > > +8.16 KVM_CAP_PPC_SAFE_INDIRECT_BRANCH
> > > +
> > > +Architectures: ppc
> > > +
> > > +This capability gives information about the underlying machine's
> > > +vulnerability or otherwise to the indirect branch variant of the
> > > Spectre
> > > +attack.  Its value is a tristate, where 0 indicates the machine
> > > is
> > > +vulnerable and 2 indicates that the machine is not vulnerable.
> > > +(1 would indicate the availability of a workaround that software
> > > +needs to implement, but there is currently no workaround that
> > > needs
> > > +software changes.)
> > > +
> > > diff --git a/arch/powerpc/kvm/powerpc.c
> > > b/arch/powerpc/kvm/powerpc.c
> > > index 1915e86..58e863b 100644
> > > --- a/arch/powerpc/kvm/powerpc.c
> > > +++ b/arch/powerpc/kvm/powerpc.c
> > > @@ -39,6 +39,10 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#ifdef CONFIG_PPC_PSERIES
> > > +#include 
> > > +#include 
> > > +#endif
> > >  
> > >  #include "timing.h"
> > >  #include "irq.h"
> > > @@ -488,6 +492,193 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
> > >   module_put(kvm->arch.kvm_ops

Re: [PATCH 10/13] ocxl: Add Makefile and Kconfig

[Michael Ellerman]

On 10 January 2018 2:45:56 am AEDT, Frederic Barrat 
 wrote:
>
>
>Le 03/01/2018 à 06:48, Andrew Donnellan a écrit :
>> On 19/12/17 02:21, Frederic Barrat wrote:
>>> OCXL_BASE triggers the platform support needed by the driver.
>>>
>>> Signed-off-by: Frederic Barrat 
>>> ---
>>>   drivers/misc/Kconfig   |  1 +
>>>   drivers/misc/Makefile  |  1 +
>>>   drivers/misc/ocxl/Kconfig  | 25 +
>>>   drivers/misc/ocxl/Makefile | 10 ++
>>>   4 files changed, 37 insertions(+)
>>>   create mode 100644 drivers/misc/ocxl/Kconfig
>>>   create mode 100644 drivers/misc/ocxl/Makefile
>>>
>>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>>> index f1a5c2357b14..0534f338c84a 100644
>>> --- a/drivers/misc/Kconfig
>>> +++ b/drivers/misc/Kconfig
>>> @@ -508,4 +508,5 @@ source "drivers/misc/mic/Kconfig"
>>>   source "drivers/misc/genwqe/Kconfig"
>>>   source "drivers/misc/echo/Kconfig"
>>>   source "drivers/misc/cxl/Kconfig"
>>> +source "drivers/misc/ocxl/Kconfig"
>>>   endmenu
>>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>>> index 5ca5f64df478..73326d54e246 100644
>>> --- a/drivers/misc/Makefile
>>> +++ b/drivers/misc/Makefile
>>> @@ -55,6 +55,7 @@ obj-$(CONFIG_CXL_BASE)    += cxl/
>>>   obj-$(CONFIG_ASPEED_LPC_CTRL)    += aspeed-lpc-ctrl.o
>>>   obj-$(CONFIG_ASPEED_LPC_SNOOP)    += aspeed-lpc-snoop.o
>>>   obj-$(CONFIG_PCI_ENDPOINT_TEST)    += pci_endpoint_test.o
>>> +obj-$(CONFIG_OCXL)    += ocxl/
>>>
>>>   lkdtm-$(CONFIG_LKDTM)    += lkdtm_core.o
>>>   lkdtm-$(CONFIG_LKDTM)    += lkdtm_bugs.o
>>> diff --git a/drivers/misc/ocxl/Kconfig b/drivers/misc/ocxl/Kconfig
>>> new file mode 100644
>>> index ..4496b61f48db
>>> --- /dev/null
>>> +++ b/drivers/misc/ocxl/Kconfig
>>> @@ -0,0 +1,25 @@
>>> +#
>>> +# Open Coherent Accelerator (OCXL) compatible devices
>>> +#
>>> +
>>> +config OCXL_BASE
>>> +    bool
>>> +    default n
>>> +    select PPC_COPRO_BASE
>>> +
>>> +config OCXL
>>> +    tristate "Support for Open Coherent Accelerators (OCXL)"
>>> +    depends on PPC_POWERNV && PCI && EEH
>>> +    select OCXL_BASE
>>> +    default m
>>> +    help
>>> +
>>> +  Select this option to enable driver support for Open
>>> +  Coherent Accelerators (OCXL).  OCXL is otherwise known as
>>> +  Open Coherent Accelerator Processor Interface (OCAPI).
>>> +  OCAPI allows accelerators in FPGAs to be coherently attached
>>> +  to a CPU through a Open CAPI link.  This driver enables
>>> +  userspace programs to access these accelerators through
>>> +  devices found in /dev/ocxl/
>> 
>> I'd prefer more consistency in how we refer to OpenCAPI. "ocxl" is a 
>> driver name that we have purely for historical reasons, it's not
>really 
>> the name of anything else. I know throughout the various specs and
>code, 
>> we use "OCAPI" a lot, but that's not really an abbreviation that
>should 
>> be "user-facing".
>> 
>> Something like:
>> 
>> config OCXL
>>   tristate "OpenCAPI coherent accelerator support"
>>   help
>> 
>>     Select this option to enable the ocxl driver for Open
>Coherent
>>     Accelerator Processor Interface (OpenCAPI) devices.
>> 
>>     OpenCAPI allows FPGA and ASIC accelerators to be coherently
>>     attached to a CPU over an OpenCAPI link.
>> 
>>     The ocxl driver enables userspace programs to access these
>>     accelerators through devices in /dev/ocxl/.
>> 
>>     For more information, see http://opencapi.org.
>> 
>>     If unsure, say N.
>> 
>
>Agreed, and stolen.

Would also be great to add something describing the relationship to CAPI and 
cxl. Otherwise people will be confused about whether they need this one or the 
other one or both.

cheers
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [linux-next][qla2xxx][85caa95]kernel BUG at lib/list_debug.c:31!

[Madhani, Himanshu]

Hello Abdul, 

> On Jan 9, 2018, at 7:54 AM, Bart Van Assche  wrote:
> 
> On Tue, 2018-01-09 at 14:44 +0530, Abdul Haleem wrote:
>> Greeting's, 
>> 
>> Linux next kernel panics on powerpc when module qla2xxx is load/unload.
>> 
>> Machine Type: Power 8 PowerVM LPAR
>> Kernel : 4.15.0-rc2-next-20171211
>> gcc : version 4.8.5
>> Test type: module load/unload few times
>> 
>> Trace messages:
>> ---
>> qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 
>> 10.00.00.03-k.
>> qla2xxx [0106:a0:00.0]-001a: : MSI-X vector count: 32.
>> qla2xxx [0106:a0:00.0]-001d: : Found an ISP2532 irq 505 iobase 
>> 0xaeb324e6.
>> qla2xxx [0106:a0:00.0]-00c6:1: MSI-X: Failed to enable support with 32 
>> vectors, using 16 vectors.
>> qla2xxx [0106:a0:00.0]-00fb:1: QLogic QLE2562 - PCIe 2-port 8Gb FC Adapter.
>> qla2xxx [0106:a0:00.0]-00fc:1: ISP2532: PCIe (5.0GT/s x8) @ 0106:a0:00.0 
>> hdma- host#=1 fw=8.06.00 (90d5).
>> qla2xxx [0106:a0:00.1]-001a: : MSI-X vector count: 32.
>> qla2xxx [0106:a0:00.1]-001d: : Found an ISP2532 irq 506 iobase 
>> 0xa46f1774.
>> qla2xxx [0106:a0:00.1]-00c6:2: MSI-X: Failed to enable support with 32 
>> vectors, using 16 vectors.
>> 2xxx
>> qla2xxx [0106:a0:00.1]-00fb:2: QLogic QLE2562 - PCIe 2-port 8Gb FC Adapter.
>> qla2xxx [0106:a0:00.1]-00fc:2: ISP2532: PCIe (5.0GT/s x8) @ 0106:a0:00.1 
>> hdma- host#=2 fw=8.06.00 (90d5).
>> 0:00.0]-500a:1: LOOP UP detected (8 Gbps). 
>> qla2xxx [0106:a0:00.1]-500a:2: LOOP UP detected (8 Gbps).
>> list_add double add: new=8d33e594, prev=8d33e594, 
>> next=adef1df4.
>> [ cut here ]
>> kernel BUG at lib/list_debug.c:31! 
>> Oops: Exception in kernel mode, sig: 5 [#1]
>> LE SMP NR_CPUS=2048 NUMA pSeries 
>> Dumping ftrace buffer: 
>>   (ftrace buffer empty)
>> Modules linked in: qla2xxx(E) tg3(E) ibmveth(E) xt_CHECKSUM(E)
>> iptable_mangle(E) ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E)
>> iptable_nat(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack_ipv4(E)
>> nf_defrag_ipv4(E) xt_conntrack(E) nf_conntrack(E) ipt_REJECT(E)
>> nf_reject_ipv4(E) tun(E) bridge(E) stp(E) llc(E) kvm_pr(E) kvm(E)
>> sctp_diag(E) sctp(E) libcrc32c(E) tcp_diag(E) udp_diag(E)
>> ebtable_filter(E) ebtables(E) dccp_diag(E) ip6table_filter(E) dccp(E)
>> ip6_tables(E) iptable_filter(E) inet_diag(E) unix_diag(E)
>> af_packet_diag(E) netlink_diag(E) xts(E) sg(E) vmx_crypto(E)
>> pseries_rng(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E)
>> sunrpc(E) binfmt_misc(E) ip_tables(E) ext4(E) mbcache(E) jbd2(E)
>> fscrypto(E) sd_mod(E) ibmvscsi(E) scsi_transport_srp(E) nvme_fc(E)
>> nvme_fabrics(E) nvme_core(E) scsi_transport_fc(E)
>> ptp(E) pps_core(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
>> [last unloaded: qla2xxx]
>> CPU: 7 PID: 22230 Comm: qla2xxx_1_dpc Tainted: GE
>> 4.15.0-rc2-next-20171211-autotest-autotest #1
>> NIP:  c0511040 LR: c051103c CTR: 00655170
>> REGS: 9b7356fa TRAP: 0700   Tainted: GE 
>> (4.15.0-rc2-next-20171211-autotest-autotest)
>> MSR:  80010282b033   CR: 2222 
>>  XER: 0009  
>> CFAR: c0170594 SOFTE: 0 
>> GPR00: c051103c c000fc293ac0 c10f1d00 0058 
>> GPR04: c0028fcccdd0 c0028fce3798 8000374060b8  
>> GPR08:  c0d435ec 00028ef9 2717 
>> GPR12:  ce734980 c01215d8 c002886996c0 
>> GPR16:  0020 c002813d83f8 0001 
>> GPR20: 2000 2000 0002 c002813dc808 
>> GPR24: 0003 0001 c0027f5a5c20 c002813dced0 
>> GPR28: c0027f5a5d90 c0027f5a5d90 c0027f5a5c00 c002813dc7f8 
>> NIP [c0511040] __list_add_valid+0x70/0xb0
>> LR [c051103c] __list_add_valid+0x6c/0xb0
>> Call Trace:
>> [c000fc293ac0] [c051103c] __list_add_valid+0x6c/0xb0 (unreliable)
>> [c000fc293b20] [d51f1a08] qla24xx_async_gnl+0x108/0x420 [qla2xxx]
>> [c000fc293bc0] [d51e762c] qla2x00_do_work+0x18c/0x8c0 [qla2xxx]
>> [c000fc293ce0] [d51e8180] qla2x00_relogin+0x420/0xff0 [qla2xxx]
>> [c000fc293dc0] [c012172c] kthread+0x15c/0x1a0
>> [c000fc293e30] [c000b4e8] ret_from_kernel_thread+0x5c/0x74
>> Instruction dump:
>> 41de0018 38210060 3861 e8010010 7c0803a6 4e800020 3c62ffae 7d445378 
>> 38631748 7d254b78 4bc5f51d 6000 <0fe0> 3c62ffae 7cc43378 386316f8 
>> ---[ end trace a41bc8bd434657f1 ]---
>> 
>> Kernel panic - not syncing: Fatal exception
>> Dumping ftrace buffer: 
>>   (ftrace buffer empty)
>> Rebooting in 10 seconds..
>> 
>> This trace back to the below code path:
>> 
>> # gdb -batch vmlinux -ex 'list *(0xc0511040)'
>> 0xc0511040 is in __list_add_valid (lib/list_debug.c:29).
>> 24   "list_add corruption. next->prev should be prev 
>> (%p), 

Re: [PATCH 07/11] powerpc/64s: Add support for RFI flush of L1-D cache

[Michael Ellerman]

Joel Stanley  writes:

> On Mon, Jan 8, 2018 at 8:54 AM, Michael Ellerman  wrote:
>> On some CPUs we can prevent the Meltdown vulnerability by flushing the
>> L1-D cache on exit from kernel to user mode, and from hypervisor to
>> guest.
>
> Super minor nitpicks below. Don't let this hold up your work.
>
>> --- a/arch/powerpc/kernel/exceptions-64s.S
>> +++ b/arch/powerpc/kernel/exceptions-64s.S
>> @@ -1449,6 +1449,88 @@ masked_##_H##interrupt:   
>>\
>> b   .;  \
>> MASKED_DEC_HANDLER(_H)
>>
>> +TRAMP_REAL_BEGIN(rfi_flush_fallback)
>> +   SET_SCRATCH0(r13);
>> +   GET_PACA(r13);
>> +   std r9,PACA_EXRFI+EX_R9(r13)
>> +   std r10,PACA_EXRFI+EX_R10(r13)
>> +   std r11,PACA_EXRFI+EX_R11(r13)
>> +   std r12,PACA_EXRFI+EX_R12(r13)
>> +   std r8,PACA_EXRFI+EX_R13(r13)
>> +   mfctr   r9
>> +   ld  r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13)
>> +   ld  r11,PACA_L1D_FLUSH_SETS(r13)
>> +   ld  r12,PACA_L1D_FLUSH_CONGRUENCE(r13)
>> +   /*
>> +* The load adresses are at staggered offsets within cachelines,
>> +* which suits some pipelines better (on others it should not
>> +* hurt.
>
> Nit: missing ) on the last line.

Thanks.

>> --- a/arch/powerpc/lib/feature-fixups.c
>> +++ b/arch/powerpc/lib/feature-fixups.c
>> @@ -116,6 +116,47 @@ void do_feature_fixups(unsigned long value, void 
>> *fixup_start, void *fixup_end)
>> }
>>  }
>>
>> +#ifdef CONFIG_PPC_BOOK3S_64
>> +void do_rfi_flush_fixups(enum l1d_flush_type types)
>> +{
>> +   unsigned int instrs[3], *dest;
>> +   long *start, *end;
>> +   int i;
>> +
>> +   start = PTRRELOC(&__start___rfi_flush_fixup),
>> +   end = PTRRELOC(&__stop___rfi_flush_fixup);
>> +
>> +   instrs[0] = 0x6000; /* nop */
>> +   instrs[1] = 0x6000; /* nop */
>> +   instrs[2] = 0x6000; /* nop */
>> +
>> +   if (types & L1D_FLUSH_FALLBACK)
>
> This looked a bit confusing on first read. Do we ever get
> L1D_FLUSH_FALLBACK and the other types? If not, could it be made
> clearer?
>
>   if ( types & L1D_FLUSH_FALLBACK)
>   /* stuff */
>   else
> /* other types */

Yeah that would make more sense.

I'm going to merge it as-is because that's whats been tested, and given
the time of day I'm likely to break it if I try and refactor it. So we
can clean it up once it's merged.

cheers

Re: [PATCH 05/67] dma-mapping: replace PCI_DMA_BUS_IS_PHYS with a flag in struct dma_map_ops

[Jesper Nilsson]

On Fri, Dec 29, 2017 at 09:18:09AM +0100, Christoph Hellwig wrote:
> The current PCI_DMA_BUS_IS_PHYS decided if a dma implementation is bound
> by the dma mask in the device because it directly maps to a physical
> address range (modulo an offset in the device), or if it is virtualized
> by an iommu and can map any address (that includes virtual iommus like
> swiotlb).  The problem with this scheme is that it is per-architecture and
> not per dma_ops instance, and we are growing more and more setups that
> have multiple different dma operations in use on a single system, for
> which this scheme can't provide a correct answer.  Depending on the
> architecture that means we either get a false positive or false negative
> at the moment.
> 
> This patch instead extents the is_phys flag in struct dma_map_ops that
> is currently only used by a few architectures to be used tree wide.
> 
> Note that this means that we now need a struct device parent in the
> Scsi_Host or netdevice.  Every modern driver has these, but there might
> still be a few outdated legacy drivers out there, which now won't make
> an intelligent decision.
> 
> Signed-off-by: Christoph Hellwig 

For the CRIS part:

Acked-by: Jesper Nilsson 

> ---
>  arch/cris/arch-v32/drivers/pci/dma.c  |  1 +
>  arch/cris/include/asm/pci.h   |  6 --

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com

Re: [PATCH 22/67] dma-mapping: clear harmful GFP_* flags in common code

[Jesper Nilsson]

On Fri, Dec 29, 2017 at 09:18:26AM +0100, Christoph Hellwig wrote:
> Life the code from x86 so that we behave consistently.  In the future we
> should probably warn if any of these is set.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: Jesper Nilsson 

> ---
>  arch/cris/arch-v32/drivers/pci/dma.c  | 3 ---

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com

Re: [linux-next][qla2xxx][85caa95]kernel BUG at lib/list_debug.c:31!

[Bart Van Assche]

On Tue, 2018-01-09 at 14:44 +0530, Abdul Haleem wrote:
> Greeting's, 
> 
> Linux next kernel panics on powerpc when module qla2xxx is load/unload.
> 
> Machine Type: Power 8 PowerVM LPAR
> Kernel : 4.15.0-rc2-next-20171211
> gcc : version 4.8.5
> Test type: module load/unload few times
> 
> Trace messages:
> ---
> qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 10.00.00.03-k.
> qla2xxx [0106:a0:00.0]-001a: : MSI-X vector count: 32.
> qla2xxx [0106:a0:00.0]-001d: : Found an ISP2532 irq 505 iobase 
> 0xaeb324e6.
> qla2xxx [0106:a0:00.0]-00c6:1: MSI-X: Failed to enable support with 32 
> vectors, using 16 vectors.
> qla2xxx [0106:a0:00.0]-00fb:1: QLogic QLE2562 - PCIe 2-port 8Gb FC Adapter.
> qla2xxx [0106:a0:00.0]-00fc:1: ISP2532: PCIe (5.0GT/s x8) @ 0106:a0:00.0 
> hdma- host#=1 fw=8.06.00 (90d5).
> qla2xxx [0106:a0:00.1]-001a: : MSI-X vector count: 32.
> qla2xxx [0106:a0:00.1]-001d: : Found an ISP2532 irq 506 iobase 
> 0xa46f1774.
> qla2xxx [0106:a0:00.1]-00c6:2: MSI-X: Failed to enable support with 32 
> vectors, using 16 vectors.
> 2xxx
> qla2xxx [0106:a0:00.1]-00fb:2: QLogic QLE2562 - PCIe 2-port 8Gb FC Adapter.
> qla2xxx [0106:a0:00.1]-00fc:2: ISP2532: PCIe (5.0GT/s x8) @ 0106:a0:00.1 
> hdma- host#=2 fw=8.06.00 (90d5).
> 0:00.0]-500a:1: LOOP UP detected (8 Gbps). 
> qla2xxx [0106:a0:00.1]-500a:2: LOOP UP detected (8 Gbps).
> list_add double add: new=8d33e594, prev=8d33e594, 
> next=adef1df4.
> [ cut here ]
> kernel BUG at lib/list_debug.c:31! 
> Oops: Exception in kernel mode, sig: 5 [#1]
> LE SMP NR_CPUS=2048 NUMA pSeries 
> Dumping ftrace buffer: 
>(ftrace buffer empty)
> Modules linked in: qla2xxx(E) tg3(E) ibmveth(E) xt_CHECKSUM(E)
> iptable_mangle(E) ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E)
> iptable_nat(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack_ipv4(E)
> nf_defrag_ipv4(E) xt_conntrack(E) nf_conntrack(E) ipt_REJECT(E)
> nf_reject_ipv4(E) tun(E) bridge(E) stp(E) llc(E) kvm_pr(E) kvm(E)
> sctp_diag(E) sctp(E) libcrc32c(E) tcp_diag(E) udp_diag(E)
> ebtable_filter(E) ebtables(E) dccp_diag(E) ip6table_filter(E) dccp(E)
> ip6_tables(E) iptable_filter(E) inet_diag(E) unix_diag(E)
> af_packet_diag(E) netlink_diag(E) xts(E) sg(E) vmx_crypto(E)
> pseries_rng(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E)
> sunrpc(E) binfmt_misc(E) ip_tables(E) ext4(E) mbcache(E) jbd2(E)
> fscrypto(E) sd_mod(E) ibmvscsi(E) scsi_transport_srp(E) nvme_fc(E)
> nvme_fabrics(E) nvme_core(E) scsi_transport_fc(E)
>  ptp(E) pps_core(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
> [last unloaded: qla2xxx]
> CPU: 7 PID: 22230 Comm: qla2xxx_1_dpc Tainted: GE
> 4.15.0-rc2-next-20171211-autotest-autotest #1
> NIP:  c0511040 LR: c051103c CTR: 00655170
> REGS: 9b7356fa TRAP: 0700   Tainted: GE 
> (4.15.0-rc2-next-20171211-autotest-autotest)
> MSR:  80010282b033   CR: 2222  
> XER: 0009  
> CFAR: c0170594 SOFTE: 0 
> GPR00: c051103c c000fc293ac0 c10f1d00 0058 
> GPR04: c0028fcccdd0 c0028fce3798 8000374060b8  
> GPR08:  c0d435ec 00028ef9 2717 
> GPR12:  ce734980 c01215d8 c002886996c0 
> GPR16:  0020 c002813d83f8 0001 
> GPR20: 2000 2000 0002 c002813dc808 
> GPR24: 0003 0001 c0027f5a5c20 c002813dced0 
> GPR28: c0027f5a5d90 c0027f5a5d90 c0027f5a5c00 c002813dc7f8 
> NIP [c0511040] __list_add_valid+0x70/0xb0
> LR [c051103c] __list_add_valid+0x6c/0xb0
> Call Trace:
> [c000fc293ac0] [c051103c] __list_add_valid+0x6c/0xb0 (unreliable)
> [c000fc293b20] [d51f1a08] qla24xx_async_gnl+0x108/0x420 [qla2xxx]
> [c000fc293bc0] [d51e762c] qla2x00_do_work+0x18c/0x8c0 [qla2xxx]
> [c000fc293ce0] [d51e8180] qla2x00_relogin+0x420/0xff0 [qla2xxx]
> [c000fc293dc0] [c012172c] kthread+0x15c/0x1a0
> [c000fc293e30] [c000b4e8] ret_from_kernel_thread+0x5c/0x74
> Instruction dump:
> 41de0018 38210060 3861 e8010010 7c0803a6 4e800020 3c62ffae 7d445378 
> 38631748 7d254b78 4bc5f51d 6000 <0fe0> 3c62ffae 7cc43378 386316f8 
> ---[ end trace a41bc8bd434657f1 ]---
> 
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer: 
>(ftrace buffer empty)
> Rebooting in 10 seconds..
> 
> This trace back to the below code path:
> 
> # gdb -batch vmlinux -ex 'list *(0xc0511040)'
> 0xc0511040 is in __list_add_valid (lib/list_debug.c:29).
> 24"list_add corruption. next->prev should be prev 
> (%p), but was %p. (next=%p).\n",
> 25prev, next->prev, next) ||
> 26CHECK_DATA_CORRUPTION(prev->next != next,
> 27 

Re: [PATCH 34/67] cris: use dma-direct

[Jesper Nilsson]

On Fri, Dec 29, 2017 at 09:18:38AM +0100, Christoph Hellwig wrote:
> cris currently has an incomplete direct mapping dma_map_ops implementation
> is PCI support is enabled.  Replace it with the fully feature generic
> dma-direct implementation.
> 
> Signed-off-by: Christoph Hellwig 

For CRIS:

Acked-by: Jesper Nilsson 

> ---
>  arch/cris/Kconfig   |  4 ++
>  arch/cris/arch-v32/drivers/pci/Makefile |  2 +-
>  arch/cris/arch-v32/drivers/pci/dma.c| 78 
> -
>  arch/cris/include/asm/Kbuild|  1 +
>  arch/cris/include/asm/dma-mapping.h | 20 -
>  5 files changed, 6 insertions(+), 99 deletions(-)
>  delete mode 100644 arch/cris/arch-v32/drivers/pci/dma.c
>  delete mode 100644 arch/cris/include/asm/dma-mapping.h
> 

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com

[PATCH V6] cxl: Add support for ASB_Notify on POWER9

[Christophe Lombard]

The POWER9 core supports a new feature: ASB_Notify which requires the
support of the Special Purpose Register: TIDR.

The ASB_Notify command, generated by the AFU, will attempt to
wake-up the host thread identified by the particular LPID:PID:TID.

This patch assign a unique TIDR (thread id) for the current thread which
will be used in the process element entry.

Signed-off-by: Christophe Lombard 
Reviewed-by: Philippe Bergheaud 

---
Changelog[v6]
 - Rebased to latest upstream.
 - Updated the ioctl interface.
 - Removed the updated ptrace.
 - Assigned a unique TIDR for the current thread at a lower level.

Changelog[v5]
 - Rebased to latest upstream.
 - Updated the ioctl interface.
 - Returned the tid in the ioctl structure.

Changelog[v4]
 - Rebased to latest upstream.
 - Updated the ioctl interface.
 - Removed the field tid in the context structure.

Changelog[v3]
 - Rebased to latest upstream.
 - Updated attr->tid field in cxllib_get_PE_attributes().

Changelog[v2]
 - Rebased to latest upstream.
 - Updated the ioctl interface.
 - Added a checking to allow updating the TIDR if a P9 chip is present.
---
 arch/powerpc/kernel/process.c |  1 +
 drivers/misc/cxl/context.c|  1 +
 drivers/misc/cxl/cxl.h|  3 +++
 drivers/misc/cxl/cxllib.c |  3 ++-
 drivers/misc/cxl/file.c   | 10 +-
 drivers/misc/cxl/native.c | 13 -
 include/uapi/misc/cxl.h   | 10 ++
 7 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 72be0c3..1dc39dd 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1589,6 +1589,7 @@ int set_thread_tidr(struct task_struct *t)
 
return 0;
 }
+EXPORT_SYMBOL_GPL(set_thread_tidr);
 
 #endif /* CONFIG_PPC64 */
 
diff --git a/drivers/misc/cxl/context.c b/drivers/misc/cxl/context.c
index 12a41b2..9a1c6b9 100644
--- a/drivers/misc/cxl/context.c
+++ b/drivers/misc/cxl/context.c
@@ -45,6 +45,7 @@ int cxl_context_init(struct cxl_context *ctx, struct cxl_afu 
*afu, bool master)
ctx->pid = NULL; /* Set in start work ioctl */
mutex_init(&ctx->mapping_lock);
ctx->mapping = NULL;
+   ctx->tidr = 0;
 
if (cxl_is_power8()) {
spin_lock_init(&ctx->sste_lock);
diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
index e46a406..86ae215 100644
--- a/drivers/misc/cxl/cxl.h
+++ b/drivers/misc/cxl/cxl.h
@@ -630,6 +630,9 @@ struct cxl_context {
struct list_head extra_irq_contexts;
 
struct mm_struct *mm;
+
+   u16 tidr;
+   u64 wflags;
 };
 
 struct cxl_irq_info;
diff --git a/drivers/misc/cxl/cxllib.c b/drivers/misc/cxl/cxllib.c
index dc9bc18..30ccba4 100644
--- a/drivers/misc/cxl/cxllib.c
+++ b/drivers/misc/cxl/cxllib.c
@@ -199,10 +199,11 @@ int cxllib_get_PE_attributes(struct task_struct *task,
 */
attr->pid = mm->context.id;
mmput(mm);
+   attr->tid = task->thread.tidr;
} else {
attr->pid = 0;
+   attr->tid = 0;
}
-   attr->tid = 0;
return 0;
 }
 EXPORT_SYMBOL_GPL(cxllib_get_PE_attributes);
diff --git a/drivers/misc/cxl/file.c b/drivers/misc/cxl/file.c
index 76c0b0c..e28aefb 100644
--- a/drivers/misc/cxl/file.c
+++ b/drivers/misc/cxl/file.c
@@ -173,7 +173,7 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,
 * flags are set it's invalid
 */
if (work.reserved1 || work.reserved2 || work.reserved3 ||
-   work.reserved4 || work.reserved5 || work.reserved6 ||
+   work.reserved4 || work.reserved5 ||
(work.flags & ~CXL_START_WORK_ALL)) {
rc = -EINVAL;
goto out;
@@ -186,6 +186,7 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,
rc =  -EINVAL;
goto out;
}
+
if ((rc = afu_register_irqs(ctx, work.num_interrupts)))
goto out;
 
@@ -193,6 +194,7 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,
amr = work.amr & mfspr(SPRN_UAMOR);
 
ctx->mmio_err_ff = !!(work.flags & CXL_START_WORK_ERR_FF);
+   ctx->wflags = work.flags;
 
/*
 * Increment the mapped context count for adapter. This also checks
@@ -263,6 +265,12 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,
goto out;
}
 
+   if (work.flags & CXL_START_WORK_TID) {
+   work.tid = ctx->tidr;
+   if (copy_to_user(uwork, &work, sizeof(work)))
+   return -EFAULT;
+   }
+
ctx->status = STARTED;
rc = 0;
 out:
diff --git a/drivers/misc/cxl/native.c b/drivers/misc/cxl/native.c
index 02b6b45..0cccf27 100644
--- a/drivers/misc/cxl/native.c
+++ b/drivers/misc/cxl/native.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "cxl.h"
@@ -655,6 +656,7 @@ static void update_ivtes_directed(stru

Re: [PATCH 10/13] ocxl: Add Makefile and Kconfig

[Frederic Barrat]

Le 03/01/2018 à 06:48, Andrew Donnellan a écrit :

On 19/12/17 02:21, Frederic Barrat wrote:

OCXL_BASE triggers the platform support needed by the driver.

Signed-off-by: Frederic Barrat 
---
  drivers/misc/Kconfig   |  1 +
  drivers/misc/Makefile  |  1 +
  drivers/misc/ocxl/Kconfig  | 25 +
  drivers/misc/ocxl/Makefile | 10 ++
  4 files changed, 37 insertions(+)
  create mode 100644 drivers/misc/ocxl/Kconfig
  create mode 100644 drivers/misc/ocxl/Makefile

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f1a5c2357b14..0534f338c84a 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -508,4 +508,5 @@ source "drivers/misc/mic/Kconfig"
  source "drivers/misc/genwqe/Kconfig"
  source "drivers/misc/echo/Kconfig"
  source "drivers/misc/cxl/Kconfig"
+source "drivers/misc/ocxl/Kconfig"
  endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 5ca5f64df478..73326d54e246 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_CXL_BASE)    += cxl/
  obj-$(CONFIG_ASPEED_LPC_CTRL)    += aspeed-lpc-ctrl.o
  obj-$(CONFIG_ASPEED_LPC_SNOOP)    += aspeed-lpc-snoop.o
  obj-$(CONFIG_PCI_ENDPOINT_TEST)    += pci_endpoint_test.o
+obj-$(CONFIG_OCXL)    += ocxl/

  lkdtm-$(CONFIG_LKDTM)    += lkdtm_core.o
  lkdtm-$(CONFIG_LKDTM)    += lkdtm_bugs.o
diff --git a/drivers/misc/ocxl/Kconfig b/drivers/misc/ocxl/Kconfig
new file mode 100644
index ..4496b61f48db
--- /dev/null
+++ b/drivers/misc/ocxl/Kconfig
@@ -0,0 +1,25 @@
+#
+# Open Coherent Accelerator (OCXL) compatible devices
+#
+
+config OCXL_BASE
+    bool
+    default n
+    select PPC_COPRO_BASE
+
+config OCXL
+    tristate "Support for Open Coherent Accelerators (OCXL)"
+    depends on PPC_POWERNV && PCI && EEH
+    select OCXL_BASE
+    default m
+    help
+
+  Select this option to enable driver support for Open
+  Coherent Accelerators (OCXL).  OCXL is otherwise known as
+  Open Coherent Accelerator Processor Interface (OCAPI).
+  OCAPI allows accelerators in FPGAs to be coherently attached
+  to a CPU through a Open CAPI link.  This driver enables
+  userspace programs to access these accelerators through
+  devices found in /dev/ocxl/


I'd prefer more consistency in how we refer to OpenCAPI. "ocxl" is a 
driver name that we have purely for historical reasons, it's not really 
the name of anything else. I know throughout the various specs and code, 
we use "OCAPI" a lot, but that's not really an abbreviation that should 
be "user-facing".


Something like:

config OCXL
  tristate "OpenCAPI coherent accelerator support"
  help

    Select this option to enable the ocxl driver for Open Coherent
    Accelerator Processor Interface (OpenCAPI) devices.

    OpenCAPI allows FPGA and ASIC accelerators to be coherently
    attached to a CPU over an OpenCAPI link.

    The ocxl driver enables userspace programs to access these
    accelerators through devices in /dev/ocxl/.

    For more information, see http://opencapi.org.

    If unsure, say N.



Agreed, and stolen.

  Fred



+
+  If unsure, say N.
diff --git a/drivers/misc/ocxl/Makefile b/drivers/misc/ocxl/Makefile
new file mode 100644
index ..f75853411cfd
--- /dev/null
+++ b/drivers/misc/ocxl/Makefile
@@ -0,0 +1,10 @@
+ccflags-$(CONFIG_PPC_WERROR)    += -Werror
+
+ocxl-y    += main.o pci.o config.o file.o pasid.o
+ocxl-y    += link.o context.o afu_irq.o sysfs.o trace.o
+obj-$(CONFIG_OCXL)    += ocxl.o
+
+# For tracepoints to include our trace.h from tracepoint infrastructure:
+CFLAGS_trace.o := -I$(src)
+
+# ccflags-y += -DDEBUG

Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_

[Christoph Hellwig]

On Thu, Jan 04, 2018 at 09:49:30AM +0100, Christoph Hellwig wrote:
> On Tue, Jan 02, 2018 at 08:45:30PM +1100, Michael Ellerman wrote:
> > Christoph Hellwig  writes:
> > 
> > > We want to use the dma_direct_ namespace for a generic implementation,
> > > so rename powerpc to the second best choice: dma_nommu_.
> > 
> > I'm not a fan of "nommu". Some of the users of direct ops *are* using an
> > IOMMU, they're just setting up a 1:1 mapping once at init time, rather
> > than mapping dynamically.
> > 
> > Though I don't have a good idea for a better name, maybe "1to1",
> > "linear", "premapped" ?
> 
> It seems like a nice counter part to the dma_iommu_ops used just about
> anywhere else in ppc.
> 
> But I'll happily take any maintainer bike shed decision for the next
> series.  Remember that in a merge window or two it will hopefully
> go away in favor of the new generic dma_direct ops.

Michael, please suggest what name you want for the next iteration,
I don't want to hold up the series on a naming bikeshed.

Re: Sleep in preempt_disable on powernv with 'cat /proc/cpuinfo' on v4.15

[Michael Ellerman]

Benjamin Herrenschmidt  writes:

> On Mon, 2018-01-08 at 21:30 -0800, John Sperbeck wrote:
>> The pnv_get_proc_freq() function was recently changed to call
>> cpufreq_get(), instead of cpufreq_quick_get(), in order to fetch
>> a more up-to-date value for the CPU frequency:
>> 
>>cd77b5ce208c153260ed7882d8910f2395bfaabd
>>powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo
>> 
>> Unfortunately, this function is called from show_cpuinfo() in
>> arch/powerpc/kernel/setup-common.c with preemption disabled.  The
>> cpufreq_get() function might do a down_read(), which can sleep.
>> 
>> With CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_ATOMIC_SLEEP set, a warning
>> like the following is generated when running 'cat /proc/cpuinfo':

This was reported by Nick back in November just a few days after the
patch went in, so it's a little disappointing that it's still broken.

> We could just either remove the preempt_disable completely like
> x86 and keep it racy, or stick a cpus_read_lock around it. I dont think
> we need that preempt_disable, it's definitely overkill.
>
> Michael, what do you think ? I'm keen on sync'ing with x86 here...

Yeah I think we can drop it. The cpufreq seems to have some locking that
looks like it'll probably work - famous last words.

Who's writing the patch?

cheers

Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[Michael Ellerman]

Greg Kurz  writes:

> On Tue, 9 Jan 2018 23:44:56 +1100
> Alexey Kardashevskiy  wrote:
>
>> On 09/01/18 19:39, Suraj Jitindar Singh wrote:
> [...]
>> >> + rc = plpar_get_cpu_characteristics(&c);
>> >> + if (rc == H_SUCCESS) {
>> >> + if (!(c.behavior &   
>> > 
>> > s/behavior/behaviour  
>> 
>> Why?
>> https://dictionary.cambridge.org/dictionary/english/behavior
>> 
>
> Behavior is US English while behaviour is UK (and US)... Matter of taste ? :)

Straya mate!

cheers

Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[kbuild test robot]

Hi Paul,

I love your patch! Yet something to improve:

[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.15-rc7 next-20180109]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Paul-Mackerras/KVM-PPC-Book3S-Add-capabilities-for-Meltdown-Spectre-workarounds/20180109-165503
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   arch/powerpc/kvm/powerpc.c: In function 'check_pseries_safe_cache':
>> arch/powerpc/kvm/powerpc.c:527:27: error: storage size of 'c' isn't known
 struct h_cpu_char_result c;
  ^
>> arch/powerpc/kvm/powerpc.c:534:7: error: implicit declaration of function 
>> 'plpar_get_cpu_characteristics' [-Werror=implicit-function-declaration]
 rc = plpar_get_cpu_characteristics(&c);
  ^
>> arch/powerpc/kvm/powerpc.c:536:22: error: 
>> 'H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV' undeclared (first use in this 
>> function)
  if (!(c.behavior & H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV))
 ^~
   arch/powerpc/kvm/powerpc.c:536:22: note: each undeclared identifier is 
reported only once for each function it appears in
>> arch/powerpc/kvm/powerpc.c:538:27: error: 'H_GET_CPU_CHAR_CHAR_L1D_PRIVATE' 
>> undeclared (first use in this function); did you mean 
>> 'H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV'?
  else if ((c.character & H_GET_CPU_CHAR_CHAR_L1D_PRIVATE) &&
  ^~~
  H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV
>> arch/powerpc/kvm/powerpc.c:539:21: error: 
>> 'H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH' undeclared (first use in this 
>> function); did you mean 'H_GET_CPU_CHAR_CHAR_L1D_PRIVATE'?
((c.character & H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH) ||
^~
H_GET_CPU_CHAR_CHAR_L1D_PRIVATE
>> arch/powerpc/kvm/powerpc.c:540:21: error: 
>> 'H_GET_CPU_CHAR_CHAR_MTTRIG2_L1_FLUSH' undeclared (first use in this 
>> function); did you mean 'H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH'?
 (c.character & H_GET_CPU_CHAR_CHAR_MTTRIG2_L1_FLUSH)))
^~~~
H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH
   arch/powerpc/kvm/powerpc.c:527:27: warning: unused variable 'c' 
[-Wunused-variable]
 struct h_cpu_char_result c;
  ^
   arch/powerpc/kvm/powerpc.c: In function 'check_pseries_safe_bounds_check':
   arch/powerpc/kvm/powerpc.c:549:27: error: storage size of 'c' isn't known
 struct h_cpu_char_result c;
  ^
>> arch/powerpc/kvm/powerpc.c:558:22: error: 
>> 'H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK' undeclared (first use in this 
>> function)
  if (!(c.behavior & H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK))
 ^~
>> arch/powerpc/kvm/powerpc.c:560:26: error: 
>> 'H_GET_CPU_CHAR_CHAR_ORI31_SPEC_BAR' undeclared (first use in this 
>> function); did you mean 'H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK'?
  else if (c.character & H_GET_CPU_CHAR_CHAR_ORI31_SPEC_BAR)
 ^~
 H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK
   arch/powerpc/kvm/powerpc.c:549:27: warning: unused variable 'c' 
[-Wunused-variable]
 struct h_cpu_char_result c;
  ^
   arch/powerpc/kvm/powerpc.c: In function 'check_pseries_safe_indirect_branch':
   arch/powerpc/kvm/powerpc.c:569:27: error: storage size of 'c' isn't known
 struct h_cpu_char_result c;
  ^
>> arch/powerpc/kvm/powerpc.c:578:21: error: 'H_GET_CPU_CHAR_CHAR_BCCTR_SERIAL' 
>> undeclared (first use in this function)
  if (c.character & H_GET_CPU_CHAR_CHAR_BCCTR_SERIAL)
^~~~
   arch/powerpc/kvm/powerpc.c:569:27: warning: unused variable 'c' 
[-Wunused-variable]
 struct h_cpu_char_result c;
   

Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[Greg Kurz]

On Tue, 9 Jan 2018 23:44:56 +1100
Alexey Kardashevskiy  wrote:

> On 09/01/18 19:39, Suraj Jitindar Singh wrote:
[...]
> >> +  rc = plpar_get_cpu_characteristics(&c);
> >> +  if (rc == H_SUCCESS) {
> >> +  if (!(c.behavior &   
> > 
> > s/behavior/behaviour  
> 
> Why?
> https://dictionary.cambridge.org/dictionary/english/behavior
> 

Behavior is US English while behaviour is UK (and US)... Matter of taste ? :)

> 
> 

Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[Alexey Kardashevskiy]

On 09/01/18 19:39, Suraj Jitindar Singh wrote:
> On Tue, 2018-01-09 at 15:48 +1100, Paul Mackerras wrote:
>> This adds three new capabilities that give userspace information
>> about
>> the underlying machine's level of vulnerability to the Meltdown and
>> Spectre attacks, and what instructions the hardware implements to
>> assist software to work around the vulnerabilities.
>>
>> Each capability is a tri-state, where 0 indicates that the machine is
>> vulnerable and no workarounds are implement, 1 indicates that the
>> machine is vulnerable but workaround assist instructions are
>> available, and 2 indicates that the machine is not vulnerable.
>>
>> The capabilities are:
>>
>> KVM_CAP_PPC_SAFE_CACHE reports the vulnerability of the machine to
>> attacks based on using speculative loads to data in L1 cache which
>> should not be addressable.  The workaround provided by hardware is an
>> instruction to invalidate the entire L1 data cache.
>>
>> KVM_CAP_PPC_SAFE_BOUNDS_CHECK reports the vulnerability of the
>> machine
>> to attacks based on using speculative loads behind mispredicted
>> bounds
>> checks.  The workaround provided by hardware is an instruction that
>> acts as a speculation barrier.
>>
>> KVM_CAP_PPC_SAFE_INDIRECT_BRANCH reports the vulnerability of the
>> machine to attacks based on poisoning the indirect branch predictor.
>> No workaround that requires software changes is provided; the current
>> hardware fix is to prevent speculation past indirect branches.
>>
>> Signed-off-by: Paul Mackerras 
>> ---
>> Note: This patch depends on the patch "powerpc/pseries: Add
>> H_GET_CPU_CHARACTERISTICS flags & wrapper" by Michael Ellerman,
>> available at http://patchwork.ozlabs.org/patch/856914/ .
>>
>>  Documentation/virtual/kvm/api.txt |  36 +++
>>  arch/powerpc/kvm/powerpc.c| 202
>> ++
>>  include/uapi/linux/kvm.h  |   3 +
>>  3 files changed, 241 insertions(+)
>>
>> diff --git a/Documentation/virtual/kvm/api.txt
>> b/Documentation/virtual/kvm/api.txt
>> index 57d3ee9..8d76260 100644
>> --- a/Documentation/virtual/kvm/api.txt
>> +++ b/Documentation/virtual/kvm/api.txt
>> @@ -4369,3 +4369,39 @@ Parameters: none
>>  This capability indicates if the flic device will be able to get/set
>> the
>>  AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and
>> allows
>>  to discover this without having to create a flic device.
>> +
>> +8.14 KVM_CAP_PPC_SAFE_CACHE
>> +
>> +Architectures: ppc
>> +
>> +This capability gives information about the underlying machine's
>> +vulnerability or otherwise to the Meltdown attack.  Its value is a
>> +tristate, where 0 indicates the machine is vulnerable, 1 indicates
>> the
>> +hardware is vulnerable but provides assistance to work around the
>> +vulnerability (specifically by providing a fast L1 data cache flush
>> +facility), and 2 indicates that the machine is not vulnerable.
>> +
>> +8.15 KVM_CAP_PPC_SAFE_BOUNDS_CHECK
>> +
>> +Architectures: ppc
>> +
>> +This capability gives information about the underlying machine's
>> +vulnerability or otherwise to the bounds-check variant of the
>> Spectre
>> +attack.  Its value is a tristate, where 0 indicates the machine is
>> +vulnerable, 1 indicates the hardware is vulnerable but provides
>> +assistance to work around the vulnerability (specifically by
>> providing
>> +an instruction that acts as a speculation barrier), and 2 indicates
>> +that the machine is not vulnerable.
>> +
>> +8.16 KVM_CAP_PPC_SAFE_INDIRECT_BRANCH
>> +
>> +Architectures: ppc
>> +
>> +This capability gives information about the underlying machine's
>> +vulnerability or otherwise to the indirect branch variant of the
>> Spectre
>> +attack.  Its value is a tristate, where 0 indicates the machine is
>> +vulnerable and 2 indicates that the machine is not vulnerable.
>> +(1 would indicate the availability of a workaround that software
>> +needs to implement, but there is currently no workaround that needs
>> +software changes.)
>> +
>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>> index 1915e86..58e863b 100644
>> --- a/arch/powerpc/kvm/powerpc.c
>> +++ b/arch/powerpc/kvm/powerpc.c
>> @@ -39,6 +39,10 @@
>>  #include 
>>  #include 
>>  #include 
>> +#ifdef CONFIG_PPC_PSERIES
>> +#include 
>> +#include 
>> +#endif
>>  
>>  #include "timing.h"
>>  #include "irq.h"
>> @@ -488,6 +492,193 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
>>  module_put(kvm->arch.kvm_ops->owner);
>>  }
>>  
>> +#ifdef CONFIG_PPC_BOOK3S_64
>> +/*
>> + * These functions check whether the underlying hardware is safe
>> + * against the Meltdown/Spectre attacks and whether it supplies
>> + * instructions for use in workarounds.  The information comes from
>> + * firmware, either via the device tree on powernv platforms or
>> + * from an hcall on pseries platforms.
>> + *
>> + * For check_safe_cache() and check_safe_bounds_check(), a return
>> + * value of 0 means vulnerable, 1 means vulnerable but 

Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[joserz]

On Tue, Jan 09, 2018 at 12:57:26PM +0100, Michal Suchánek wrote:
> On Tue, 09 Jan 2018 19:39:14 +1100
> Suraj Jitindar Singh  wrote:
> 
> > 
> > s/behavior/behaviour
> 
> Nope. Either is valid and the shorter American spelling is actually
> more common.
> 
> If you must nickpick choose something actually broken :p

Suraj is right:

struct h_cpu_char_result {
   u64 character;
   u64 behaviour;
};

> 
> Thanks
> 
> Michal
> 

Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[Michal Suchánek]

On Tue, 09 Jan 2018 19:39:14 +1100
Suraj Jitindar Singh  wrote:

> 
> s/behavior/behaviour

Nope. Either is valid and the shorter American spelling is actually
more common.

If you must nickpick choose something actually broken :p

Thanks

Michal

Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[kbuild test robot]

Hi Paul,

I love your patch! Yet something to improve:

[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.15-rc7 next-20180109]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Paul-Mackerras/KVM-PPC-Book3S-Add-capabilities-for-Meltdown-Spectre-workarounds/20180109-165503
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   arch/powerpc/kvm/powerpc.c: In function 'check_pseries_safe_cache':
   arch/powerpc/kvm/powerpc.c:527:27: error: storage size of 'c' isn't known
 struct h_cpu_char_result c;
  ^
   arch/powerpc/kvm/powerpc.c:534:7: error: implicit declaration of function 
'plpar_get_cpu_characteristics' [-Werror=implicit-function-declaration]
 rc = plpar_get_cpu_characteristics(&c);
  ^
   arch/powerpc/kvm/powerpc.c:536:22: error: 
'H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV' undeclared (first use in this function)
  if (!(c.behavior & H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV))
 ^~
   arch/powerpc/kvm/powerpc.c:536:22: note: each undeclared identifier is 
reported only once for each function it appears in
   arch/powerpc/kvm/powerpc.c:538:27: error: 'H_GET_CPU_CHAR_CHAR_L1D_PRIVATE' 
undeclared (first use in this function); did you mean 
'H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV'?
  else if ((c.character & H_GET_CPU_CHAR_CHAR_L1D_PRIVATE) &&
  ^~~
  H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV
   arch/powerpc/kvm/powerpc.c:539:21: error: 
'H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH' undeclared (first use in this function); 
did you mean 'H_GET_CPU_CHAR_CHAR_L1D_PRIVATE'?
((c.character & H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH) ||
^~
H_GET_CPU_CHAR_CHAR_L1D_PRIVATE
   arch/powerpc/kvm/powerpc.c:540:21: error: 
'H_GET_CPU_CHAR_CHAR_MTTRIG2_L1_FLUSH' undeclared (first use in this function); 
did you mean 'H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH'?
 (c.character & H_GET_CPU_CHAR_CHAR_MTTRIG2_L1_FLUSH)))
^~~~
H_GET_CPU_CHAR_CHAR_ORI30_L1_FLUSH
>> arch/powerpc/kvm/powerpc.c:527:27: error: unused variable 'c' 
>> [-Werror=unused-variable]
 struct h_cpu_char_result c;
  ^
   arch/powerpc/kvm/powerpc.c: In function 'check_pseries_safe_bounds_check':
   arch/powerpc/kvm/powerpc.c:549:27: error: storage size of 'c' isn't known
 struct h_cpu_char_result c;
  ^
   arch/powerpc/kvm/powerpc.c:558:22: error: 
'H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK' undeclared (first use in this function)
  if (!(c.behavior & H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK))
 ^~
   arch/powerpc/kvm/powerpc.c:560:26: error: 
'H_GET_CPU_CHAR_CHAR_ORI31_SPEC_BAR' undeclared (first use in this function); 
did you mean 'H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK'?
  else if (c.character & H_GET_CPU_CHAR_CHAR_ORI31_SPEC_BAR)
 ^~
 H_GET_CPU_CHAR_BEHAV_SPEC_BAR_BNDS_CHK
   arch/powerpc/kvm/powerpc.c:549:27: error: unused variable 'c' 
[-Werror=unused-variable]
 struct h_cpu_char_result c;
  ^
   arch/powerpc/kvm/powerpc.c: In function 'check_pseries_safe_indirect_branch':
   arch/powerpc/kvm/powerpc.c:569:27: error: storage size of 'c' isn't known
 struct h_cpu_char_result c;
  ^
   arch/powerpc/kvm/powerpc.c:578:21: error: 'H_GET_CPU_CHAR_CHAR_BCCTR_SERIAL' 
undeclared (first use in this function)
  if (c.character & H_GET_CPU_CHAR_CHAR_BCCTR_SERIAL)
^~~~
   arch/powerpc/kvm/powerpc.c:569:27: error: unused variable 'c' 
[-Werror=unused-variable]
 struct h_cpu_char_result c;
  ^
   cc1: all warnings being treated as errors

vim +/c +527 arch/powerpc/kvm/powerpc.c

   523  
   524  #ifdef CONFIG_PPC_PSERIES
  

[PATCH v2] powerpc/mm: Fix growth direction for hugepages mmaps with slice

[Christophe Leroy]

An application running with libhugetlbfs fails to allocate
additional pages to HEAP due to the hugemap being done
inconditionally as topdown mapping:

mmap(0x1008, 1572864, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|0x4, -1, 0) = 0x73e8
[...]
mmap(0x7400, 1048576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|0x4, -1, 0x18) = 0x73d8
munmap(0x73d8, 1048576) = 0
[...]
mmap(0x7400, 1572864, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|0x4, -1, 0x18) = 0x73d0
munmap(0x73d0, 1572864) = 0
[...]
mmap(0x7400, 1572864, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|0x4, -1, 0x18) = 0x73d0
munmap(0x73d0, 1572864) = 0
[...]

As one can see from the above strace log, mmap() allocates further
pages below the initial one.

This patch fixes it by taking into account MAP_GROWSDOWN flag.

Fixes: d0f13e3c20b6f ("[POWERPC] Introduce address space "slices" ")
Signed-off-by: Christophe Leroy 
---
 v2: Added missing include

 arch/powerpc/mm/hugetlbpage.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 79e1378ee303..0eadf9f199de 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -558,7 +559,8 @@ unsigned long hugetlb_get_unmapped_area(struct file *file, 
unsigned long addr,
return radix__hugetlb_get_unmapped_area(file, addr, len,
   pgoff, flags);
 #endif
-   return slice_get_unmapped_area(addr, len, flags, mmu_psize, 1);
+   return slice_get_unmapped_area(addr, len, flags, mmu_psize,
+  flags & MAP_GROWSDOWN);
 }
 #endif
 
-- 
2.13.3

Re: [PATCH v2] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[Suraj Jitindar Singh]

On Tue, 2018-01-09 at 20:21 +1100, Paul Mackerras wrote:
> This adds three new capabilities that give userspace information
> about
> the underlying machine's level of vulnerability to the Meltdown and
> Spectre attacks, and what instructions the hardware implements to
> assist software to work around the vulnerabilities.
> 
> Each capability is a tri-state, where 0 indicates that the machine is
> vulnerable and no workarounds are implement, 1 indicates that the
> machine is vulnerable but workaround assist instructions are
> available, and 2 indicates that the machine is not vulnerable.
> 
> The capabilities are:
> 
> KVM_CAP_PPC_SAFE_CACHE reports the vulnerability of the machine to
> attacks based on using speculative loads to data in L1 cache which
> should not be addressable.  The workaround provided by hardware is an
> instruction to invalidate the entire L1 data cache.
> 
> KVM_CAP_PPC_SAFE_BOUNDS_CHECK reports the vulnerability of the
> machine
> to attacks based on using speculative loads behind mispredicted
> bounds
> checks.  The workaround provided by hardware is an instruction that
> acts as a speculation barrier.
> 
> KVM_CAP_PPC_SAFE_INDIRECT_BRANCH reports the vulnerability of the
> machine to attacks based on poisoning the indirect branch predictor.
> No workaround that requires software changes is provided; the current
> hardware fix is to prevent speculation past indirect branches.
> 

Tested-by: Suraj Jitindar Singh 

> Signed-off-by: Paul Mackerras 
> ---
> Note: This patch depends on the patch "powerpc/pseries: Add
> H_GET_CPU_CHARACTERISTICS flags & wrapper" by Michael Ellerman,
> available at http://patchwork.ozlabs.org/patch/856914/ .
> 
>  Documentation/virtual/kvm/api.txt |  35 +++
>  arch/powerpc/kvm/powerpc.c| 202
> ++
>  include/uapi/linux/kvm.h  |   3 +
>  3 files changed, 240 insertions(+)
> 
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index 57d3ee9..7107e52 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -4369,3 +4369,38 @@ Parameters: none
>  This capability indicates if the flic device will be able to get/set
> the
>  AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and
> allows
>  to discover this without having to create a flic device.
> +
> +8.14 KVM_CAP_PPC_SAFE_CACHE
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the Meltdown attack.  Its value is a
> +tristate, where 0 indicates the machine is vulnerable, 1 indicates
> the
> +hardware is vulnerable but provides assistance to work around the
> +vulnerability (specifically by providing a fast L1 data cache flush
> +facility), and 2 indicates that the machine is not vulnerable.
> +
> +8.15 KVM_CAP_PPC_SAFE_BOUNDS_CHECK
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the bounds-check variant of the
> Spectre
> +attack.  Its value is a tristate, where 0 indicates the machine is
> +vulnerable, 1 indicates the hardware is vulnerable but provides
> +assistance to work around the vulnerability (specifically by
> providing
> +an instruction that acts as a speculation barrier), and 2 indicates
> +that the machine is not vulnerable.
> +
> +8.16 KVM_CAP_PPC_SAFE_INDIRECT_BRANCH
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the indirect branch variant of the
> Spectre
> +attack.  Its value is a tristate, where 0 indicates the machine is
> +vulnerable and 2 indicates that the machine is not vulnerable.
> +(1 would indicate the availability of a workaround that software
> +needs to implement, but there is currently no workaround that needs
> +software changes.)
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 1915e86..bef76f8 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -39,6 +39,10 @@
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_PPC_PSERIES
> +#include 
> +#include 
> +#endif
>  
>  #include "timing.h"
>  #include "irq.h"
> @@ -488,6 +492,193 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
>   module_put(kvm->arch.kvm_ops->owner);
>  }
>  
> +#ifdef CONFIG_PPC_BOOK3S_64
> +/*
> + * These functions check whether the underlying hardware is safe
> + * against the Meltdown/Spectre attacks and whether it supplies
> + * instructions for use in workarounds.  The information comes from
> + * firmware, either via the device tree on powernv platforms or
> + * from an hcall on pseries platforms.
> + *
> + * For check_safe_cache() and check_safe_bounds_check(), a return
> + * value of 0 means vulnerable, 1 means vulnerable but workaround
> + * instructions are provided, and 2 means not vulnerable (no
> workaround
> + * is needed).
> + * For check_safe_indi

Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[Paul Mackerras]

On Tue, Jan 09, 2018 at 07:28:35PM +1100, Suraj Jitindar Singh wrote:
[snip]
> > +   rc = plpar_get_cpu_characteristics(&c);
> > +   if (rc == H_SUCCESS) {
> > +   if (!(c.behavior &
> > H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV))
> 
> s/H_GET_CPU_CHAR_BEHAV_L1_FLUSH_LOW_PRIV/H_CPU_BEHAV_L1D_FLUSH_PR

Yes, somehow I managed to post an old version of the patch.  New
version coming.

Paul.

[PATCH v2] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[Paul Mackerras]

This adds three new capabilities that give userspace information about
the underlying machine's level of vulnerability to the Meltdown and
Spectre attacks, and what instructions the hardware implements to
assist software to work around the vulnerabilities.

Each capability is a tri-state, where 0 indicates that the machine is
vulnerable and no workarounds are implement, 1 indicates that the
machine is vulnerable but workaround assist instructions are
available, and 2 indicates that the machine is not vulnerable.

The capabilities are:

KVM_CAP_PPC_SAFE_CACHE reports the vulnerability of the machine to
attacks based on using speculative loads to data in L1 cache which
should not be addressable.  The workaround provided by hardware is an
instruction to invalidate the entire L1 data cache.

KVM_CAP_PPC_SAFE_BOUNDS_CHECK reports the vulnerability of the machine
to attacks based on using speculative loads behind mispredicted bounds
checks.  The workaround provided by hardware is an instruction that
acts as a speculation barrier.

KVM_CAP_PPC_SAFE_INDIRECT_BRANCH reports the vulnerability of the
machine to attacks based on poisoning the indirect branch predictor.
No workaround that requires software changes is provided; the current
hardware fix is to prevent speculation past indirect branches.

Signed-off-by: Paul Mackerras 
---
Note: This patch depends on the patch "powerpc/pseries: Add
H_GET_CPU_CHARACTERISTICS flags & wrapper" by Michael Ellerman,
available at http://patchwork.ozlabs.org/patch/856914/ .

 Documentation/virtual/kvm/api.txt |  35 +++
 arch/powerpc/kvm/powerpc.c| 202 ++
 include/uapi/linux/kvm.h  |   3 +
 3 files changed, 240 insertions(+)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index 57d3ee9..7107e52 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4369,3 +4369,38 @@ Parameters: none
 This capability indicates if the flic device will be able to get/set the
 AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows
 to discover this without having to create a flic device.
+
+8.14 KVM_CAP_PPC_SAFE_CACHE
+
+Architectures: ppc
+
+This capability gives information about the underlying machine's
+vulnerability or otherwise to the Meltdown attack.  Its value is a
+tristate, where 0 indicates the machine is vulnerable, 1 indicates the
+hardware is vulnerable but provides assistance to work around the
+vulnerability (specifically by providing a fast L1 data cache flush
+facility), and 2 indicates that the machine is not vulnerable.
+
+8.15 KVM_CAP_PPC_SAFE_BOUNDS_CHECK
+
+Architectures: ppc
+
+This capability gives information about the underlying machine's
+vulnerability or otherwise to the bounds-check variant of the Spectre
+attack.  Its value is a tristate, where 0 indicates the machine is
+vulnerable, 1 indicates the hardware is vulnerable but provides
+assistance to work around the vulnerability (specifically by providing
+an instruction that acts as a speculation barrier), and 2 indicates
+that the machine is not vulnerable.
+
+8.16 KVM_CAP_PPC_SAFE_INDIRECT_BRANCH
+
+Architectures: ppc
+
+This capability gives information about the underlying machine's
+vulnerability or otherwise to the indirect branch variant of the Spectre
+attack.  Its value is a tristate, where 0 indicates the machine is
+vulnerable and 2 indicates that the machine is not vulnerable.
+(1 would indicate the availability of a workaround that software
+needs to implement, but there is currently no workaround that needs
+software changes.)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 1915e86..bef76f8 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -39,6 +39,10 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_PPC_PSERIES
+#include 
+#include 
+#endif
 
 #include "timing.h"
 #include "irq.h"
@@ -488,6 +492,193 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
module_put(kvm->arch.kvm_ops->owner);
 }
 
+#ifdef CONFIG_PPC_BOOK3S_64
+/*
+ * These functions check whether the underlying hardware is safe
+ * against the Meltdown/Spectre attacks and whether it supplies
+ * instructions for use in workarounds.  The information comes from
+ * firmware, either via the device tree on powernv platforms or
+ * from an hcall on pseries platforms.
+ *
+ * For check_safe_cache() and check_safe_bounds_check(), a return
+ * value of 0 means vulnerable, 1 means vulnerable but workaround
+ * instructions are provided, and 2 means not vulnerable (no workaround
+ * is needed).
+ * For check_safe_indirect_branch(), 0 means vulnerable and 2 means
+ * not vulnerable.
+ */
+static inline bool have_fw_feat(struct device_node *fw_features,
+   const char *state, const char *name)
+{
+   struct device_node *np;
+   bool r = false;
+
+   np = of_get_child_by_name(fw_features, name);
+   if (np) {

[linux-next][qla2xxx][85caa95]kernel BUG at lib/list_debug.c:31!

[Abdul Haleem]

Greeting's, 

Linux next kernel panics on powerpc when module qla2xxx is load/unload.

Machine Type: Power 8 PowerVM LPAR
Kernel : 4.15.0-rc2-next-20171211
gcc : version 4.8.5
Test type: module load/unload few times

Trace messages:
---
qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 10.00.00.03-k.
qla2xxx [0106:a0:00.0]-001a: : MSI-X vector count: 32.
qla2xxx [0106:a0:00.0]-001d: : Found an ISP2532 irq 505 iobase 
0xaeb324e6.
qla2xxx [0106:a0:00.0]-00c6:1: MSI-X: Failed to enable support with 32 vectors, 
using 16 vectors.
qla2xxx [0106:a0:00.0]-00fb:1: QLogic QLE2562 - PCIe 2-port 8Gb FC Adapter.
qla2xxx [0106:a0:00.0]-00fc:1: ISP2532: PCIe (5.0GT/s x8) @ 0106:a0:00.0 hdma- 
host#=1 fw=8.06.00 (90d5).
qla2xxx [0106:a0:00.1]-001a: : MSI-X vector count: 32.
qla2xxx [0106:a0:00.1]-001d: : Found an ISP2532 irq 506 iobase 
0xa46f1774.
qla2xxx [0106:a0:00.1]-00c6:2: MSI-X: Failed to enable support with 32 vectors, 
using 16 vectors.
2xxx
qla2xxx [0106:a0:00.1]-00fb:2: QLogic QLE2562 - PCIe 2-port 8Gb FC Adapter.
qla2xxx [0106:a0:00.1]-00fc:2: ISP2532: PCIe (5.0GT/s x8) @ 0106:a0:00.1 hdma- 
host#=2 fw=8.06.00 (90d5).
0:00.0]-500a:1: LOOP UP detected (8 Gbps). 
qla2xxx [0106:a0:00.1]-500a:2: LOOP UP detected (8 Gbps).
list_add double add: new=8d33e594, prev=8d33e594, 
next=adef1df4.
[ cut here ]
kernel BUG at lib/list_debug.c:31! 
Oops: Exception in kernel mode, sig: 5 [#1]
LE SMP NR_CPUS=2048 NUMA pSeries 
Dumping ftrace buffer: 
   (ftrace buffer empty)
Modules linked in: qla2xxx(E) tg3(E) ibmveth(E) xt_CHECKSUM(E)
iptable_mangle(E) ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E)
iptable_nat(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack_ipv4(E)
nf_defrag_ipv4(E) xt_conntrack(E) nf_conntrack(E) ipt_REJECT(E)
nf_reject_ipv4(E) tun(E) bridge(E) stp(E) llc(E) kvm_pr(E) kvm(E)
sctp_diag(E) sctp(E) libcrc32c(E) tcp_diag(E) udp_diag(E)
ebtable_filter(E) ebtables(E) dccp_diag(E) ip6table_filter(E) dccp(E)
ip6_tables(E) iptable_filter(E) inet_diag(E) unix_diag(E)
af_packet_diag(E) netlink_diag(E) xts(E) sg(E) vmx_crypto(E)
pseries_rng(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E)
sunrpc(E) binfmt_misc(E) ip_tables(E) ext4(E) mbcache(E) jbd2(E)
fscrypto(E) sd_mod(E) ibmvscsi(E) scsi_transport_srp(E) nvme_fc(E)
nvme_fabrics(E) nvme_core(E) scsi_transport_fc(E)
 ptp(E) pps_core(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
[last unloaded: qla2xxx]
CPU: 7 PID: 22230 Comm: qla2xxx_1_dpc Tainted: GE
4.15.0-rc2-next-20171211-autotest-autotest #1
NIP:  c0511040 LR: c051103c CTR: 00655170
REGS: 9b7356fa TRAP: 0700   Tainted: GE 
(4.15.0-rc2-next-20171211-autotest-autotest)
MSR:  80010282b033   CR: 2222  
XER: 0009  
CFAR: c0170594 SOFTE: 0 
GPR00: c051103c c000fc293ac0 c10f1d00 0058 
GPR04: c0028fcccdd0 c0028fce3798 8000374060b8  
GPR08:  c0d435ec 00028ef9 2717 
GPR12:  ce734980 c01215d8 c002886996c0 
GPR16:  0020 c002813d83f8 0001 
GPR20: 2000 2000 0002 c002813dc808 
GPR24: 0003 0001 c0027f5a5c20 c002813dced0 
GPR28: c0027f5a5d90 c0027f5a5d90 c0027f5a5c00 c002813dc7f8 
NIP [c0511040] __list_add_valid+0x70/0xb0
LR [c051103c] __list_add_valid+0x6c/0xb0
Call Trace:
[c000fc293ac0] [c051103c] __list_add_valid+0x6c/0xb0 (unreliable)
[c000fc293b20] [d51f1a08] qla24xx_async_gnl+0x108/0x420 [qla2xxx]
[c000fc293bc0] [d51e762c] qla2x00_do_work+0x18c/0x8c0 [qla2xxx]
[c000fc293ce0] [d51e8180] qla2x00_relogin+0x420/0xff0 [qla2xxx]
[c000fc293dc0] [c012172c] kthread+0x15c/0x1a0
[c000fc293e30] [c000b4e8] ret_from_kernel_thread+0x5c/0x74
Instruction dump:
41de0018 38210060 3861 e8010010 7c0803a6 4e800020 3c62ffae 7d445378 
38631748 7d254b78 4bc5f51d 6000 <0fe0> 3c62ffae 7cc43378 386316f8 
---[ end trace a41bc8bd434657f1 ]---

Kernel panic - not syncing: Fatal exception
Dumping ftrace buffer: 
   (ftrace buffer empty)
Rebooting in 10 seconds..

This trace back to the below code path:

# gdb -batch vmlinux -ex 'list *(0xc0511040)'
0xc0511040 is in __list_add_valid (lib/list_debug.c:29).
24  "list_add corruption. next->prev should be prev 
(%p), but was %p. (next=%p).\n",
25  prev, next->prev, next) ||
26  CHECK_DATA_CORRUPTION(prev->next != next,
27  "list_add corruption. prev->next should be next 
(%p), but was %p. (prev=%p).\n",
28  next, prev->next, prev) ||
29  CHECK_DATA_CORRUPTION(new == prev || new == next,
30   

Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[Suraj Jitindar Singh]

On Tue, 2018-01-09 at 15:48 +1100, Paul Mackerras wrote:
> This adds three new capabilities that give userspace information
> about
> the underlying machine's level of vulnerability to the Meltdown and
> Spectre attacks, and what instructions the hardware implements to
> assist software to work around the vulnerabilities.
> 
> Each capability is a tri-state, where 0 indicates that the machine is
> vulnerable and no workarounds are implement, 1 indicates that the
> machine is vulnerable but workaround assist instructions are
> available, and 2 indicates that the machine is not vulnerable.
> 
> The capabilities are:
> 
> KVM_CAP_PPC_SAFE_CACHE reports the vulnerability of the machine to
> attacks based on using speculative loads to data in L1 cache which
> should not be addressable.  The workaround provided by hardware is an
> instruction to invalidate the entire L1 data cache.
> 
> KVM_CAP_PPC_SAFE_BOUNDS_CHECK reports the vulnerability of the
> machine
> to attacks based on using speculative loads behind mispredicted
> bounds
> checks.  The workaround provided by hardware is an instruction that
> acts as a speculation barrier.
> 
> KVM_CAP_PPC_SAFE_INDIRECT_BRANCH reports the vulnerability of the
> machine to attacks based on poisoning the indirect branch predictor.
> No workaround that requires software changes is provided; the current
> hardware fix is to prevent speculation past indirect branches.
> 
> Signed-off-by: Paul Mackerras 
> ---
> Note: This patch depends on the patch "powerpc/pseries: Add
> H_GET_CPU_CHARACTERISTICS flags & wrapper" by Michael Ellerman,
> available at http://patchwork.ozlabs.org/patch/856914/ .
> 
>  Documentation/virtual/kvm/api.txt |  36 +++
>  arch/powerpc/kvm/powerpc.c| 202
> ++
>  include/uapi/linux/kvm.h  |   3 +
>  3 files changed, 241 insertions(+)
> 
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index 57d3ee9..8d76260 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -4369,3 +4369,39 @@ Parameters: none
>  This capability indicates if the flic device will be able to get/set
> the
>  AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and
> allows
>  to discover this without having to create a flic device.
> +
> +8.14 KVM_CAP_PPC_SAFE_CACHE
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the Meltdown attack.  Its value is a
> +tristate, where 0 indicates the machine is vulnerable, 1 indicates
> the
> +hardware is vulnerable but provides assistance to work around the
> +vulnerability (specifically by providing a fast L1 data cache flush
> +facility), and 2 indicates that the machine is not vulnerable.
> +
> +8.15 KVM_CAP_PPC_SAFE_BOUNDS_CHECK
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the bounds-check variant of the
> Spectre
> +attack.  Its value is a tristate, where 0 indicates the machine is
> +vulnerable, 1 indicates the hardware is vulnerable but provides
> +assistance to work around the vulnerability (specifically by
> providing
> +an instruction that acts as a speculation barrier), and 2 indicates
> +that the machine is not vulnerable.
> +
> +8.16 KVM_CAP_PPC_SAFE_INDIRECT_BRANCH
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the indirect branch variant of the
> Spectre
> +attack.  Its value is a tristate, where 0 indicates the machine is
> +vulnerable and 2 indicates that the machine is not vulnerable.
> +(1 would indicate the availability of a workaround that software
> +needs to implement, but there is currently no workaround that needs
> +software changes.)
> +
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 1915e86..58e863b 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -39,6 +39,10 @@
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_PPC_PSERIES
> +#include 
> +#include 
> +#endif
>  
>  #include "timing.h"
>  #include "irq.h"
> @@ -488,6 +492,193 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
>   module_put(kvm->arch.kvm_ops->owner);
>  }
>  
> +#ifdef CONFIG_PPC_BOOK3S_64
> +/*
> + * These functions check whether the underlying hardware is safe
> + * against the Meltdown/Spectre attacks and whether it supplies
> + * instructions for use in workarounds.  The information comes from
> + * firmware, either via the device tree on powernv platforms or
> + * from an hcall on pseries platforms.
> + *
> + * For check_safe_cache() and check_safe_bounds_check(), a return
> + * value of 0 means vulnerable, 1 means vulnerable but workaround
> + * instructions are provided, and 2 means not vulnerable (no
> workaround
> + * is needed).
> + * For check_safe_indirect_branch(), 0 means vulnerab

Re: [PATCH] KVM: PPC: Book3S: Add capabilities for Meltdown/Spectre workarounds

[Suraj Jitindar Singh]

On Tue, 2018-01-09 at 15:48 +1100, Paul Mackerras wrote:
> This adds three new capabilities that give userspace information
> about
> the underlying machine's level of vulnerability to the Meltdown and
> Spectre attacks, and what instructions the hardware implements to
> assist software to work around the vulnerabilities.
> 
> Each capability is a tri-state, where 0 indicates that the machine is
> vulnerable and no workarounds are implement, 1 indicates that the
> machine is vulnerable but workaround assist instructions are
> available, and 2 indicates that the machine is not vulnerable.
> 
> The capabilities are:
> 
> KVM_CAP_PPC_SAFE_CACHE reports the vulnerability of the machine to
> attacks based on using speculative loads to data in L1 cache which
> should not be addressable.  The workaround provided by hardware is an
> instruction to invalidate the entire L1 data cache.
> 
> KVM_CAP_PPC_SAFE_BOUNDS_CHECK reports the vulnerability of the
> machine
> to attacks based on using speculative loads behind mispredicted
> bounds
> checks.  The workaround provided by hardware is an instruction that
> acts as a speculation barrier.
> 
> KVM_CAP_PPC_SAFE_INDIRECT_BRANCH reports the vulnerability of the
> machine to attacks based on poisoning the indirect branch predictor.
> No workaround that requires software changes is provided; the current
> hardware fix is to prevent speculation past indirect branches.
> 
> Signed-off-by: Paul Mackerras 
> ---
> Note: This patch depends on the patch "powerpc/pseries: Add
> H_GET_CPU_CHARACTERISTICS flags & wrapper" by Michael Ellerman,
> available at http://patchwork.ozlabs.org/patch/856914/ .
> 
>  Documentation/virtual/kvm/api.txt |  36 +++
>  arch/powerpc/kvm/powerpc.c| 202
> ++
>  include/uapi/linux/kvm.h  |   3 +
>  3 files changed, 241 insertions(+)
> 
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index 57d3ee9..8d76260 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -4369,3 +4369,39 @@ Parameters: none
>  This capability indicates if the flic device will be able to get/set
> the
>  AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and
> allows
>  to discover this without having to create a flic device.
> +
> +8.14 KVM_CAP_PPC_SAFE_CACHE
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the Meltdown attack.  Its value is a
> +tristate, where 0 indicates the machine is vulnerable, 1 indicates
> the
> +hardware is vulnerable but provides assistance to work around the
> +vulnerability (specifically by providing a fast L1 data cache flush
> +facility), and 2 indicates that the machine is not vulnerable.
> +
> +8.15 KVM_CAP_PPC_SAFE_BOUNDS_CHECK
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the bounds-check variant of the
> Spectre
> +attack.  Its value is a tristate, where 0 indicates the machine is
> +vulnerable, 1 indicates the hardware is vulnerable but provides
> +assistance to work around the vulnerability (specifically by
> providing
> +an instruction that acts as a speculation barrier), and 2 indicates
> +that the machine is not vulnerable.
> +
> +8.16 KVM_CAP_PPC_SAFE_INDIRECT_BRANCH
> +
> +Architectures: ppc
> +
> +This capability gives information about the underlying machine's
> +vulnerability or otherwise to the indirect branch variant of the
> Spectre
> +attack.  Its value is a tristate, where 0 indicates the machine is
> +vulnerable and 2 indicates that the machine is not vulnerable.
> +(1 would indicate the availability of a workaround that software
> +needs to implement, but there is currently no workaround that needs
> +software changes.)
> +
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 1915e86..58e863b 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -39,6 +39,10 @@
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_PPC_PSERIES
> +#include 
> +#include 
> +#endif
>  
>  #include "timing.h"
>  #include "irq.h"
> @@ -488,6 +492,193 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
>   module_put(kvm->arch.kvm_ops->owner);
>  }
>  
> +#ifdef CONFIG_PPC_BOOK3S_64
> +/*
> + * These functions check whether the underlying hardware is safe
> + * against the Meltdown/Spectre attacks and whether it supplies
> + * instructions for use in workarounds.  The information comes from
> + * firmware, either via the device tree on powernv platforms or
> + * from an hcall on pseries platforms.
> + *
> + * For check_safe_cache() and check_safe_bounds_check(), a return
> + * value of 0 means vulnerable, 1 means vulnerable but workaround
> + * instructions are provided, and 2 means not vulnerable (no
> workaround
> + * is needed).
> + * For check_safe_indirect_branch(), 0 means vulnerab

Re: [PATCH 09/11] powerpc/64s: Allow control of RFI flush via sysfs

[Greg KH]

On Tue, Jan 09, 2018 at 03:54:51AM +1100, Michael Ellerman wrote:
> From: Nicholas Piggin 
> 
> Expose the state of the RFI flush (enabled/disabled) via sysfs, and
> allow it to be enabled/dissabled at runtime.
> 
> Signed-off-by: Nicholas Piggin 
> Signed-off-by: Michael Ellerman 
> ---
>  arch/powerpc/kernel/setup.h |  2 ++
>  arch/powerpc/kernel/sysfs.c | 41 +
>  2 files changed, 43 insertions(+)

You forgot a Documentation/ABI/ update for a new sysfs file :(

> diff --git a/arch/powerpc/kernel/setup.h b/arch/powerpc/kernel/setup.h
> index 21c18071d9d5..493b03b0a966 100644
> --- a/arch/powerpc/kernel/setup.h
> +++ b/arch/powerpc/kernel/setup.h
> @@ -61,4 +61,6 @@ void kvm_cma_reserve(void);
>  static inline void kvm_cma_reserve(void) { };
>  #endif
>  
> +extern bool rfi_flush;
> +
>  #endif /* __ARCH_POWERPC_KERNEL_SETUP_H */
> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index b8d4a1dac39f..8c19d014cffc 100644
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -20,6 +20,7 @@
>  #include 
>  
>  #include "cacheinfo.h"
> +#include "setup.h"
>  
>  #ifdef CONFIG_PPC64
>  #include 
> @@ -496,6 +497,43 @@ static DEVICE_ATTR(spurr, 0400, show_spurr, NULL);
>  static DEVICE_ATTR(purr, 0400, show_purr, store_purr);
>  static DEVICE_ATTR(pir, 0400, show_pir, NULL);
>  
> +#ifdef CONFIG_PPC_BOOK3S_64
> +static ssize_t show_rfi_flush(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d\n", rfi_flush ? 1 : 0);
> +}
> +
> +static ssize_t __used store_rfi_flush(struct device *dev,
> + struct device_attribute *attr, const char *buf,
> + size_t count)
> +{
> + int val;
> + int ret = 0;
> +
> + ret = sscanf(buf, "%d", &val);
> + if (ret != 1)
> + return -EINVAL;
> +
> + if (val == 1)
> + rfi_flush_enable(true);
> + else if (val == 0)
> + rfi_flush_enable(false);
> + else
> + return -EINVAL;
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR(rfi_flush, 0600,
> + show_rfi_flush, store_rfi_flush);

DEVICE_ATTR_RW()?  And why 0600?  That's odd.

> +
> +static void sysfs_create_rfi_flush(void)
> +{
> + device_create_file(cpu_subsys.dev_root, &dev_attr_rfi_flush);

No error checking?

And as Thomas said, why not just use the generic infrastructure he
created instead?  That way there is some form of unity here for the same
exact issue.

At least he documented the api :)

thanks,

greg k-h

Re: [PATCH 09/11] powerpc/64s: Allow control of RFI flush via sysfs

[Jon Masters]

On 01/09/2018 03:05 AM, Greg KH wrote:
> On Tue, Jan 09, 2018 at 01:06:23AM -0500, Jon Masters wrote:
>> Knowing that the IBM team was going to post with this sysfs interface,
>> our trees contain the rfi_flush file. I mentioned it to some folks on
>> this end (because we know we don't want to add things in sysfs
>> generally, debugfs is a good substitute, per Andrea, and I raised this
>> with him yesterday as a concern in the backport here) but in the end it
>> seemed reasonable to pull this in because it was what got posted, and as
>> Michael says, it's gone into other distro kernels beyond just ours.
> 
> What distro kernels end up enabling does not really reflect on what we
> end up doing in mainline.  The api for this should NOT be arch-specific
> if at all possible, that way lies madness.  Do you want to write
> userspace tools to handle the 60+ different arch implementations?
> 
> Don't let the fragmentation problems of the period in which no one was
> allowed to talk to each other, result in a unchangable mess, that would
> be insane.

Totally fine :) Just saying we tried to do reasonable things with what
we had. Whatever happens upstream in the end is, of course, what we'll
make sure fits into updates that go into the likes of RHEL.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

Re: [PATCH 09/11] powerpc/64s: Allow control of RFI flush via sysfs

[Greg KH]

On Tue, Jan 09, 2018 at 01:06:23AM -0500, Jon Masters wrote:
> Knowing that the IBM team was going to post with this sysfs interface,
> our trees contain the rfi_flush file. I mentioned it to some folks on
> this end (because we know we don't want to add things in sysfs
> generally, debugfs is a good substitute, per Andrea, and I raised this
> with him yesterday as a concern in the backport here) but in the end it
> seemed reasonable to pull this in because it was what got posted, and as
> Michael says, it's gone into other distro kernels beyond just ours.

What distro kernels end up enabling does not really reflect on what we
end up doing in mainline.  The api for this should NOT be arch-specific
if at all possible, that way lies madness.  Do you want to write
userspace tools to handle the 60+ different arch implementations?

Don't let the fragmentation problems of the period in which no one was
allowed to talk to each other, result in a unchangable mess, that would
be insane.

thanks,

greg k-h