Re: [PATCH v5 06/16] KVM: PPC: Book3S HV: XIVE: add controls for the EQ configuration

2019-04-11 Thread David Gibson
On Wed, Apr 10, 2019 at 07:04:38PM +0200, Cédric Le Goater wrote:
> These controls will be used by the H_INT_SET_QUEUE_CONFIG and
> H_INT_GET_QUEUE_CONFIG hcalls from QEMU to configure the underlying
> Event Queue in the XIVE IC. They will also be used to restore the
> configuration of the XIVE EQs and to capture the internal run-time
> state of the EQs. Both 'get' and 'set' rely on an OPAL call to access
> the EQ toggle bit and EQ index which are updated by the XIVE IC when
> event notifications are enqueued in the EQ.
> 
> The value of the guest physical address of the event queue is saved in
> the XIVE internal xive_q structure for later use. That is when
> migration needs to mark the EQ pages dirty to capture a consistent
> memory state of the VM.
> 
> To be noted that H_INT_SET_QUEUE_CONFIG does not require the extra
> OPAL call setting the EQ toggle bit and EQ index to configure the EQ,
> but restoring the EQ state will.
> 
> Signed-off-by: Cédric Le Goater 

Reviewed-by: David Gibson 

> ---
> 
>  Changes since v4 :
> 
>  - add check on EQ page alignment
>  - add requirement on KVM_XIVE_EQ_ALWAYS_NOTIFY
> 
>  arch/powerpc/include/asm/xive.h|   2 +
>  arch/powerpc/include/uapi/asm/kvm.h|  19 ++
>  arch/powerpc/kvm/book3s_xive.h |   2 +
>  arch/powerpc/kvm/book3s_xive.c |  15 +-
>  arch/powerpc/kvm/book3s_xive_native.c  | 249 +
>  Documentation/virtual/kvm/devices/xive.txt |  34 +++
>  6 files changed, 315 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
> index b579a943407b..c4e88abd3b67 100644
> --- a/arch/powerpc/include/asm/xive.h
> +++ b/arch/powerpc/include/asm/xive.h
> @@ -73,6 +73,8 @@ struct xive_q {
>   u32 esc_irq;
>   atomic_tcount;
>   atomic_tpending_count;
> + u64 guest_qaddr;
> + u32 guest_qshift;
>  };
>  
>  /* Global enable flags for the XIVE support */
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h 
> b/arch/powerpc/include/uapi/asm/kvm.h
> index e8161e21629b..85005400fd86 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -681,6 +681,7 @@ struct kvm_ppc_cpu_char {
>  #define KVM_DEV_XIVE_GRP_CTRL1
>  #define KVM_DEV_XIVE_GRP_SOURCE  2   /* 64-bit source 
> identifier */
>  #define KVM_DEV_XIVE_GRP_SOURCE_CONFIG   3   /* 64-bit source 
> identifier */
> +#define KVM_DEV_XIVE_GRP_EQ_CONFIG   4   /* 64-bit EQ identifier */
>  
>  /* Layout of 64-bit XIVE source attribute values */
>  #define KVM_XIVE_LEVEL_SENSITIVE (1ULL << 0)
> @@ -696,4 +697,22 @@ struct kvm_ppc_cpu_char {
>  #define KVM_XIVE_SOURCE_EISN_SHIFT   33
>  #define KVM_XIVE_SOURCE_EISN_MASK0xfffeULL
>  
> +/* Layout of 64-bit EQ identifier */
> +#define KVM_XIVE_EQ_PRIORITY_SHIFT   0
> +#define KVM_XIVE_EQ_PRIORITY_MASK0x7
> +#define KVM_XIVE_EQ_SERVER_SHIFT 3
> +#define KVM_XIVE_EQ_SERVER_MASK  0xfff8ULL
> +
> +/* Layout of EQ configuration values (64 bytes) */
> +struct kvm_ppc_xive_eq {
> + __u32 flags;
> + __u32 qshift;
> + __u64 qaddr;
> + __u32 qtoggle;
> + __u32 qindex;
> + __u8  pad[40];
> +};
> +
> +#define KVM_XIVE_EQ_ALWAYS_NOTIFY0x0001
> +
>  #endif /* __LINUX_KVM_POWERPC_H */
> diff --git a/arch/powerpc/kvm/book3s_xive.h b/arch/powerpc/kvm/book3s_xive.h
> index ae26fe653d98..622f594d93e1 100644
> --- a/arch/powerpc/kvm/book3s_xive.h
> +++ b/arch/powerpc/kvm/book3s_xive.h
> @@ -272,6 +272,8 @@ struct kvmppc_xive_src_block 
> *kvmppc_xive_create_src_block(
>   struct kvmppc_xive *xive, int irq);
>  void kvmppc_xive_free_sources(struct kvmppc_xive_src_block *sb);
>  int kvmppc_xive_select_target(struct kvm *kvm, u32 *server, u8 prio);
> +int kvmppc_xive_attach_escalation(struct kvm_vcpu *vcpu, u8 prio,
> +   bool single_escalation);
>  
>  #endif /* CONFIG_KVM_XICS */
>  #endif /* _KVM_PPC_BOOK3S_XICS_H */
> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> index e09f3addffe5..c1b7aa7dbc28 100644
> --- a/arch/powerpc/kvm/book3s_xive.c
> +++ b/arch/powerpc/kvm/book3s_xive.c
> @@ -166,7 +166,8 @@ static irqreturn_t xive_esc_irq(int irq, void *data)
>   return IRQ_HANDLED;
>  }
>  
> -static int xive_attach_escalation(struct kvm_vcpu *vcpu, u8 prio)
> +int kvmppc_xive_attach_escalation(struct kvm_vcpu *vcpu, u8 prio,
> +   bool single_escalation)
>  {
>   struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
>   struct xive_q *q = >queues[prio];
> @@ -185,7 +186,7 @@ static int xive_attach_escalation(struct kvm_vcpu *vcpu, 
> u8 prio)
>   return -EIO;
>   }
>  
> - if (xc->xive->single_escalation)
> + if (single_escalation)
>   name = kasprintf(GFP_KERNEL, "kvm-%d-%d",

Re: [PATCH kernel v3] powerpc/powernv: Isolate NVLinks between GV100GL on Witherspoon

2019-04-11 Thread Alexey Kardashevskiy



On 12/04/2019 02:52, Alex Williamson wrote:
> On Thu, 11 Apr 2019 16:48:44 +1000
> Alexey Kardashevskiy  wrote:
> 
>> The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
>> (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
>> peer-to-peer NVLinks in groups of 2 to 4 GPUs with no buffers/latches
>> between GPUs.
>>
>> Because of these interconnected NVLinks, the POWERNV platform puts such
>> interconnected GPUs to the same IOMMU group. However users want to pass
>> GPUs through individually which requires separate IOMMU groups.
>>
>> Thankfully V100 GPUs implement an interface to disable arbitrary links
>> by programming link disabling mask via the GPU's BAR0. Once a link is
>> disabled, it only can be enabled after performing the secondary bus reset
>> (SBR) on the GPU. Since these GPUs do not advertise any other type of
>> reset, it is reset by the platform's SBR handler.
>>
>> This adds an extra step to the POWERNV's SBR handler to block NVLinks to
>> GPUs which do not belong to the same group as the GPU being reset.
>>
>> This adds a new "isolate_nvlink" kernel parameter to force GPU isolation;
>> when enabled, every GPU gets placed in its own IOMMU group. The new
>> parameter is off by default to preserve the existing behaviour.
>>
>> Before isolating:
>> [nvdbg ~]$ nvidia-smi topo -m
>> GPU0GPU1GPU2CPU Affinity
>> GPU0 X  NV2 NV2 0-0
>> GPU1NV2  X  NV2 0-0
>> GPU2NV2 NV2  X  0-0
>>
>> After isolating:
>> [nvdbg ~]$ nvidia-smi topo -m
>> GPU0GPU1GPU2CPU Affinity
>> GPU0 X  PHB PHB 0-0
>> GPU1PHB  X  PHB 0-0
>> GPU2PHB PHB  X  0-0
>>
>> Where:
>>   X= Self
>>   PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically 
>> the CPU)
>>   NV#  = Connection traversing a bonded set of # NVLinks
>>
>> Signed-off-by: Alexey Kardashevskiy 
>> ---
>> Changes:
>> v3:
>> * added pci_err() for failed ioremap
>> * reworked commit log
>>
>> v2:
>> * this is rework of [PATCH kernel RFC 0/2] vfio, powerpc/powernv: Isolate 
>> GV100GL
>> but this time it is contained in the powernv platform
>> ---
>>  arch/powerpc/platforms/powernv/Makefile  |   2 +-
>>  arch/powerpc/platforms/powernv/pci.h |   1 +
>>  arch/powerpc/platforms/powernv/eeh-powernv.c |   1 +
>>  arch/powerpc/platforms/powernv/npu-dma.c |  24 +++-
>>  arch/powerpc/platforms/powernv/nvlinkgpu.c   | 137 +++
>>  5 files changed, 162 insertions(+), 3 deletions(-)
>>  create mode 100644 arch/powerpc/platforms/powernv/nvlinkgpu.c
>>
>> diff --git a/arch/powerpc/platforms/powernv/Makefile 
>> b/arch/powerpc/platforms/powernv/Makefile
>> index da2e99efbd04..60a10d3b36eb 100644
>> --- a/arch/powerpc/platforms/powernv/Makefile
>> +++ b/arch/powerpc/platforms/powernv/Makefile
>> @@ -6,7 +6,7 @@ obj-y+= opal-msglog.o opal-hmi.o 
>> opal-power.o opal-irqchip.o
>>  obj-y   += opal-kmsg.o opal-powercap.o opal-psr.o 
>> opal-sensor-groups.o
>>  
>>  obj-$(CONFIG_SMP)   += smp.o subcore.o subcore-asm.o
>> -obj-$(CONFIG_PCI)   += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o
>> +obj-$(CONFIG_PCI)   += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o nvlinkgpu.o
>>  obj-$(CONFIG_CXL_BASE)  += pci-cxl.o
>>  obj-$(CONFIG_EEH)   += eeh-powernv.o
>>  obj-$(CONFIG_PPC_SCOM)  += opal-xscom.o
>> diff --git a/arch/powerpc/platforms/powernv/pci.h 
>> b/arch/powerpc/platforms/powernv/pci.h
>> index 8e36da379252..9fd3f391482c 100644
>> --- a/arch/powerpc/platforms/powernv/pci.h
>> +++ b/arch/powerpc/platforms/powernv/pci.h
>> @@ -250,5 +250,6 @@ extern void pnv_pci_unlink_table_and_group(struct 
>> iommu_table *tbl,
>>  extern void pnv_pci_setup_iommu_table(struct iommu_table *tbl,
>>  void *tce_mem, u64 tce_size,
>>  u64 dma_offset, unsigned int page_shift);
>> +extern void pnv_try_isolate_nvidia_v100(struct pci_dev *gpdev);
>>  
>>  #endif /* __POWERNV_PCI_H */
>> diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c 
>> b/arch/powerpc/platforms/powernv/eeh-powernv.c
>> index f38078976c5d..464b097d9635 100644
>> --- a/arch/powerpc/platforms/powernv/eeh-powernv.c
>> +++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
>> @@ -937,6 +937,7 @@ void pnv_pci_reset_secondary_bus(struct pci_dev *dev)
>>  pnv_eeh_bridge_reset(dev, EEH_RESET_HOT);
>>  pnv_eeh_bridge_reset(dev, EEH_RESET_DEACTIVATE);
>>  }
>> +pnv_try_isolate_nvidia_v100(dev);
>>  }
>>  
>>  static void pnv_eeh_wait_for_pending(struct pci_dn *pdn, const char *type,
>> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
>> b/arch/powerpc/platforms/powernv/npu-dma.c
>> index dc23d9d2a7d9..d4f9ee6222b5 100644
>> --- a/arch/powerpc/platforms/powernv/npu-dma.c
>> +++ b/arch/powerpc/platforms/powernv/npu-dma.c
>> @@ -22,6 +22,23 @@
>>  
>>  #include "pci.h"
>>  
>> +static bool isolate_nvlink;
>> +
>> +static 

Re: powerpc/64s/radix: Fix radix segment exception handling

2019-04-11 Thread Nicholas Piggin
Michael Ellerman's on April 11, 2019 12:49 am:
> On Fri, 2019-03-29 at 07:42:57 UTC, Nicholas Piggin wrote:
>> Commit 48e7b76957 ("powerpc/64s/hash: Convert SLB miss handlers to C")
>> broke the radix-mode segment exception handler. In radix mode, this is
>> exception is not an SLB miss, rather it signals that the EA is outside
>> the range translated by any page table.
>> 
>> The commit lost the radix feature alternate code patch, which can
>> cause faults to some EAs to kernel BUG at arch/powerpc/mm/slb.c:639!
>> 
>> The original radix code would send faults to slb_miss_large_addr,
>> which would end up faulting due to slb_addr_limit being 0. This patch
>> sends radix directly to do_bad_slb_fault, which is a bit clearer.
>> 
>> Fixes: 48e7b76957 ("powerpc/64s/hash: Convert SLB miss handlers to C")
>> Cc: Aneesh Kumar K.V 
>> Reported-by: Anton Blanchard 
>> Signed-off-by: Nicholas Piggin 
>> Reviewed-by: Aneesh Kumar K.V 
> 
> Applied to powerpc fixes, thanks.
> 
> https://git.kernel.org/powerpc/c/7100e8704b61247649c50551b965e71d

I sent a v2 with a selftests that triggers the crash if you want it.
Code was unchanged to no big deal there.

Thanks,
Nick



[PATCH][v2] powerpc/lib: remove memcpy_flushcache redundant return

2019-04-11 Thread Li RongQing
Align it with other architectures and none of the callers has
been interested its return

Signed-off-by: Li RongQing 
---
v1->v2: change memcpy_flushcache declaration in 
arch/powerpc/include/asm/string.h

 arch/powerpc/include/asm/string.h | 2 +-
 arch/powerpc/lib/pmem.c   | 4 +---
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/string.h 
b/arch/powerpc/include/asm/string.h
index 1647de15a31e..15e2e16272ea 100644
--- a/arch/powerpc/include/asm/string.h
+++ b/arch/powerpc/include/asm/string.h
@@ -25,7 +25,7 @@ extern void * memcpy(void *,const void *,__kernel_size_t);
 extern void * memmove(void *,const void *,__kernel_size_t);
 extern int memcmp(const void *,const void *,__kernel_size_t);
 extern void * memchr(const void *,int,__kernel_size_t);
-extern void * memcpy_flushcache(void *,const void *,__kernel_size_t);
+extern void memcpy_flushcache(void *, const void *, __kernel_size_t);
 
 #ifdef CONFIG_PPC64
 #define __HAVE_ARCH_MEMSET32
diff --git a/arch/powerpc/lib/pmem.c b/arch/powerpc/lib/pmem.c
index 53c018762e1c..a7a1b3fc6720 100644
--- a/arch/powerpc/lib/pmem.c
+++ b/arch/powerpc/lib/pmem.c
@@ -48,14 +48,12 @@ long __copy_from_user_flushcache(void *dest, const void 
__user *src,
return copied;
 }
 
-void *memcpy_flushcache(void *dest, const void *src, size_t size)
+void memcpy_flushcache(void *dest, const void *src, size_t size)
 {
unsigned long start = (unsigned long) dest;
 
memcpy(dest, src, size);
flush_inval_dcache_range(start, start + size);
-
-   return dest;
 }
 EXPORT_SYMBOL(memcpy_flushcache);
 
-- 
2.16.2



Re: [PATCH RFC 1/5] cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options

2019-04-11 Thread Michael Ellerman
Josh Poimboeuf  writes:
> On Wed, Apr 10, 2019 at 02:10:01PM +0200, Thomas Gleixner wrote:
>> On Wed, 10 Apr 2019, Michael Ellerman wrote:
>> > Josh Poimboeuf  writes:
>> > 
>> > > On Fri, Apr 05, 2019 at 06:01:36PM +0200, Borislav Petkov wrote:
>> > >> Thinking about this more, we can shave off the first 4 chars and have it
>> > >> be:
>> > >> 
>> > >> spec_mitigations=
>> > >> 
>> > >> I think it is painfully clear which speculation mitigations we mean. And
>> > >> the other switches don't have "cpu_" prefixes too so...
>> > >
>> > > Sure, I'm ok with renaming it to that, if there are no objections.
>> > 
>> > What about when we have a mitigation for a non-speculation related bug :)
>> 
>> Those kind of silicon bugs are usually mitigated unconditionally.
>
> Right.
>
> But at least "mitigations=" is nice and short.  We could clarify in the
> documentation that it doesn't apply to *all* mitigations, only the ones
> which are optional and which can affect performance.
>
> And it would give us the freedom to include any future "optional"
> mitigations, spec or not.
>
> I kind of like it.  But I could go either way.

Some of the published SMT attacks are not speculation based.

And arguably we already have an optional mitigation for those, ie. nosmt.

cheers


Re: [PATCH RFC 1/5] cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options

2019-04-11 Thread Michael Ellerman
Thomas Gleixner  writes:
> On Wed, 10 Apr 2019, Michael Ellerman wrote:
>> Josh Poimboeuf  writes:
>> 
>> > On Fri, Apr 05, 2019 at 06:01:36PM +0200, Borislav Petkov wrote:
>> >> Thinking about this more, we can shave off the first 4 chars and have it
>> >> be:
>> >> 
>> >> spec_mitigations=
>> >> 
>> >> I think it is painfully clear which speculation mitigations we mean. And
>> >> the other switches don't have "cpu_" prefixes too so...
>> >
>> > Sure, I'm ok with renaming it to that, if there are no objections.
>> 
>> What about when we have a mitigation for a non-speculation related bug :)
>
> Those kind of silicon bugs are usually mitigated unconditionally.

I guess that's true, usually :)

cheers


Re: [PATCH stable v4.9 00/35] powerpc spectre backports for 4.9

2019-04-11 Thread Michael Ellerman
Sasha Levin  writes:
> On Thu, Apr 11, 2019 at 09:45:55PM +1000, Michael Ellerman wrote:
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA1
>>
>>Hi Greg,
>>
>>Please queue up these powerpc patches for 4.9 if you have no objections.
>>
>>There's one build fix for newer toolchains, and the rest are spectre related.
>
> I've queued it up, thank you.

Thanks. I'll fix my script to generate "Hi Sasha" for v4.9 mails :)

cheers


[PATCH v4 2/5] powerpc: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC

2019-04-11 Thread Sinan Kaya
CONFIG_DEBUG_KERNEL should not impact code generation. Use the newly
defined CONFIG_DEBUG_MISC instead to keep the current code.

Signed-off-by: Sinan Kaya 
---
 arch/powerpc/kernel/sysfs.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index e8e93c2c7d03..7a1708875d27 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -610,7 +610,7 @@ SYSFS_PMCSETUP(pa6t_pmc2, SPRN_PA6T_PMC2);
 SYSFS_PMCSETUP(pa6t_pmc3, SPRN_PA6T_PMC3);
 SYSFS_PMCSETUP(pa6t_pmc4, SPRN_PA6T_PMC4);
 SYSFS_PMCSETUP(pa6t_pmc5, SPRN_PA6T_PMC5);
-#ifdef CONFIG_DEBUG_KERNEL
+#ifdef CONFIG_DEBUG_MISC
 SYSFS_SPRSETUP(hid0, SPRN_HID0);
 SYSFS_SPRSETUP(hid1, SPRN_HID1);
 SYSFS_SPRSETUP(hid4, SPRN_HID4);
@@ -639,7 +639,7 @@ SYSFS_SPRSETUP(tsr0, SPRN_PA6T_TSR0);
 SYSFS_SPRSETUP(tsr1, SPRN_PA6T_TSR1);
 SYSFS_SPRSETUP(tsr2, SPRN_PA6T_TSR2);
 SYSFS_SPRSETUP(tsr3, SPRN_PA6T_TSR3);
-#endif /* CONFIG_DEBUG_KERNEL */
+#endif /* CONFIG_DEBUG_MISC */
 #endif /* HAS_PPC_PMC_PA6T */
 
 #ifdef HAS_PPC_PMC_IBM
@@ -680,7 +680,7 @@ static struct device_attribute pa6t_attrs[] = {
__ATTR(pmc3, 0600, show_pa6t_pmc3, store_pa6t_pmc3),
__ATTR(pmc4, 0600, show_pa6t_pmc4, store_pa6t_pmc4),
__ATTR(pmc5, 0600, show_pa6t_pmc5, store_pa6t_pmc5),
-#ifdef CONFIG_DEBUG_KERNEL
+#ifdef CONFIG_DEBUG_MISC
__ATTR(hid0, 0600, show_hid0, store_hid0),
__ATTR(hid1, 0600, show_hid1, store_hid1),
__ATTR(hid4, 0600, show_hid4, store_hid4),
@@ -709,7 +709,7 @@ static struct device_attribute pa6t_attrs[] = {
__ATTR(tsr1, 0600, show_tsr1, store_tsr1),
__ATTR(tsr2, 0600, show_tsr2, store_tsr2),
__ATTR(tsr3, 0600, show_tsr3, store_tsr3),
-#endif /* CONFIG_DEBUG_KERNEL */
+#endif /* CONFIG_DEBUG_MISC */
 };
 #endif /* HAS_PPC_PMC_PA6T */
 #endif /* HAS_PPC_PMC_CLASSIC */
-- 
2.21.0



Re: [PATCH v2] powerpc/xmon: add read-only mode

2019-04-11 Thread Christopher M Riedl


> On April 11, 2019 at 8:37 AM Michael Ellerman  wrote:
> 
> 
> Christopher M Riedl  writes:
> >> On April 8, 2019 at 1:34 AM Oliver  wrote:
> >> On Mon, Apr 8, 2019 at 1:06 PM Christopher M. Riedl  
> >> wrote:
> ...
> >> >
> >> > diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
> >> > index 4e00cb0a5464..0c7f21476018 100644
> >> > --- a/arch/powerpc/Kconfig.debug
> >> > +++ b/arch/powerpc/Kconfig.debug
> >> > @@ -117,6 +117,16 @@ config XMON_DISASSEMBLY
> >> >   to say Y here, unless you're building for a memory-constrained
> >> >   system.
> >> >
> >> 
> >> > +config XMON_RW
> >> > +   bool "Allow xmon read and write operations"
> >> > +   depends on XMON
> >> > +   default !STRICT_KERNEL_RWX
> >> > +   help
> >> > + Allow xmon to read and write to memory and special-purpose 
> >> > registers.
> >> > +  Conversely, prevent xmon write access when set to N. Read and 
> >> > write
> >> > +  access can also be explicitly controlled with 'xmon=rw' or 
> >> > 'xmon=ro'
> >> > +  (read-only) cmdline options. Default is !STRICT_KERNEL_RWX.
> >> 
> >> Maybe I am a dumb, but I found this *extremely* confusing.
> >> Conventionally Kconfig options will control what code is and is not
> >> included in the kernel (see XMON_DISASSEMBLY) rather than changing the
> >> default behaviour of code. It's not wrong to do so and I'm going to
> >> assume that you were following the pattern of XMON_DEFAULT, but I
> >> think you need to be a little more clear about what option actually
> >> does. Renaming it to XMON_DEFAULT_RO_MODE and re-wording the
> >> description to indicate it's a only a mode change would help a lot.
> >> 
> >> Sorry if this comes across as pointless bikeshedding since it's the
> >> opposite of what Christophe said in the last patch, but this was a bit
> >> of a head scratcher.
> >
> > If anyone is dumb here it's me for making this confusing :)
> > I chatted with Michael Ellerman about this, so let me try to explain this 
> > more clearly.
> 
> Yeah it's my fault :)
>

"Signed-off-by: Christopher M. Riedl" -- I take full responsibility hah.

> 
> > There are two things I am trying to address with XMON_RW:
> > 1) provide a default access mode for xmon based on system "security"
> 
> I think I've gone off this idea. Tying them together is just enforcing a
> linkage that people may not want.
> 
> I think XMON_RW should just be an option that stands on its own. It
> should probably be default n, to give people a safe default.
> 

Next version includes this along with making it clear that this option
provides the default mode for XMON.

>
> > 2) replace XMON in the decision to write-protect kernel text at compile-time
> 
> We should do that as a separate patch. That's actually a bug in the
> current STRICT_KERNEL_RWX support.
> 
> ie. STRICT_KERNEL_RWX should always give you PAGE_KERNEL_ROX, regardless
> of XMON or anything else.
> 
> > I think a single Kconfig for both of those things is sensible as ultimately 
> > the
> > point is to allow xmon to operate in read-only mode on "secure" systems -- 
> > without
> > violating any integrity/security guarantees (such as write-protected kernel 
> > text).
> >
> > Christophe suggested looking at STRICT_KERNEL_RWX and I think that option 
> > makes the
> > most sense to base XMON_RW on since the description for STRICT_KERNEL_RWX 
> > states:
> 
> Once we fix the bugs in STRICT_KERNEL_RWX people are going to enable
> that by default, so it will essentially be always on in future.
> 
> 
> > With that said, I will remove the 'xmon=rw' cmdline option as it really 
> > doesn't work
> > since kernel text is write-protected at compile time.
> 
> I think 'xmon=rw' still makes sense. Only some of the RW functionality
> relies on being able to patch kernel text.
> 
> And once you have proccall() you can just call a function to make it
> read/write anyway, or use memex to manually frob the page tables.
> 
> cheers

Great, adding this back in the next version.


Re: [PATCH 0/8]

2019-04-11 Thread Tyrel Datwyler
On 03/19/2019 07:58 PM, Sam Bobroff wrote:
> Hi all,
> 
> This patch set adds support for EEH recovery of hot plugged devices on pSeries
> machines. Specifically, devices discovered by PCI rescanning using
> /sys/bus/pci/rescan, which includes devices hotplugged by QEMU's device_add
> command. (pSeries doesn't currently use slot power control for hotplugging.)

Slight nit that its not that pSeries doesn't support slot power control
hotplugging, its that QEMU pSeries guests don't support it. We most definitely
use the slot power control for hotplugging in PowerVM pSeries Linux guests. More
specifically we had to work around short comings in the rpaphp driver when
dealing with QEMU. This being that while at initial glance the design implies
that it had multiple devices per PHB in mind, it didn't, and only actually
supported a single slot per PHB. Further, when we developed the QEMU pci hotplug
feature we had to deal with only having a single PHB per QEMU guest and as a
result needed a way to plug multiple pci devices into a single PHB. Hence, came
the pci rescan work around in drmgr.

Mike Roth and I have had discussions over the years to get the slot power
control hotplugging working properly with QEMU, and while I did get the RPA
hotplug driver fixed to register all available slots associated with a PHB, EEH
remained an issue. So, I'm very happy to see this patchset get that working with
the rescan work around.

> 
> As a side effect this also provides EEH support for devices removed by
> /sys/bus/pci/devices/*/remove and re-discovered by writing to 
> /sys/bus/pci/rescan,
> on all platforms.

+1, this seems like icing on the cake. ;)

> 
> The approach I've taken is to use the fact that the existing
> pcibios_bus_add_device() platform hooks (which are used to set up EEH on
> Virtual Function devices (VFs)) are actually called for all devices, so I've
> widened their scope and made other adjustments necessary to allow them to work
> for hotplugged and boot-time devices as well.
> 
> Because some of the changes are in generic PowerPC code, it's
> possible that I've disturbed something for another PowerPC platform. I've 
> tried
> to minimize this by leaving that code alone as much as possible and so there
> are a few cases where eeh_add_device_{early,late}() or eeh_add_sysfs_files() 
> is
> called more than once. I think these can be looked at later, as duplicate 
> calls
> are not harmful.
> 
> The patch "Convert PNV_PHB_FLAG_EEH" isn't strictly necessary and I'm not sure
> if it's better to keep it, because it simplifies the code or drop it, because
> we may need a separate flag per PHB later on. Thoughts anyone?
> 
> The first patch is a rework of the pcibios_init reordering patch I posted
> earlier, which I've included here because it's necessary for this set.
> 
> I have done some testing for PowerNV on Power9 using a modified pnv_php module
> and some testing on pSeries with slot power control using a modified rpaphp
> module, and the EEH-related parts seem to work.

I'm interested in what modifications with rpaphp. Its unclear if you are saying
rpaphp modified so that slot power hotplug works with a QEMU pSeries guest? If
thats the case it would be optimal to get that upstream and remove the work
rescan workaround for guests that don't need it.

-Tyrel

> 
> Cheers,
> Sam.
> 
> Sam Bobroff (8):
>   powerpc/64: Adjust order in pcibios_init()
>   powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag
>   powerpc/eeh: Convert PNV_PHB_FLAG_EEH to global flag
>   powerpc/eeh: Improve debug messages around device addition
>   powerpc/eeh: Add eeh_show_enabled()
>   powerpc/eeh: Initialize EEH address cache earlier
>   powerpc/eeh: EEH for pSeries hot plug
>   powerpc/eeh: Remove eeh_probe_devices() and eeh_addr_cache_build()
> 
>  arch/powerpc/include/asm/eeh.h   | 19 +++--
>  arch/powerpc/kernel/eeh.c| 33 -
>  arch/powerpc/kernel/eeh_cache.c  | 29 +---
>  arch/powerpc/kernel/eeh_driver.c |  4 ++
>  arch/powerpc/kernel/of_platform.c|  3 +-
>  arch/powerpc/kernel/pci-common.c |  4 --
>  arch/powerpc/kernel/pci_32.c |  4 ++
>  arch/powerpc/kernel/pci_64.c | 12 +++-
>  arch/powerpc/platforms/powernv/eeh-powernv.c | 41 +--
>  arch/powerpc/platforms/powernv/pci.c |  7 +-
>  arch/powerpc/platforms/powernv/pci.h |  2 -
>  arch/powerpc/platforms/pseries/eeh_pseries.c | 75 +++-
>  arch/powerpc/platforms/pseries/pci.c |  7 +-
>  13 files changed, 122 insertions(+), 118 deletions(-)
> 



Re: [PATCH-tip 00/22] locking/rwsem: Rework rwsem-xadd & enable new rwsem features

2019-04-11 Thread huang ying
On Thu, Apr 11, 2019 at 12:08 AM Waiman Long  wrote:
>
> On 04/10/2019 04:15 AM, huang ying wrote:
> > Hi, Waiman,
> >
> > What's the status of this patchset?  And its merging plan?
> >
> > Best Regards,
> > Huang, Ying
>
> I have broken the patch into 3 parts (0/1/2) and rewritten some of them.
> Part 0 has been merged into tip. Parts 1 and 2 are still under testing.

Thanks!  Please keep me updated!

Best Regards,
Huang, Ying

> Cheers,
> Longman
>


Re: [PATCH v2 00/21] Convert hwmon documentation to ReST

2019-04-11 Thread Mauro Carvalho Chehab
Em Thu, 11 Apr 2019 14:07:31 -0700
Guenter Roeck  escreveu:

> On Thu, Apr 11, 2019 at 05:43:57PM -0300, Mauro Carvalho Chehab wrote:
> > Em Thu, 11 Apr 2019 12:43:24 -0600
> > Jonathan Corbet  escreveu:
> >   
> > > On Wed, 10 Apr 2019 16:22:37 -0300
> > > Mauro Carvalho Chehab  wrote:
> > >   
> > > > This series converts the contents of Documentation/hwmon to ReST
> > > > format.
> > > > 
> > > > PS.: I opted to group the conversion files per groups of maintainer
> > > > set, as, if I were to generate one patch per file, it would give around
> > > > 160 patches.
> > > > 
> > > > I also added those patches to my development tree at:
> > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=hwmon
> > > > 
> > > > If you want to see the results, they're at:
> > > > https://www.infradead.org/~mchehab/hwmon/
> > > 
> > > This set seems generally good and could probably be applied as-is.  But I
> > > have to ask...is there a reason to not take the last step and actually
> > > bring this stuff into the Sphinx doc tree?
> > > 
> > > We seem to be mostly documenting sysfs files and such.  I am *guessing*
> > > that perhaps the set should move to Documentation/admin-guide/hwmon?  Or
> > > have I misunderstood the intended audience here?  
> > 
> > :-)
> > 
> > Yeah, I'd say that 80% of the contents there are user-faced.
> > 
> > Yet, the main issue with this (and other driver subsystems) is that there's
> > a mix of userspace and Kernelspace stuff. One somewhat simple case is
> > the abituguru: it has a "datasheet" file:
> > 
> > abituguru-datasheet
> > 
> > This contains programming information for the corresponding drivers,
> > while abituguru and abituguru3 contains mostly userspace
> > stuff (still, it also contains the I2C address, with shouldn't mean
> > anything for the user).
> > 
> > However, if you take a look at w83781d, you'll see a mix of both
> > userspace and driver developer info there... it has a chapter called
> > "Data sheet updates", for example, with is probably meaningless for
> > anyone but the hwmon driver developers.
> > 
> > That's, btw, a pattern that happens a lot inside device driver
> > documents on almost all subsystems I checked: driver-specific
> > documentation is usually not split into user-facing/kernel-facing.
> > 
> > While nobody does such split, IMHO, the best would be to keep the
> > information outside Documentation/admin-guide. But hey! You're
> > the Doc maintainer. If you prefer to move, I'm perfectly fine
> > with that.
> >   
> 
> Same here, but please don't move the files which are kernel facing only.
> 
> How do you want to handle this series ? Do you expect it to be pushed
> through hwmon, or through Documentation, or do you plan to push yourself ?
> 
> If the series isn't pushed through hwmon, we'll likely have a couple of
> conflicts against hwmon-next.

Guenter,

I won't be pushing it myself. IMO, it makes more sense to apply it at
hwmon-next, except if it would cause some conflicts against docs-next.

Regards,
Mauro


Re: [PATCH] crypto: vmx - fix copy-paste error in CTR mode

2019-04-11 Thread Nayna



On 04/11/2019 10:47 AM, Daniel Axtens wrote:

Eric Biggers  writes:


Are you still planning to fix the remaining bug?  I booted a ppc64le VM, and I
see the same test failure (I think) you were referring to:

alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test vector 3, 
cfg="uneven misaligned splits, may sleep"


Yes, that's the one I saw. I don't have time to follow it up at the
moment, but Nayna is aware of it.



Yes Eric, we identified this as a separate issue of misalignment and 
plan to post a separate patch to address it.


Thanks & Regards,
  - Nayna



Re: [PATCH v2 00/21] Convert hwmon documentation to ReST

2019-04-11 Thread Guenter Roeck
On Thu, Apr 11, 2019 at 05:43:57PM -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 11 Apr 2019 12:43:24 -0600
> Jonathan Corbet  escreveu:
> 
> > On Wed, 10 Apr 2019 16:22:37 -0300
> > Mauro Carvalho Chehab  wrote:
> > 
> > > This series converts the contents of Documentation/hwmon to ReST
> > > format.
> > > 
> > > PS.: I opted to group the conversion files per groups of maintainer
> > > set, as, if I were to generate one patch per file, it would give around
> > > 160 patches.
> > > 
> > > I also added those patches to my development tree at:
> > >   https://git.linuxtv.org/mchehab/experimental.git/log/?h=hwmon
> > > 
> > > If you want to see the results, they're at:
> > >   https://www.infradead.org/~mchehab/hwmon/  
> > 
> > This set seems generally good and could probably be applied as-is.  But I
> > have to ask...is there a reason to not take the last step and actually
> > bring this stuff into the Sphinx doc tree?
> > 
> > We seem to be mostly documenting sysfs files and such.  I am *guessing*
> > that perhaps the set should move to Documentation/admin-guide/hwmon?  Or
> > have I misunderstood the intended audience here?
> 
> :-)
> 
> Yeah, I'd say that 80% of the contents there are user-faced.
> 
> Yet, the main issue with this (and other driver subsystems) is that there's
> a mix of userspace and Kernelspace stuff. One somewhat simple case is
> the abituguru: it has a "datasheet" file:
> 
>   abituguru-datasheet
> 
> This contains programming information for the corresponding drivers,
> while abituguru and abituguru3 contains mostly userspace
> stuff (still, it also contains the I2C address, with shouldn't mean
> anything for the user).
> 
> However, if you take a look at w83781d, you'll see a mix of both
> userspace and driver developer info there... it has a chapter called
> "Data sheet updates", for example, with is probably meaningless for
> anyone but the hwmon driver developers.
> 
> That's, btw, a pattern that happens a lot inside device driver
> documents on almost all subsystems I checked: driver-specific
> documentation is usually not split into user-facing/kernel-facing.
> 
> While nobody does such split, IMHO, the best would be to keep the
> information outside Documentation/admin-guide. But hey! You're
> the Doc maintainer. If you prefer to move, I'm perfectly fine
> with that.
> 

Same here, but please don't move the files which are kernel facing only.

How do you want to handle this series ? Do you expect it to be pushed
through hwmon, or through Documentation, or do you plan to push yourself ?

If the series isn't pushed through hwmon, we'll likely have a couple of
conflicts against hwmon-next.

Thanks,
Guenter


Re: [PATCH v2 00/21] Convert hwmon documentation to ReST

2019-04-11 Thread Mauro Carvalho Chehab
Em Thu, 11 Apr 2019 12:43:24 -0600
Jonathan Corbet  escreveu:

> On Wed, 10 Apr 2019 16:22:37 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > This series converts the contents of Documentation/hwmon to ReST
> > format.
> > 
> > PS.: I opted to group the conversion files per groups of maintainer
> > set, as, if I were to generate one patch per file, it would give around
> > 160 patches.
> > 
> > I also added those patches to my development tree at:
> > https://git.linuxtv.org/mchehab/experimental.git/log/?h=hwmon
> > 
> > If you want to see the results, they're at:
> > https://www.infradead.org/~mchehab/hwmon/  
> 
> This set seems generally good and could probably be applied as-is.  But I
> have to ask...is there a reason to not take the last step and actually
> bring this stuff into the Sphinx doc tree?
> 
> We seem to be mostly documenting sysfs files and such.  I am *guessing*
> that perhaps the set should move to Documentation/admin-guide/hwmon?  Or
> have I misunderstood the intended audience here?

:-)

Yeah, I'd say that 80% of the contents there are user-faced.

Yet, the main issue with this (and other driver subsystems) is that there's
a mix of userspace and Kernelspace stuff. One somewhat simple case is
the abituguru: it has a "datasheet" file:

abituguru-datasheet

This contains programming information for the corresponding drivers,
while abituguru and abituguru3 contains mostly userspace
stuff (still, it also contains the I2C address, with shouldn't mean
anything for the user).

However, if you take a look at w83781d, you'll see a mix of both
userspace and driver developer info there... it has a chapter called
"Data sheet updates", for example, with is probably meaningless for
anyone but the hwmon driver developers.

That's, btw, a pattern that happens a lot inside device driver
documents on almost all subsystems I checked: driver-specific
documentation is usually not split into user-facing/kernel-facing.

While nobody does such split, IMHO, the best would be to keep the
information outside Documentation/admin-guide. But hey! You're
the Doc maintainer. If you prefer to move, I'm perfectly fine
with that.


Thanks,
Mauro


Re: [PATCH 1/6] mm: change locked_vm's type from unsigned long to atomic64_t

2019-04-11 Thread Daniel Jordan
On Thu, Apr 11, 2019 at 10:55:43AM +0100, Mark Rutland wrote:
> On Thu, Apr 11, 2019 at 02:22:23PM +1000, Alexey Kardashevskiy wrote:
> > On 03/04/2019 07:41, Daniel Jordan wrote:
> 
> > > - dev_dbg(dev, "[%d] RLIMIT_MEMLOCK %c%ld %ld/%ld%s\n", current->pid,
> > > + dev_dbg(dev, "[%d] RLIMIT_MEMLOCK %c%ld %lld/%lu%s\n", current->pid,
> > >   incr ? '+' : '-', npages << PAGE_SHIFT,
> > > - current->mm->locked_vm << PAGE_SHIFT, rlimit(RLIMIT_MEMLOCK),
> > > - ret ? "- exceeded" : "");
> > > + (s64)atomic64_read(>mm->locked_vm) << PAGE_SHIFT,
> > > + rlimit(RLIMIT_MEMLOCK), ret ? "- exceeded" : "");
> > 
> > 
> > 
> > atomic64_read() returns "long" which matches "%ld", why this change (and
> > similar below)? You did not do this in the two pr_debug()s above anyway.
> 
> Unfortunately, architectures return inconsistent types for atomic64 ops.
> 
> Some return long (e..g. powerpc), some return long long (e.g. arc), and
> some return s64 (e.g. x86).

Yes, Mark said it all, I'm just chiming in to confirm that's why I added the
cast.

Btw, thanks for doing this, Mark.


Re: [PATCH v4 4/4] ASoC: fsl_audmix: cache pdev->dev pointer

2019-04-11 Thread Nicolin Chen
On Wed, Apr 10, 2019 at 11:06:39AM +, Viorel Suman wrote:
> There should be no trouble to understand dev = pdev->dev.
> This can save some space to have more print info or save
> some wrapped lines.

Change looks fine. Ack.

> Signed-off-by: Viorel Suman 
> Suggested-by: Nicolin Chen 

I think usually Suggested-by comes above Signed-off-by.

This was originally in your change already, so you can replace:
-Suggested-by: Nicolin Chen 
-Acked-by: Nicolin Chen 

Just a chance for it to get resent without being a noise :)


Re: [PATCH V2 2/2] ASoC: fsl_asrc: Unify the supported input and output rate

2019-04-11 Thread Nicolin Chen
On Thu, Apr 11, 2019 at 09:39:09AM +, S.j. Wang wrote:
> Unify the supported input and output rate, add the

We previously didn't support 5KHz->5KHz, but now we do? That'd be
great if so.

>  static int fsl_asrc_dai_hw_params(struct snd_pcm_substream *substream,
> @@ -626,14 +629,18 @@ static int fsl_asrc_dai_probe(struct snd_soc_dai *dai)
>   .stream_name = "ASRC-Playback",
>   .channels_min = 1,
>   .channels_max = 10,
> - .rates = FSL_ASRC_RATES,
> + .rate_min = 5512,
> + .rate_max = 192000,
> + .rates = SNDRV_PCM_RATE_KNOT,
>   .formats = FSL_ASRC_FORMATS,
>   },
>   .capture = {
>   .stream_name = "ASRC-Capture",
>   .channels_min = 1,
>   .channels_max = 10,
> - .rates = FSL_ASRC_RATES,

Probably could remove FSL_ASRC_RATES define since it's not used.

Thanks


Re: [PATCH V2 1/2] ASoC: fsl_asrc: replace the process_option table with function

2019-04-11 Thread Nicolin Chen
On Thu, Apr 11, 2019 at 09:39:06AM +, S.j. Wang wrote:
  
> +/*
> + * Select the pre-processing and post-processing options

By aligning with other function comments:
/**
 * Select the pre-processing and post-processing options

> + *
> + * Fsin: input sample rate
> + * Fsout: output sample rate

I would suggest to use inrate and outrate to keep naming consistent.

> + * pre_proc: return value for pre-processing option
> + * post_proc: return value for post-processing option
> + */
> +static int fsl_asrc_sel_proc(int Fsin, int Fsout, int *pre_proc, int 
> *post_proc)
> +{
> + bool det_out_op2_cond;
> + bool det_out_op0_cond;

By looking at the comments below. Probably better to rename them
bool post_proc_cond2, post_proc_cond0;

> + /* Codition for selection of post-processing */

"Codition" -> "Conditions"

> + det_out_op2_cond = (((Fsin * 15 > Fsout * 16) & (Fsout < 56000)) |
> + ((Fsin > 56000) & (Fsout < 56000)));

Combining Daniel's comments + indentation alignment:
det_out_op2_cond = (Fsin * 15 > Fsout * 16 && Fsout < 56000) ||
   (Fsin > 56000 && Fsout < 56000);

> + det_out_op0_cond = (Fsin * 23 < Fsout * 8);
> +
> + /*
> +  * unsupported case: Tsout>16.125*Tsin, and Tsout>8.125*Tsin.

Funny thing is that there'd be no point in checking the 16.125, if
Tsout is bigger than 8.125 times of Tsin, i.e. only one condition:
Tsout > 8.125 * Tsin

> +  * Tsout>16.125*Tsin -> Fsin * 8 > 129 * Fsout
> +  * Tsout>8.125*Tsin  -> Fsin * 8 > 65 * Fsout
> +  * Tsout>4.125*Tsin  -> Fsin * 8 > 33 * Fsout
> +  * Tsout>1.875*Tsin  -> Fsin * 8 > 15 * Fsout

Took me a while to understand what it is saying

Better to write like this:
/* Does not support cases: Tsout > 8.125 * Tsin */
if (Fsin * 8 > 65 * Fsout) {
pair_err("Does not support %d > 8.125 * %d\n", Fsout, Fsin);
return -EINVAL;
}

/* Otherwise, select pre_proc between [0, 2] */
if (Fsin * 8 > 33 * Fsout)
> + *pre_proc = 2;
> + else if (Fsin * 8 > 15 * Fsout) {
> + if (Fsin > 152000)
> + *pre_proc = 2;
> + else
> + *pre_proc = 1;
> + } else if (Fsin < 76000)
> + *pre_proc = 0;
> + else if (Fsin > 152000)
> + *pre_proc = 2;
> + else
> + *pre_proc = 1;

<== Would look better by moving post_cond calculations here.

> + if (det_out_op2_cond)
> + *post_proc = 2;
> + else if (det_out_op0_cond)
> + *post_proc = 0;
> + else
> + *post_proc = 1;

And we could remove this check below:
> + /* unsupported options */
> + if (*pre_proc == 4 || *pre_proc == 5)
> + return -EINVAL;

So basically we are doing:
1) Error out unsupported cases
2) Select pre_proc
3) Calculate conditions for post_proc
4) Select post_proc

Thanks


Re: [PATCH v2 00/21] Convert hwmon documentation to ReST

2019-04-11 Thread Jonathan Corbet
On Wed, 10 Apr 2019 16:22:37 -0300
Mauro Carvalho Chehab  wrote:

> This series converts the contents of Documentation/hwmon to ReST
> format.
> 
> PS.: I opted to group the conversion files per groups of maintainer
> set, as, if I were to generate one patch per file, it would give around
> 160 patches.
> 
> I also added those patches to my development tree at:
>   https://git.linuxtv.org/mchehab/experimental.git/log/?h=hwmon
> 
> If you want to see the results, they're at:
>   https://www.infradead.org/~mchehab/hwmon/

This set seems generally good and could probably be applied as-is.  But I
have to ask...is there a reason to not take the last step and actually
bring this stuff into the Sphinx doc tree?

We seem to be mostly documenting sysfs files and such.  I am *guessing*
that perhaps the set should move to Documentation/admin-guide/hwmon?  Or
have I misunderstood the intended audience here?

Thanks,

jon


Re: [PATCH kernel v3] powerpc/powernv: Isolate NVLinks between GV100GL on Witherspoon

2019-04-11 Thread Alex Williamson
On Thu, 11 Apr 2019 16:48:44 +1000
Alexey Kardashevskiy  wrote:

> The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
> (on POWER9) NVLinks. In addition to that, GPUs themselves have direct
> peer-to-peer NVLinks in groups of 2 to 4 GPUs with no buffers/latches
> between GPUs.
> 
> Because of these interconnected NVLinks, the POWERNV platform puts such
> interconnected GPUs to the same IOMMU group. However users want to pass
> GPUs through individually which requires separate IOMMU groups.
> 
> Thankfully V100 GPUs implement an interface to disable arbitrary links
> by programming link disabling mask via the GPU's BAR0. Once a link is
> disabled, it only can be enabled after performing the secondary bus reset
> (SBR) on the GPU. Since these GPUs do not advertise any other type of
> reset, it is reset by the platform's SBR handler.
> 
> This adds an extra step to the POWERNV's SBR handler to block NVLinks to
> GPUs which do not belong to the same group as the GPU being reset.
> 
> This adds a new "isolate_nvlink" kernel parameter to force GPU isolation;
> when enabled, every GPU gets placed in its own IOMMU group. The new
> parameter is off by default to preserve the existing behaviour.
> 
> Before isolating:
> [nvdbg ~]$ nvidia-smi topo -m
> GPU0GPU1GPU2CPU Affinity
> GPU0 X  NV2 NV2 0-0
> GPU1NV2  X  NV2 0-0
> GPU2NV2 NV2  X  0-0
> 
> After isolating:
> [nvdbg ~]$ nvidia-smi topo -m
> GPU0GPU1GPU2CPU Affinity
> GPU0 X  PHB PHB 0-0
> GPU1PHB  X  PHB 0-0
> GPU2PHB PHB  X  0-0
> 
> Where:
>   X= Self
>   PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically 
> the CPU)
>   NV#  = Connection traversing a bonded set of # NVLinks
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
> Changes:
> v3:
> * added pci_err() for failed ioremap
> * reworked commit log
> 
> v2:
> * this is rework of [PATCH kernel RFC 0/2] vfio, powerpc/powernv: Isolate 
> GV100GL
> but this time it is contained in the powernv platform
> ---
>  arch/powerpc/platforms/powernv/Makefile  |   2 +-
>  arch/powerpc/platforms/powernv/pci.h |   1 +
>  arch/powerpc/platforms/powernv/eeh-powernv.c |   1 +
>  arch/powerpc/platforms/powernv/npu-dma.c |  24 +++-
>  arch/powerpc/platforms/powernv/nvlinkgpu.c   | 137 +++
>  5 files changed, 162 insertions(+), 3 deletions(-)
>  create mode 100644 arch/powerpc/platforms/powernv/nvlinkgpu.c
> 
> diff --git a/arch/powerpc/platforms/powernv/Makefile 
> b/arch/powerpc/platforms/powernv/Makefile
> index da2e99efbd04..60a10d3b36eb 100644
> --- a/arch/powerpc/platforms/powernv/Makefile
> +++ b/arch/powerpc/platforms/powernv/Makefile
> @@ -6,7 +6,7 @@ obj-y += opal-msglog.o opal-hmi.o 
> opal-power.o opal-irqchip.o
>  obj-y+= opal-kmsg.o opal-powercap.o opal-psr.o 
> opal-sensor-groups.o
>  
>  obj-$(CONFIG_SMP)+= smp.o subcore.o subcore-asm.o
> -obj-$(CONFIG_PCI)+= pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o
> +obj-$(CONFIG_PCI)+= pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o nvlinkgpu.o
>  obj-$(CONFIG_CXL_BASE)   += pci-cxl.o
>  obj-$(CONFIG_EEH)+= eeh-powernv.o
>  obj-$(CONFIG_PPC_SCOM)   += opal-xscom.o
> diff --git a/arch/powerpc/platforms/powernv/pci.h 
> b/arch/powerpc/platforms/powernv/pci.h
> index 8e36da379252..9fd3f391482c 100644
> --- a/arch/powerpc/platforms/powernv/pci.h
> +++ b/arch/powerpc/platforms/powernv/pci.h
> @@ -250,5 +250,6 @@ extern void pnv_pci_unlink_table_and_group(struct 
> iommu_table *tbl,
>  extern void pnv_pci_setup_iommu_table(struct iommu_table *tbl,
>   void *tce_mem, u64 tce_size,
>   u64 dma_offset, unsigned int page_shift);
> +extern void pnv_try_isolate_nvidia_v100(struct pci_dev *gpdev);
>  
>  #endif /* __POWERNV_PCI_H */
> diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c 
> b/arch/powerpc/platforms/powernv/eeh-powernv.c
> index f38078976c5d..464b097d9635 100644
> --- a/arch/powerpc/platforms/powernv/eeh-powernv.c
> +++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
> @@ -937,6 +937,7 @@ void pnv_pci_reset_secondary_bus(struct pci_dev *dev)
>   pnv_eeh_bridge_reset(dev, EEH_RESET_HOT);
>   pnv_eeh_bridge_reset(dev, EEH_RESET_DEACTIVATE);
>   }
> + pnv_try_isolate_nvidia_v100(dev);
>  }
>  
>  static void pnv_eeh_wait_for_pending(struct pci_dn *pdn, const char *type,
> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
> b/arch/powerpc/platforms/powernv/npu-dma.c
> index dc23d9d2a7d9..d4f9ee6222b5 100644
> --- a/arch/powerpc/platforms/powernv/npu-dma.c
> +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> @@ -22,6 +22,23 @@
>  
>  #include "pci.h"
>  
> +static bool isolate_nvlink;
> +
> +static int __init parse_isolate_nvlink(char *p)
> +{
> + bool val;
> +
> + if (!p)
> + val = true;
> + else if (kstrtobool(p, ))
> +

Re: [PATCH v2 3/7] drivers/clocksource: timer-fsl-ftm: use common header for FlexTimer #defines

2019-04-11 Thread Daniel Lezcano
On 06/03/2019 12:12, Patrick Havelange wrote:
> Common #defines have been moved to "linux/fsl/ftm.h". Thus making use of
> this file.
> Also FTM_SC_CLK_SHIFT has been renamed to FTM_SC_CLK_MASK_SHIFT.
> 
> Signed-off-by: Patrick Havelange 
> Reviewed-by: Esben Haabendal 

Acked-by: Daniel Lezcano 

> ---
> Changes v2
>  - None
> ---
>  drivers/clocksource/timer-fsl-ftm.c | 15 ++-
>  1 file changed, 2 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/clocksource/timer-fsl-ftm.c 
> b/drivers/clocksource/timer-fsl-ftm.c
> index 846d18daf893..e1c34b2f53a5 100644
> --- a/drivers/clocksource/timer-fsl-ftm.c
> +++ b/drivers/clocksource/timer-fsl-ftm.c
> @@ -19,20 +19,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
> -#define FTM_SC   0x00
> -#define FTM_SC_CLK_SHIFT 3
> -#define FTM_SC_CLK_MASK  (0x3 << FTM_SC_CLK_SHIFT)
> -#define FTM_SC_CLK(c)((c) << FTM_SC_CLK_SHIFT)
> -#define FTM_SC_PS_MASK   0x7
> -#define FTM_SC_TOIE  BIT(6)
> -#define FTM_SC_TOF   BIT(7)
> -
> -#define FTM_CNT  0x04
> -#define FTM_MOD  0x08
> -#define FTM_CNTIN0x4C
> -
> -#define FTM_PS_MAX   7
> +#define FTM_SC_CLK(c)((c) << FTM_SC_CLK_MASK_SHIFT)
>  
>  struct ftm_clock_device {
>   void __iomem *clksrc_base;
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog



Re: [PATCH stable v4.9 00/35] powerpc spectre backports for 4.9

2019-04-11 Thread Sasha Levin

On Thu, Apr 11, 2019 at 09:45:55PM +1000, Michael Ellerman wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Greg,

Please queue up these powerpc patches for 4.9 if you have no objections.

There's one build fix for newer toolchains, and the rest are spectre related.


I've queued it up, thank you.

--
Thanks,
Sasha


Re: [PATCH] crypto: vmx - fix copy-paste error in CTR mode

2019-04-11 Thread Daniel Axtens
Eric Biggers  writes:

> Hi Daniel,
>
> On Fri, Mar 15, 2019 at 04:23:02PM +1100, Daniel Axtens wrote:
>> Eric Biggers  writes:
>> 
>> > Hi Daniel,
>> >
>> > On Fri, Mar 15, 2019 at 03:24:35PM +1100, Daniel Axtens wrote:
>> >> Hi Eric,
>> >> 
>> >> >> The original assembly imported from OpenSSL has two copy-paste
>> >> >> errors in handling CTR mode. When dealing with a 2 or 3 block tail,
>> >> >> the code branches to the CBC decryption exit path, rather than to
>> >> >> the CTR exit path.
>> >> >
>> >> > So does this need to be fixed in OpenSSL too?
>> >> 
>> >> Yes, I'm getting in touch with some people internally (at IBM) about
>> >> doing that.
>> >> 
>> >> >> This leads to corruption of the IV, which leads to subsequent blocks
>> >> >> being corrupted.
>> >> >> 
>> >> >> This can be detected with libkcapi test suite, which is available at
>> >> >> https://github.com/smuellerDD/libkcapi
>> >> >> 
>> >> >
>> >> > Is this also detected by the kernel's crypto self-tests, and if not why 
>> >> > not?
>> >> > What about with the new option CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y?
>> >> 
>> >> It seems the self-tests do not catch it. To catch it, there has to be a
>> >> test where the blkcipher_walk creates a walk.nbytes such that
>> >> [(the number of AES blocks) mod 8] is either 2 or 3. This happens with
>> >> AF_ALG pretty frequently, but when I booted with self-tests it only hit
>> >> 1, 4, 5, 6 and 7 - it missed 0, 2 and 3.
>> >> 
>> >> I don't have the EXTRA_TESTS option - I'm testing with 5.0-rc6. Is it in
>> >> -next?
>> >> 
>> >> Regards,
>> >> Daniel
>> >
>> > The improvements I recently made to the self-tests are intended to catch 
>> > exactly
>> > this sort of bug.  They were just merged for v5.1, so try the latest 
>> > mainline.
>> > This almost certainly would be caught by EXTRA_TESTS (and if not I'd want 
>> > to
>> > know), but it may be caught by the regular self-tests now too.
>> 
>> Well, even the patched code fails with the new self-tests, so clearly
>> they're catching something! I'll investigate in more detail next week.
>> 
>> Regards,
>> Daniel
>> 
>> >
>> > - Eric

Hi Eric,

>
> Are you still planning to fix the remaining bug?  I booted a ppc64le VM, and I
> see the same test failure (I think) you were referring to:
>
> alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test 
> vector 3, cfg="uneven misaligned splits, may sleep"
>

Yes, that's the one I saw. I don't have time to follow it up at the
moment, but Nayna is aware of it.

Regards,
Daniel

> - Eric


Re: [PATCH RFC 1/5] cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options

2019-04-11 Thread Josh Poimboeuf
On Wed, Apr 10, 2019 at 02:10:01PM +0200, Thomas Gleixner wrote:
> On Wed, 10 Apr 2019, Michael Ellerman wrote:
> > Josh Poimboeuf  writes:
> > 
> > > On Fri, Apr 05, 2019 at 06:01:36PM +0200, Borislav Petkov wrote:
> > >> Thinking about this more, we can shave off the first 4 chars and have it
> > >> be:
> > >> 
> > >> spec_mitigations=
> > >> 
> > >> I think it is painfully clear which speculation mitigations we mean. And
> > >> the other switches don't have "cpu_" prefixes too so...
> > >
> > > Sure, I'm ok with renaming it to that, if there are no objections.
> > 
> > What about when we have a mitigation for a non-speculation related bug :)
> 
> Those kind of silicon bugs are usually mitigated unconditionally.

Right.

But at least "mitigations=" is nice and short.  We could clarify in the
documentation that it doesn't apply to *all* mitigations, only the ones
which are optional and which can affect performance.

And it would give us the freedom to include any future "optional"
mitigations, spec or not.

I kind of like it.  But I could go either way.

-- 
Josh


Re: [PATCH] MAINTAINERS: Update remaining @linux.vnet.ibm.com addresses

2019-04-11 Thread Paul E. McKenney
On Thu, Apr 11, 2019 at 05:27:31AM -0700, Joe Perches wrote:
> On Thu, 2019-04-11 at 22:07 +1000, Michael Ellerman wrote:
> > Joe Perches  writes:
> > > On Thu, 2019-04-11 at 06:27 +0200, Lukas Bulwahn wrote:
> > > > Paul McKenney attempted to update all email addresses 
> > > > @linux.vnet.ibm.com
> > > > to @linux.ibm.com in commit 1dfddcdb95c4
> > > > ("MAINTAINERS: Update from @linux.vnet.ibm.com to @linux.ibm.com"), but
> > > > some still remained.
> > > > 
> > > > We update the remaining email addresses in MAINTAINERS, hopefully 
> > > > finally
> > > > catching all cases for good.
> > > 
> > > Perhaps update all the similar addresses in other files too
> > > 
> > > $ git grep --name-only 'linux\.vnet\.ibm\.com' | wc -l
> > > 315
> > 
> > A good number of them are no longer valid. So I'm not sure it's worth
> > updating them en masse to addresses that won't ever work.
> > 
> > We have git now, we don't need email addresses in files, they're just
> > prone to bitrot like this.
> > 
> > Should we just change them all like so?
> > 
> >   -arch/powerpc/boot/dts/bamboo.dts: * Josh Boyer 
> > 
> >   +arch/powerpc/boot/dts/bamboo.dts: * Josh Boyer (IBM)
> > 
> > To indicate the author was at IBM when they wrote it?
> 
> If that's desired, perhaps:
> 
> $ git grep -P --name-only '?' | \
>   grep -vP '\.mailmap|MAINTAINERS' | \
>   xargs perl -p -i -e 's/?/(IBM)/g'
> 
> > Or should we try and update them with current addresses? Though then the
> > authors might start getting mails they don't want.
> 
> That'd be my preference.
> 
> If authors get emails they don't want, then those contact
> emails should be removed.

I have updated most of mine, with one more installment of patches to go
into the next merge window and another into the merge window after that.
More churn than I would have expected, though.  If my email address were
to change again, I would instead go with the "(IBM)" approach and let
the git log and MAINTAINERS file keep the contact information.  Not that
we get to update the git log, of course.  ;-)

I might not have bothered except for combining with the SPDX-tag
commits.

Thanx, Paul



Re: [PATCH v2 21/21] docs: hwmon: Add an index file and rename docs to *.rst

2019-04-11 Thread Liviu Dudau
On Wed, Apr 10, 2019 at 04:22:58PM -0300, Mauro Carvalho Chehab wrote:
> Now that all files were converted to ReST format, rename them
> and add an index.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  .../devicetree/bindings/hwmon/g762.txt|   2 +-
>  Documentation/hwmon/{ab8500 => ab8500.rst}|   2 +-
>  ...guru-datasheet => abituguru-datasheet.rst} |   0
>  .../hwmon/{abituguru => abituguru.rst}|   0
>  .../hwmon/{abituguru3 => abituguru3.rst}  |   0
>  Documentation/hwmon/{abx500 => abx500.rst}|   0
>  ...{acpi_power_meter => acpi_power_meter.rst} |   2 +-
>  Documentation/hwmon/{ad7314 => ad7314.rst}|   0
>  .../hwmon/{adc128d818 => adc128d818.rst}  |   0
>  Documentation/hwmon/{adm1021 => adm1021.rst}  |   0
>  Documentation/hwmon/{adm1025 => adm1025.rst}  |   0
>  Documentation/hwmon/{adm1026 => adm1026.rst}  |   0
>  Documentation/hwmon/{adm1031 => adm1031.rst}  |   0
>  Documentation/hwmon/{adm1275 => adm1275.rst}  |   4 +-
>  Documentation/hwmon/{adm9240 => adm9240.rst}  |   0
>  Documentation/hwmon/{ads1015 => ads1015.rst}  |   0
>  Documentation/hwmon/{ads7828 => ads7828.rst}  |   0
>  Documentation/hwmon/{adt7410 => adt7410.rst}  |   0
>  Documentation/hwmon/{adt7411 => adt7411.rst}  |   0
>  Documentation/hwmon/{adt7462 => adt7462.rst}  |   0
>  Documentation/hwmon/{adt7470 => adt7470.rst}  |   0
>  Documentation/hwmon/{adt7475 => adt7475.rst}  |   0
>  Documentation/hwmon/{amc6821 => amc6821.rst}  |   0
>  Documentation/hwmon/{asb100 => asb100.rst}|   0
>  Documentation/hwmon/{asc7621 => asc7621.rst}  |   0
>  ...{aspeed-pwm-tacho => aspeed-pwm-tacho.rst} |   0
>  .../hwmon/{coretemp => coretemp.rst}  |   0
>  Documentation/hwmon/{da9052 => da9052.rst}|   0
>  Documentation/hwmon/{da9055 => da9055.rst}|   0
>  Documentation/hwmon/{dme1737 => dme1737.rst}  |   0
>  Documentation/hwmon/{ds1621 => ds1621.rst}|   0
>  Documentation/hwmon/{ds620 => ds620.rst}  |   0
>  Documentation/hwmon/{emc1403 => emc1403.rst}  |   0
>  Documentation/hwmon/{emc2103 => emc2103.rst}  |   0
>  .../hwmon/{emc6w201 => emc6w201.rst}  |   0
>  Documentation/hwmon/{f71805f => f71805f.rst}  |   0
>  .../hwmon/{f71882fg => f71882fg.rst}  |   0
>  .../hwmon/{fam15h_power => fam15h_power.rst}  |   0
>  .../hwmon/{ftsteutates => ftsteutates.rst}|   0
>  Documentation/hwmon/{g760a => g760a.rst}  |   0
>  Documentation/hwmon/{g762 => g762.rst}|   2 +-
>  Documentation/hwmon/{gl518sm => gl518sm.rst}  |   0
>  Documentation/hwmon/{hih6130 => hih6130.rst}  |   0
>  ...on-kernel-api.txt => hwmon-kernel-api.rst} |   4 +-
>  .../hwmon/{ibm-cffps => ibm-cffps.rst}|   0
>  Documentation/hwmon/{ibmaem => ibmaem.rst}|   0
>  .../hwmon/{ibmpowernv => ibmpowernv.rst}  |   0
>  Documentation/hwmon/{ina209 => ina209.rst}|   0
>  Documentation/hwmon/{ina2xx => ina2xx.rst}|   2 +-
>  Documentation/hwmon/{ina3221 => ina3221.rst}  |   0
>  Documentation/hwmon/index.rst | 179 ++
>  Documentation/hwmon/{ir35221 => ir35221.rst}  |   0
>  Documentation/hwmon/{it87 => it87.rst}|   0
>  Documentation/hwmon/{jc42 => jc42.rst}|   0
>  Documentation/hwmon/{k10temp => k10temp.rst}  |   0
>  Documentation/hwmon/{k8temp => k8temp.rst}|   0
>  .../hwmon/{lineage-pem => lineage-pem.rst}|   0
>  Documentation/hwmon/{lm25066 => lm25066.rst}  |   2 +-
>  Documentation/hwmon/{lm63 => lm63.rst}|   0
>  Documentation/hwmon/{lm70 => lm70.rst}|   0
>  Documentation/hwmon/{lm73 => lm73.rst}|   0
>  Documentation/hwmon/{lm75 => lm75.rst}|   0
>  Documentation/hwmon/{lm77 => lm77.rst}|   0
>  Documentation/hwmon/{lm78 => lm78.rst}|   0
>  Documentation/hwmon/{lm80 => lm80.rst}|   0
>  Documentation/hwmon/{lm83 => lm83.rst}|   0
>  Documentation/hwmon/{lm85 => lm85.rst}|   0
>  Documentation/hwmon/{lm87 => lm87.rst}|   0
>  Documentation/hwmon/{lm90 => lm90.rst}|   0
>  Documentation/hwmon/{lm92 => lm92.rst}|   0
>  Documentation/hwmon/{lm93 => lm93.rst}|   0
>  Documentation/hwmon/{lm95234 => lm95234.rst}  |   0
>  Documentation/hwmon/{lm95245 => lm95245.rst}  |   0
>  Documentation/hwmon/{ltc2945 => ltc2945.rst}  |   0
>  Documentation/hwmon/{ltc2978 => ltc2978.rst}  |   0
>  Documentation/hwmon/{ltc2990 => ltc2990.rst}  |   0
>  Documentation/hwmon/{ltc3815 => ltc3815.rst}  |   0
>  Documentation/hwmon/{ltc4151 => ltc4151.rst}  |   0
>  Documentation/hwmon/{ltc4215 => ltc4215.rst}  |   0
>  Documentation/hwmon/{ltc4245 => ltc4245.rst}  |   0
>  Documentation/hwmon/{ltc4260 => ltc4260.rst}  |   0
>  Documentation/hwmon/{ltc4261 => ltc4261.rst}  |   0
>  .../hwmon/{max16064 => max16064.rst}  |   2 +-
>  .../hwmon/{max16065 => max16065.rst}  |   0
>  Documentation/hwmon/{max1619 => max1619.rst}  |   0
>  Documentation/hwmon/{max1668 => max1668.rst}  |   0
>  

Re: [PATCH] Linux: Define struct termios2 in under _GNU_SOURCE [BZ #10339]

2019-04-11 Thread Adhemerval Zanella



On 11/04/2019 08:07, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> This allows us to adjust the baud rates to non-standard values using termios
>> interfaces without to resorting to add new headers and use a different API
>> (ioctl).
> 
> How much symbol versioning will be required for this change?

I think all interfaces that have termios as input for sparc and mips 
(tcgetattr, tcsetattr, cfmakeraw, cfgetispeed, cfgetospeed, cfsetispeed,
cfsetospeed, cfsetspeed).

Alpha will also need to use termios1 for pre-4.20 kernels.

> 
>> As Peter Anvin has indicated, he create a POC [1] with the aforementioned
>> new interfaces.  It has not been rebased against master, more specially 
>> against
>> my termios refactor to simplify the multiple architecture header definitions,
>> but I intend to use as a base.
> 
> Reference [1] is still missing. 8-(

Oops... it is 
https://git.zytor.com/users/hpa/glibc/termbaud.git/log/?h=wip.termbaud

> 
> Thanks,
> Florian
> 


Re: [PATCH v2] powerpc/xmon: add read-only mode

2019-04-11 Thread Michael Ellerman
Christopher M Riedl  writes:
>> On April 8, 2019 at 1:34 AM Oliver  wrote:
>> On Mon, Apr 8, 2019 at 1:06 PM Christopher M. Riedl  
>> wrote:
...
>> >
>> > diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
>> > index 4e00cb0a5464..0c7f21476018 100644
>> > --- a/arch/powerpc/Kconfig.debug
>> > +++ b/arch/powerpc/Kconfig.debug
>> > @@ -117,6 +117,16 @@ config XMON_DISASSEMBLY
>> >   to say Y here, unless you're building for a memory-constrained
>> >   system.
>> >
>> 
>> > +config XMON_RW
>> > +   bool "Allow xmon read and write operations"
>> > +   depends on XMON
>> > +   default !STRICT_KERNEL_RWX
>> > +   help
>> > + Allow xmon to read and write to memory and special-purpose 
>> > registers.
>> > +  Conversely, prevent xmon write access when set to N. Read and 
>> > write
>> > +  access can also be explicitly controlled with 'xmon=rw' or 
>> > 'xmon=ro'
>> > +  (read-only) cmdline options. Default is !STRICT_KERNEL_RWX.
>> 
>> Maybe I am a dumb, but I found this *extremely* confusing.
>> Conventionally Kconfig options will control what code is and is not
>> included in the kernel (see XMON_DISASSEMBLY) rather than changing the
>> default behaviour of code. It's not wrong to do so and I'm going to
>> assume that you were following the pattern of XMON_DEFAULT, but I
>> think you need to be a little more clear about what option actually
>> does. Renaming it to XMON_DEFAULT_RO_MODE and re-wording the
>> description to indicate it's a only a mode change would help a lot.
>> 
>> Sorry if this comes across as pointless bikeshedding since it's the
>> opposite of what Christophe said in the last patch, but this was a bit
>> of a head scratcher.
>
> If anyone is dumb here it's me for making this confusing :)
> I chatted with Michael Ellerman about this, so let me try to explain this 
> more clearly.

Yeah it's my fault :)

> There are two things I am trying to address with XMON_RW:
> 1) provide a default access mode for xmon based on system "security"

I think I've gone off this idea. Tying them together is just enforcing a
linkage that people may not want.

I think XMON_RW should just be an option that stands on its own. It
should probably be default n, to give people a safe default.

> 2) replace XMON in the decision to write-protect kernel text at compile-time

We should do that as a separate patch. That's actually a bug in the
current STRICT_KERNEL_RWX support.

ie. STRICT_KERNEL_RWX should always give you PAGE_KERNEL_ROX, regardless
of XMON or anything else.

> I think a single Kconfig for both of those things is sensible as ultimately 
> the
> point is to allow xmon to operate in read-only mode on "secure" systems -- 
> without
> violating any integrity/security guarantees (such as write-protected kernel 
> text).
>
> Christophe suggested looking at STRICT_KERNEL_RWX and I think that option 
> makes the
> most sense to base XMON_RW on since the description for STRICT_KERNEL_RWX 
> states:

Once we fix the bugs in STRICT_KERNEL_RWX people are going to enable
that by default, so it will essentially be always on in future.


> With that said, I will remove the 'xmon=rw' cmdline option as it really 
> doesn't work
> since kernel text is write-protected at compile time.

I think 'xmon=rw' still makes sense. Only some of the RW functionality
relies on being able to patch kernel text.

And once you have proccall() you can just call a function to make it
read/write anyway, or use memex to manually frob the page tables.

cheers


Re: [PATCH] MAINTAINERS: Update remaining @linux.vnet.ibm.com addresses

2019-04-11 Thread Joe Perches
On Thu, 2019-04-11 at 22:07 +1000, Michael Ellerman wrote:
> Joe Perches  writes:
> > On Thu, 2019-04-11 at 06:27 +0200, Lukas Bulwahn wrote:
> > > Paul McKenney attempted to update all email addresses @linux.vnet.ibm.com
> > > to @linux.ibm.com in commit 1dfddcdb95c4
> > > ("MAINTAINERS: Update from @linux.vnet.ibm.com to @linux.ibm.com"), but
> > > some still remained.
> > > 
> > > We update the remaining email addresses in MAINTAINERS, hopefully finally
> > > catching all cases for good.
> > 
> > Perhaps update all the similar addresses in other files too
> > 
> > $ git grep --name-only 'linux\.vnet\.ibm\.com' | wc -l
> > 315
> 
> A good number of them are no longer valid. So I'm not sure it's worth
> updating them en masse to addresses that won't ever work.
> 
> We have git now, we don't need email addresses in files, they're just
> prone to bitrot like this.
> 
> Should we just change them all like so?
> 
>   -arch/powerpc/boot/dts/bamboo.dts: * Josh Boyer 
>   +arch/powerpc/boot/dts/bamboo.dts: * Josh Boyer (IBM)
> 
> To indicate the author was at IBM when they wrote it?

If that's desired, perhaps:

$ git grep -P --name-only '?' | \
  grep -vP '\.mailmap|MAINTAINERS' | \
  xargs perl -p -i -e 's/?/(IBM)/g'

> Or should we try and update them with current addresses? Though then the
> authors might start getting mails they don't want.

That'd be my preference.

If authors get emails they don't want, then those contact
emails should be removed.




Re: [PATCH] MAINTAINERS: Update remaining @linux.vnet.ibm.com addresses

2019-04-11 Thread Michael Ellerman
Joe Perches  writes:
> On Thu, 2019-04-11 at 06:27 +0200, Lukas Bulwahn wrote:
>> Paul McKenney attempted to update all email addresses @linux.vnet.ibm.com
>> to @linux.ibm.com in commit 1dfddcdb95c4
>> ("MAINTAINERS: Update from @linux.vnet.ibm.com to @linux.ibm.com"), but
>> some still remained.
>> 
>> We update the remaining email addresses in MAINTAINERS, hopefully finally
>> catching all cases for good.
>
> Perhaps update all the similar addresses in other files too
>
> $ git grep --name-only 'linux\.vnet\.ibm\.com' | wc -l
> 315

A good number of them are no longer valid. So I'm not sure it's worth
updating them en masse to addresses that won't ever work.

We have git now, we don't need email addresses in files, they're just
prone to bitrot like this.

Should we just change them all like so?

  -arch/powerpc/boot/dts/bamboo.dts: * Josh Boyer 
  +arch/powerpc/boot/dts/bamboo.dts: * Josh Boyer (IBM)


To indicate the author was at IBM when they wrote it?

Or should we try and update them with current addresses? Though then the
authors might start getting mails they don't want.

cheers


Re: [PATCH v5 16/16] KVM: PPC: Book3S HV: XIVE: introduce a 'release' device operation

2019-04-11 Thread Cédric Le Goater
On 4/11/19 12:27 PM, Paul Mackerras wrote:
> On Wed, Apr 10, 2019 at 07:04:48PM +0200, Cédric Le Goater wrote:
>> When a P9 sPAPR VM boots, the CAS negotiation process determines which
>> interrupt mode to use (XICS legacy or XIVE native) and invokes a
>> machine reset to activate the chosen mode.
>>
>> To be able to switch from one mode to another, we introduce the
>> capability to release a KVM device without destroying the VM. The KVM
>> device interface is extended with a new 'release' operation which is
>> called when the file descriptor of the device is closed.
> 
> Unfortunately, I think there is now a memory leak:
> 
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index ea2018ae1cd7..ea2619d5ca98 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -2938,6 +2938,19 @@ static int kvm_device_release(struct inode *inode, 
>> struct file *filp)
>>  struct kvm_device *dev = filp->private_data;
>>  struct kvm *kvm = dev->kvm;
>>  
>> +if (!dev)
>> +return -ENODEV;
>> +
>> +if (dev->kvm != kvm)
>> +return -EPERM;
>> +
>> +if (dev->ops->release) {
>> +mutex_lock(>lock);
>> +list_del(>vm_node);
> 
> Because the device is now no longer in the kvm->devices list,
> kvm_destroy_devices() won't find it there and therefore won't call the
> device's destroy method.  In fact now the device's destroy method will
> never get called; I can't see how kvmppc_xive_free() or
> kvmppc_xive_native_free() will ever get called.  Thus the memory for
> the kvmppc_xive structs will never get freed as far as I can see.

ah yes. indeed ...

> We could fix that by freeing both of the kvm->arch.xive_devices
> entries at VM destruction time.

That is what I was doing in the first patch I sent : 

http://patchwork.ozlabs.org/patch/1082303/

It worked fine and then, I had this better (worse) idea which I included 
in v5. 
 
> If it is true that any device that has a release method will never see
> its destroy method being called, then that needs to be documented
> clearly somewhere.

Yes. Closing the fd should take care of it. I have to rework that patch.

Thanks,

C.


[PATCH stable v4.9 35/35] powerpc/security: Fix spectre_v2 reporting

2019-04-11 Thread Michael Ellerman
commit 92edf8df0ff2ae86cc632eeca0e651fd8431d40d upstream.

When I updated the spectre_v2 reporting to handle software count cache
flush I got the logic wrong when there's no software count cache
enabled at all.

The result is that on systems with the software count cache flush
disabled we print:

  Mitigation: Indirect branch cache disabled, Software count cache flush

Which correctly indicates that the count cache is disabled, but
incorrectly says the software count cache flush is enabled.

The root of the problem is that we are trying to handle all
combinations of options. But we know now that we only expect to see
the software count cache flush enabled if the other options are false.

So split the two cases, which simplifies the logic and fixes the bug.
We were also missing a space before "(hardware accelerated)".

The result is we see one of:

  Mitigation: Indirect branch serialisation (kernel only)
  Mitigation: Indirect branch cache disabled
  Mitigation: Software count cache flush
  Mitigation: Software count cache flush (hardware accelerated)

Fixes: ee13cb249fab ("powerpc/64s: Add support for software count cache flush")
Cc: sta...@vger.kernel.org # v4.19+
Signed-off-by: Michael Ellerman 
Reviewed-by: Michael Neuling 
Reviewed-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/security.c | 23 ---
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 43ce800e73bf..30542e833ebe 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -190,29 +190,22 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct 
device_attribute *attr, c
bcs = security_ftr_enabled(SEC_FTR_BCCTRL_SERIALISED);
ccd = security_ftr_enabled(SEC_FTR_COUNT_CACHE_DISABLED);
 
-   if (bcs || ccd || count_cache_flush_type != COUNT_CACHE_FLUSH_NONE) {
-   bool comma = false;
+   if (bcs || ccd) {
seq_buf_printf(, "Mitigation: ");
 
-   if (bcs) {
+   if (bcs)
seq_buf_printf(, "Indirect branch serialisation 
(kernel only)");
-   comma = true;
-   }
 
-   if (ccd) {
-   if (comma)
-   seq_buf_printf(, ", ");
-   seq_buf_printf(, "Indirect branch cache disabled");
-   comma = true;
-   }
-
-   if (comma)
+   if (bcs && ccd)
seq_buf_printf(, ", ");
 
-   seq_buf_printf(, "Software count cache flush");
+   if (ccd)
+   seq_buf_printf(, "Indirect branch cache disabled");
+   } else if (count_cache_flush_type != COUNT_CACHE_FLUSH_NONE) {
+   seq_buf_printf(, "Mitigation: Software count cache flush");
 
if (count_cache_flush_type == COUNT_CACHE_FLUSH_HW)
-   seq_buf_printf(, "(hardware accelerated)");
+   seq_buf_printf(, " (hardware accelerated)");
} else if (btb_flush_enabled) {
seq_buf_printf(, "Mitigation: Branch predictor state flush");
} else {
-- 
2.20.1



[PATCH stable v4.9 34/35] powerpc/fsl: Fix the flush of branch predictor.

2019-04-11 Thread Michael Ellerman
From: Christophe Leroy 

commit 27da80719ef132cf8c80eb406d5aeb37dddf78cc upstream.

The commit identified below adds MC_BTB_FLUSH macro only when
CONFIG_PPC_FSL_BOOK3E is defined. This results in the following error
on some configs (seen several times with kisskb randconfig_defconfig)

arch/powerpc/kernel/exceptions-64e.S:576: Error: Unrecognized opcode: 
`mc_btb_flush'
make[3]: *** [scripts/Makefile.build:367: arch/powerpc/kernel/exceptions-64e.o] 
Error 1
make[2]: *** [scripts/Makefile.build:492: arch/powerpc/kernel] Error 2
make[1]: *** [Makefile:1043: arch/powerpc] Error 2
make: *** [Makefile:152: sub-make] Error 2

This patch adds a blank definition of MC_BTB_FLUSH for other cases.

Fixes: 10c5e83afd4a ("powerpc/fsl: Flush the branch predictor at each kernel 
entry (64bit)")
Cc: Diana Craciun 
Signed-off-by: Christophe Leroy 
Reviewed-by: Daniel Axtens 
Reviewed-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/exceptions-64e.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/exceptions-64e.S 
b/arch/powerpc/kernel/exceptions-64e.S
index 79c6fee6368d..423b5257d3a1 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -348,6 +348,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
 #define GEN_BTB_FLUSH
 #define CRIT_BTB_FLUSH
 #define DBG_BTB_FLUSH
+#define MC_BTB_FLUSH
 #define GDBELL_BTB_FLUSH
 #endif
 
-- 
2.20.1



[PATCH stable v4.9 33/35] powerpc/fsl: Fixed warning: orphan section `__btb_flush_fixup'

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit 039daac5526932ec731e4499613018d263af8b3e upstream.

Fixed the following build warning:
powerpc-linux-gnu-ld: warning: orphan section `__btb_flush_fixup' from
`arch/powerpc/kernel/head_44x.o' being placed in section
`__btb_flush_fixup'.

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/head_booke.h | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index 384bb4d80520..7b98c7351f6c 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -31,6 +31,16 @@
  */
 #define THREAD_NORMSAVE(offset)(THREAD_NORMSAVES + (offset * 4))
 
+#ifdef CONFIG_PPC_FSL_BOOK3E
+#define BOOKE_CLEAR_BTB(reg)   
\
+START_BTB_FLUSH_SECTION
\
+   BTB_FLUSH(reg)  
\
+END_BTB_FLUSH_SECTION
+#else
+#define BOOKE_CLEAR_BTB(reg)
+#endif
+
+
 #define NORMAL_EXCEPTION_PROLOG(intno) 
 \
mtspr   SPRN_SPRG_WSCRATCH0, r10;   /* save one register */  \
mfspr   r10, SPRN_SPRG_THREAD;   \
@@ -42,9 +52,7 @@
andi.   r11, r11, MSR_PR;   /* check whether user or kernel*/\
mr  r11, r1; \
beq 1f;  \
-START_BTB_FLUSH_SECTION\
-   BTB_FLUSH(r11)  \
-END_BTB_FLUSH_SECTION  \
+   BOOKE_CLEAR_BTB(r11)\
/* if from user, start at top of this thread's kernel stack */   \
lwz r11, THREAD_INFO-THREAD(r10);\
ALLOC_STACK_FRAME(r11, THREAD_SIZE); \
@@ -130,9 +138,7 @@ END_BTB_FLUSH_SECTION   
\
stw r9,_CCR(r8);/* save CR on stack*/\
mfspr   r11,exc_level_srr1; /* check whether user or kernel*/\
DO_KVM  BOOKE_INTERRUPT_##intno exc_level_srr1;  \
-START_BTB_FLUSH_SECTION
\
-   BTB_FLUSH(r10)  
\
-END_BTB_FLUSH_SECTION  
\
+   BOOKE_CLEAR_BTB(r10)\
andi.   r11,r11,MSR_PR;  \
mfspr   r11,SPRN_SPRG_THREAD;   /* if from user, start at top of   */\
lwz r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
-- 
2.20.1



[PATCH stable v4.9 32/35] powerpc/fsl: Update Spectre v2 reporting

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit dfa88658fb0583abb92e062c7a9cd5a5b94f2a46 upstream.

Report branch predictor state flush as a mitigation for
Spectre variant 2.

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/security.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 6dc5cdc2b87c..43ce800e73bf 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -213,8 +213,11 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct 
device_attribute *attr, c
 
if (count_cache_flush_type == COUNT_CACHE_FLUSH_HW)
seq_buf_printf(, "(hardware accelerated)");
-   } else
+   } else if (btb_flush_enabled) {
+   seq_buf_printf(, "Mitigation: Branch predictor state flush");
+   } else {
seq_buf_printf(, "Vulnerable");
+   }
 
seq_buf_printf(, "\n");
 
-- 
2.20.1



[PATCH stable v4.9 31/35] powerpc/fsl: Enable runtime patching if nospectre_v2 boot arg is used

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit 3bc8ea8603ae4c1e09aca8de229ad38b8091fcb3 upstream.

If the user choses not to use the mitigations, replace
the code sequence with nops.

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/setup-common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index d5a128f54537..5e7d70c5d065 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -919,6 +919,7 @@ void __init setup_arch(char **cmdline_p)
ppc_md.setup_arch();
 
setup_barrier_nospec();
+   setup_spectre_v2();
 
paging_init();
 
-- 
2.20.1



[PATCH stable v4.9 30/35] powerpc/fsl: Flush branch predictor when entering KVM

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit e7aa61f47b23afbec41031bc47ca8d6cb6516abc upstream.

Switching from the guest to host is another place
where the speculative accesses can be exploited.
Flush the branch predictor when entering KVM.

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kvm/bookehv_interrupts.S | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/kvm/bookehv_interrupts.S 
b/arch/powerpc/kvm/bookehv_interrupts.S
index 81bd8a07aa51..612b7f6a887f 100644
--- a/arch/powerpc/kvm/bookehv_interrupts.S
+++ b/arch/powerpc/kvm/bookehv_interrupts.S
@@ -75,6 +75,10 @@
PPC_LL  r1, VCPU_HOST_STACK(r4)
PPC_LL  r2, HOST_R2(r1)
 
+START_BTB_FLUSH_SECTION
+   BTB_FLUSH(r10)
+END_BTB_FLUSH_SECTION
+
mfspr   r10, SPRN_PID
lwz r8, VCPU_HOST_PID(r4)
PPC_LL  r11, VCPU_SHARED(r4)
-- 
2.20.1



[PATCH stable v4.9 29/35] powerpc/fsl: Flush the branch predictor at each kernel entry (32 bit)

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit 7fef436295bf6c05effe682c8797dfcb0deb112a upstream.

In order to protect against speculation attacks on
indirect branches, the branch predictor is flushed at
kernel entry to protect for the following situations:
- userspace process attacking another userspace process
- userspace process attacking the kernel
Basically when the privillege level change (i.e.the kernel
is entered), the branch predictor state is flushed.

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/head_booke.h |  6 ++
 arch/powerpc/kernel/head_fsl_booke.S | 15 +++
 2 files changed, 21 insertions(+)

diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index a620203f7de3..384bb4d80520 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -42,6 +42,9 @@
andi.   r11, r11, MSR_PR;   /* check whether user or kernel*/\
mr  r11, r1; \
beq 1f;  \
+START_BTB_FLUSH_SECTION\
+   BTB_FLUSH(r11)  \
+END_BTB_FLUSH_SECTION  \
/* if from user, start at top of this thread's kernel stack */   \
lwz r11, THREAD_INFO-THREAD(r10);\
ALLOC_STACK_FRAME(r11, THREAD_SIZE); \
@@ -127,6 +130,9 @@
stw r9,_CCR(r8);/* save CR on stack*/\
mfspr   r11,exc_level_srr1; /* check whether user or kernel*/\
DO_KVM  BOOKE_INTERRUPT_##intno exc_level_srr1;  \
+START_BTB_FLUSH_SECTION
\
+   BTB_FLUSH(r10)  
\
+END_BTB_FLUSH_SECTION  
\
andi.   r11,r11,MSR_PR;  \
mfspr   r11,SPRN_SPRG_THREAD;   /* if from user, start at top of   */\
lwz r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
diff --git a/arch/powerpc/kernel/head_fsl_booke.S 
b/arch/powerpc/kernel/head_fsl_booke.S
index bf4c6021515f..60a0aeefc4a7 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -452,6 +452,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
mfcrr13
stw r13, THREAD_NORMSAVE(3)(r10)
DO_KVM  BOOKE_INTERRUPT_DTLB_MISS SPRN_SRR1
+START_BTB_FLUSH_SECTION
+   mfspr r11, SPRN_SRR1
+   andi. r10,r11,MSR_PR
+   beq 1f
+   BTB_FLUSH(r10)
+1:
+END_BTB_FLUSH_SECTION
mfspr   r10, SPRN_DEAR  /* Get faulting address */
 
/* If we are faulting a kernel address, we have to use the
@@ -546,6 +553,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
mfcrr13
stw r13, THREAD_NORMSAVE(3)(r10)
DO_KVM  BOOKE_INTERRUPT_ITLB_MISS SPRN_SRR1
+START_BTB_FLUSH_SECTION
+   mfspr r11, SPRN_SRR1
+   andi. r10,r11,MSR_PR
+   beq 1f
+   BTB_FLUSH(r10)
+1:
+END_BTB_FLUSH_SECTION
+
mfspr   r10, SPRN_SRR0  /* Get faulting address */
 
/* If we are faulting a kernel address, we have to use the
-- 
2.20.1



[PATCH stable v4.9 28/35] powerpc/fsl: Flush the branch predictor at each kernel entry (64bit)

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit 10c5e83afd4a3f01712d97d3bb1ae34d5b74a185 upstream.

In order to protect against speculation attacks on
indirect branches, the branch predictor is flushed at
kernel entry to protect for the following situations:
- userspace process attacking another userspace process
- userspace process attacking the kernel
Basically when the privillege level change (i.e. the
kernel is entered), the branch predictor state is flushed.

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/entry_64.S   |  5 +
 arch/powerpc/kernel/exceptions-64e.S | 26 +-
 arch/powerpc/mm/tlb_low_64e.S|  7 +++
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 6625cec9e7c0..390ebf4ef384 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -80,6 +80,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_TM)
std r0,GPR0(r1)
std r10,GPR1(r1)
beq 2f  /* if from kernel mode */
+#ifdef CONFIG_PPC_FSL_BOOK3E
+START_BTB_FLUSH_SECTION
+   BTB_FLUSH(r10)
+END_BTB_FLUSH_SECTION
+#endif
ACCOUNT_CPU_USER_ENTRY(r13, r10, r11)
 2: std r2,GPR2(r1)
std r3,GPR3(r1)
diff --git a/arch/powerpc/kernel/exceptions-64e.S 
b/arch/powerpc/kernel/exceptions-64e.S
index ca03eb229a9a..79c6fee6368d 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -295,7 +295,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
andi.   r10,r11,MSR_PR; /* save stack pointer */\
beq 1f; /* branch around if supervisor */   \
ld  r1,PACAKSAVE(r13);  /* get kernel stack coming from usr */\
-1: cmpdi   cr1,r1,0;   /* check if SP makes sense */   \
+1: type##_BTB_FLUSH\
+   cmpdi   cr1,r1,0;   /* check if SP makes sense */   \
bge-cr1,exc_##n##_bad_stack;/* bad stack (TODO: out of line) */ \
mfspr   r10,SPRN_##type##_SRR0; /* read SRR0 before touching stack */
 
@@ -327,6 +328,29 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
 #define SPRN_MC_SRR0   SPRN_MCSRR0
 #define SPRN_MC_SRR1   SPRN_MCSRR1
 
+#ifdef CONFIG_PPC_FSL_BOOK3E
+#define GEN_BTB_FLUSH  \
+   START_BTB_FLUSH_SECTION \
+   beq 1f; \
+   BTB_FLUSH(r10)  \
+   1:  \
+   END_BTB_FLUSH_SECTION
+
+#define CRIT_BTB_FLUSH \
+   START_BTB_FLUSH_SECTION \
+   BTB_FLUSH(r10)  \
+   END_BTB_FLUSH_SECTION
+
+#define DBG_BTB_FLUSH CRIT_BTB_FLUSH
+#define MC_BTB_FLUSH CRIT_BTB_FLUSH
+#define GDBELL_BTB_FLUSH GEN_BTB_FLUSH
+#else
+#define GEN_BTB_FLUSH
+#define CRIT_BTB_FLUSH
+#define DBG_BTB_FLUSH
+#define GDBELL_BTB_FLUSH
+#endif
+
 #define NORMAL_EXCEPTION_PROLOG(n, intnum, addition)   \
EXCEPTION_PROLOG(n, intnum, GEN, addition##_GEN(n))
 
diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S
index eb82d787d99a..b7e9c09dfe19 100644
--- a/arch/powerpc/mm/tlb_low_64e.S
+++ b/arch/powerpc/mm/tlb_low_64e.S
@@ -69,6 +69,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
std r15,EX_TLB_R15(r12)
std r10,EX_TLB_CR(r12)
 #ifdef CONFIG_PPC_FSL_BOOK3E
+START_BTB_FLUSH_SECTION
+   mfspr r11, SPRN_SRR1
+   andi. r10,r11,MSR_PR
+   beq 1f
+   BTB_FLUSH(r10)
+1:
+END_BTB_FLUSH_SECTION
std r7,EX_TLB_R7(r12)
 #endif
TLB_MISS_PROLOG_STATS
-- 
2.20.1



[PATCH stable v4.9 27/35] powerpc/fsl: Add nospectre_v2 command line argument

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit f633a8ad636efb5d4bba1a047d4a0f1ef719aa06 upstream.

When the command line argument is present, the Spectre variant 2
mitigations are disabled.

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/setup.h |  5 +
 arch/powerpc/kernel/security.c   | 21 +
 2 files changed, 26 insertions(+)

diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 23ee67e279ae..862ebce3ae54 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -65,6 +65,11 @@ void do_barrier_nospec_fixups_range(bool enable, void 
*start, void *end);
 static inline void do_barrier_nospec_fixups_range(bool enable, void *start, 
void *end) { };
 #endif
 
+#ifdef CONFIG_PPC_FSL_BOOK3E
+void setup_spectre_v2(void);
+#else
+static inline void setup_spectre_v2(void) {};
+#endif
 void do_btb_flush_fixups(void);
 
 #endif /* !__ASSEMBLY__ */
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index fc41bccd9ab6..6dc5cdc2b87c 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -27,6 +27,10 @@ static enum count_cache_flush_type count_cache_flush_type = 
COUNT_CACHE_FLUSH_NO
 
 bool barrier_nospec_enabled;
 static bool no_nospec;
+static bool btb_flush_enabled;
+#ifdef CONFIG_PPC_FSL_BOOK3E
+static bool no_spectrev2;
+#endif
 
 static void enable_barrier_nospec(bool enable)
 {
@@ -102,6 +106,23 @@ static __init int barrier_nospec_debugfs_init(void)
 device_initcall(barrier_nospec_debugfs_init);
 #endif /* CONFIG_DEBUG_FS */
 
+#ifdef CONFIG_PPC_FSL_BOOK3E
+static int __init handle_nospectre_v2(char *p)
+{
+   no_spectrev2 = true;
+
+   return 0;
+}
+early_param("nospectre_v2", handle_nospectre_v2);
+void setup_spectre_v2(void)
+{
+   if (no_spectrev2)
+   do_btb_flush_fixups();
+   else
+   btb_flush_enabled = true;
+}
+#endif /* CONFIG_PPC_FSL_BOOK3E */
+
 #ifdef CONFIG_PPC_BOOK3S_64
 ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, 
char *buf)
 {
-- 
2.20.1



[PATCH stable v4.9 26/35] powerpc/fsl: Emulate SPRN_BUCSR register

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit 98518c4d8728656db349f875fcbbc7c126d4c973 upstream.

In order to flush the branch predictor the guest kernel performs
writes to the BUCSR register which is hypervisor privilleged. However,
the branch predictor is flushed at each KVM entry, so the branch
predictor has been already flushed, so just return as soon as possible
to guest.

Signed-off-by: Diana Craciun 
[mpe: Tweak comment formatting]
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kvm/e500_emulate.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index 990db69a1d0b..fa88f641ac03 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -277,6 +277,13 @@ int kvmppc_core_emulate_mtspr_e500(struct kvm_vcpu *vcpu, 
int sprn, ulong spr_va
vcpu->arch.pwrmgtcr0 = spr_val;
break;
 
+   case SPRN_BUCSR:
+   /*
+* If we are here, it means that we have already flushed the
+* branch predictor, so just return to guest.
+*/
+   break;
+
/* extra exceptions */
 #ifdef CONFIG_SPE_POSSIBLE
case SPRN_IVOR32:
-- 
2.20.1



[PATCH stable v4.9 25/35] powerpc/fsl: Fix spectre_v2 mitigations reporting

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit 7d8bad99ba5a22892f0cad6881289fdc3875a930 upstream.

Currently for CONFIG_PPC_FSL_BOOK3E the spectre_v2 file is incorrect:

  $ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
  "Mitigation: Software count cache flush"

Which is wrong. Fix it to report vulnerable for now.

Fixes: ee13cb249fab ("powerpc/64s: Add support for software count cache flush")
Cc: sta...@vger.kernel.org # v4.19+
Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/security.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index fd4703b6ddc0..fc41bccd9ab6 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -23,7 +23,7 @@ enum count_cache_flush_type {
COUNT_CACHE_FLUSH_SW= 0x2,
COUNT_CACHE_FLUSH_HW= 0x4,
 };
-static enum count_cache_flush_type count_cache_flush_type;
+static enum count_cache_flush_type count_cache_flush_type = 
COUNT_CACHE_FLUSH_NONE;
 
 bool barrier_nospec_enabled;
 static bool no_nospec;
-- 
2.20.1



[PATCH stable v4.9 24/35] powerpc/fsl: Add macro to flush the branch predictor

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit 1cbf8990d79ff69da8ad09e8a3df014e1494462b upstream.

The BUCSR register can be used to invalidate the entries in the
branch prediction mechanisms.

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/ppc_asm.h | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/powerpc/include/asm/ppc_asm.h 
b/arch/powerpc/include/asm/ppc_asm.h
index 24e95be3bfaf..bbd35ba36a22 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -780,4 +780,25 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
.long 0x244c  /* rfid   */
 #endif /* !CONFIG_PPC_BOOK3E */
 #endif /*  __ASSEMBLY__ */
+
+/*
+ * Helper macro for exception table entries
+ */
+#define EX_TABLE(_fault, _target)  \
+   stringify_in_c(.section __ex_table,"a";)\
+   stringify_in_c(.balign 4;)  \
+   stringify_in_c(.long (_fault) - . ;)\
+   stringify_in_c(.long (_target) - . ;)   \
+   stringify_in_c(.previous)
+
+#ifdef CONFIG_PPC_FSL_BOOK3E
+#define BTB_FLUSH(reg) \
+   lis reg,BUCSR_INIT@h;   \
+   ori reg,reg,BUCSR_INIT@l;   \
+   mtspr SPRN_BUCSR,reg;   \
+   isync;
+#else
+#define BTB_FLUSH(reg)
+#endif /* CONFIG_PPC_FSL_BOOK3E */
+
 #endif /* _ASM_POWERPC_PPC_ASM_H */
-- 
2.20.1



[PATCH stable v4.9 23/35] powerpc/fsl: Add infrastructure to fixup branch predictor flush

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit 76a5eaa38b15dda92cd6964248c39b5a6f3a4e9d upstream.

In order to protect against speculation attacks (Spectre
variant 2) on NXP PowerPC platforms, the branch predictor
should be flushed when the privillege level is changed.
This patch is adding the infrastructure to fixup at runtime
the code sections that are performing the branch predictor flush
depending on a boot arg parameter which is added later in a
separate patch.

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/feature-fixups.h | 12 
 arch/powerpc/include/asm/setup.h  |  2 ++
 arch/powerpc/kernel/vmlinux.lds.S |  8 
 arch/powerpc/lib/feature-fixups.c | 23 +++
 4 files changed, 45 insertions(+)

diff --git a/arch/powerpc/include/asm/feature-fixups.h 
b/arch/powerpc/include/asm/feature-fixups.h
index afd3efd38938..175128e19025 100644
--- a/arch/powerpc/include/asm/feature-fixups.h
+++ b/arch/powerpc/include/asm/feature-fixups.h
@@ -221,6 +221,17 @@ void setup_feature_keys(void);
FTR_ENTRY_OFFSET 953b-954b; \
.popsection;
 
+#define START_BTB_FLUSH_SECTION\
+955:   \
+
+#define END_BTB_FLUSH_SECTION  \
+956:   \
+   .pushsection __btb_flush_fixup,"a"; \
+   .align 2;   \
+957:   \
+   FTR_ENTRY_OFFSET 955b-957b; \
+   FTR_ENTRY_OFFSET 956b-957b; \
+   .popsection;
 
 #ifndef __ASSEMBLY__
 
@@ -229,6 +240,7 @@ extern long __start___stf_entry_barrier_fixup, 
__stop___stf_entry_barrier_fixup;
 extern long __start___stf_exit_barrier_fixup, __stop___stf_exit_barrier_fixup;
 extern long __start___rfi_flush_fixup, __stop___rfi_flush_fixup;
 extern long __start___barrier_nospec_fixup, __stop___barrier_nospec_fixup;
+extern long __start__btb_flush_fixup, __stop__btb_flush_fixup;
 
 #endif
 
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index d3e9da62d029..23ee67e279ae 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -65,6 +65,8 @@ void do_barrier_nospec_fixups_range(bool enable, void *start, 
void *end);
 static inline void do_barrier_nospec_fixups_range(bool enable, void *start, 
void *end) { };
 #endif
 
+void do_btb_flush_fixups(void);
+
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_SETUP_H */
diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
b/arch/powerpc/kernel/vmlinux.lds.S
index 5c6cf58943b9..50d365060855 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -164,6 +164,14 @@ SECTIONS
}
 #endif /* CONFIG_PPC_BARRIER_NOSPEC */
 
+#ifdef CONFIG_PPC_FSL_BOOK3E
+   . = ALIGN(8);
+   __spec_btb_flush_fixup : AT(ADDR(__spec_btb_flush_fixup) - LOAD_OFFSET) 
{
+   __start__btb_flush_fixup = .;
+   *(__btb_flush_fixup)
+   __stop__btb_flush_fixup = .;
+   }
+#endif
EXCEPTION_TABLE(0)
 
NOTES :kernel :notes
diff --git a/arch/powerpc/lib/feature-fixups.c 
b/arch/powerpc/lib/feature-fixups.c
index b3e362437ec4..e6ed0ec94bc8 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -347,6 +347,29 @@ void do_barrier_nospec_fixups_range(bool enable, void 
*fixup_start, void *fixup_
 
printk(KERN_DEBUG "barrier-nospec: patched %d locations\n", i);
 }
+
+static void patch_btb_flush_section(long *curr)
+{
+   unsigned int *start, *end;
+
+   start = (void *)curr + *curr;
+   end = (void *)curr + *(curr + 1);
+   for (; start < end; start++) {
+   pr_devel("patching dest %lx\n", (unsigned long)start);
+   patch_instruction(start, PPC_INST_NOP);
+   }
+}
+
+void do_btb_flush_fixups(void)
+{
+   long *start, *end;
+
+   start = PTRRELOC(&__start__btb_flush_fixup);
+   end = PTRRELOC(&__stop__btb_flush_fixup);
+
+   for (; start < end; start += 2)
+   patch_btb_flush_section(start);
+}
 #endif /* CONFIG_PPC_FSL_BOOK3E */
 
 void do_lwsync_fixups(unsigned long value, void *fixup_start, void *fixup_end)
-- 
2.20.1



[PATCH stable v4.9 22/35] powerpc/powernv: Query firmware for count cache flush settings

2019-04-11 Thread Michael Ellerman
commit 99d54754d3d5f896a8f616b0b6520662bc99d66b upstream.

Look for fw-features properties to determine the appropriate settings
for the count cache flush, and then call the generic powerpc code to
set it up based on the security feature flags.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/platforms/powernv/setup.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/setup.c 
b/arch/powerpc/platforms/powernv/setup.c
index 17203abf38e8..365e2b620201 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -77,6 +77,12 @@ static void init_fw_feat_flags(struct device_node *np)
if (fw_feature_is("enabled", "fw-count-cache-disabled", np))
security_ftr_set(SEC_FTR_COUNT_CACHE_DISABLED);
 
+   if (fw_feature_is("enabled", "fw-count-cache-flush-bcctr2,0,0", np))
+   security_ftr_set(SEC_FTR_BCCTR_FLUSH_ASSIST);
+
+   if (fw_feature_is("enabled", 
"needs-count-cache-flush-on-context-switch", np))
+   security_ftr_set(SEC_FTR_FLUSH_COUNT_CACHE);
+
/*
 * The features below are enabled by default, so we instead look to see
 * if firmware has *disabled* them, and clear them if so.
@@ -123,6 +129,7 @@ static void pnv_setup_rfi_flush(void)
  security_ftr_enabled(SEC_FTR_L1D_FLUSH_HV));
 
setup_rfi_flush(type, enable);
+   setup_count_cache_flush();
 }
 
 static void __init pnv_setup_arch(void)
-- 
2.20.1



[PATCH stable v4.9 21/35] powerpc/pseries: Query hypervisor for count cache flush settings

2019-04-11 Thread Michael Ellerman
commit ba72dc171954b782a79d25e0f4b3ed91090c3b1e upstream.

Use the existing hypercall to determine the appropriate settings for
the count cache flush, and then call the generic powerpc code to set
it up based on the security feature flags.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/hvcall.h  | 2 ++
 arch/powerpc/platforms/pseries/setup.c | 7 +++
 2 files changed, 9 insertions(+)

diff --git a/arch/powerpc/include/asm/hvcall.h 
b/arch/powerpc/include/asm/hvcall.h
index 9d978102bf0d..9587d301db55 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -316,10 +316,12 @@
 #define H_CPU_CHAR_BRANCH_HINTS_HONORED(1ull << 58) // IBM bit 5
 #define H_CPU_CHAR_THREAD_RECONFIG_CTRL(1ull << 57) // IBM bit 6
 #define H_CPU_CHAR_COUNT_CACHE_DISABLED(1ull << 56) // IBM bit 7
+#define H_CPU_CHAR_BCCTR_FLUSH_ASSIST  (1ull << 54) // IBM bit 9
 
 #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
+#define H_CPU_BEHAV_FLUSH_COUNT_CACHE  (1ull << 58) // IBM bit 5
 
 #ifndef __ASSEMBLY__
 #include 
diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index 91ade7755823..adb09ab87f7c 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -475,6 +475,12 @@ static void init_cpu_char_feature_flags(struct 
h_cpu_char_result *result)
if (result->character & H_CPU_CHAR_COUNT_CACHE_DISABLED)
security_ftr_set(SEC_FTR_COUNT_CACHE_DISABLED);
 
+   if (result->character & H_CPU_CHAR_BCCTR_FLUSH_ASSIST)
+   security_ftr_set(SEC_FTR_BCCTR_FLUSH_ASSIST);
+
+   if (result->behaviour & H_CPU_BEHAV_FLUSH_COUNT_CACHE)
+   security_ftr_set(SEC_FTR_FLUSH_COUNT_CACHE);
+
/*
 * The features below are enabled by default, so we instead look to see
 * if firmware has *disabled* them, and clear them if so.
@@ -525,6 +531,7 @@ void pseries_setup_rfi_flush(void)
 security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR);
 
setup_rfi_flush(types, enable);
+   setup_count_cache_flush();
 }
 
 static void __init pSeries_setup_arch(void)
-- 
2.20.1



[PATCH stable v4.9 20/35] powerpc/64s: Add support for software count cache flush

2019-04-11 Thread Michael Ellerman
commit ee13cb249fabdff8b90aaff61add347749280087 upstream.

Some CPU revisions support a mode where the count cache needs to be
flushed by software on context switch. Additionally some revisions may
have a hardware accelerated flush, in which case the software flush
sequence can be shortened.

If we detect the appropriate flag from firmware we patch a branch
into _switch() which takes us to a count cache flush sequence.

That sequence in turn may be patched to return early if we detect that
the CPU supports accelerating the flush sequence in hardware.

Add debugfs support for reporting the state of the flush, as well as
runtime disabling it.

And modify the spectre_v2 sysfs file to report the state of the
software flush.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/asm-prototypes.h|  6 ++
 arch/powerpc/include/asm/security_features.h |  1 +
 arch/powerpc/kernel/entry_64.S   | 54 +++
 arch/powerpc/kernel/security.c   | 98 +++-
 4 files changed, 154 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/asm-prototypes.h 
b/arch/powerpc/include/asm/asm-prototypes.h
index e0baba1535e6..f3daa175f86c 100644
--- a/arch/powerpc/include/asm/asm-prototypes.h
+++ b/arch/powerpc/include/asm/asm-prototypes.h
@@ -121,4 +121,10 @@ extern s64 __ashrdi3(s64, int);
 extern int __cmpdi2(s64, s64);
 extern int __ucmpdi2(u64, u64);
 
+/* Patch sites */
+extern s32 patch__call_flush_count_cache;
+extern s32 patch__flush_count_cache_return;
+
+extern long flush_count_cache;
+
 #endif /* _ASM_POWERPC_ASM_PROTOTYPES_H */
diff --git a/arch/powerpc/include/asm/security_features.h 
b/arch/powerpc/include/asm/security_features.h
index a0d47bc18a5c..759597bf0fd8 100644
--- a/arch/powerpc/include/asm/security_features.h
+++ b/arch/powerpc/include/asm/security_features.h
@@ -22,6 +22,7 @@ enum stf_barrier_type {
 
 void setup_stf_barrier(void);
 void do_stf_barrier_fixups(enum stf_barrier_type types);
+void setup_count_cache_flush(void);
 
 static inline void security_ftr_set(unsigned long feature)
 {
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 11e390662384..6625cec9e7c0 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -483,6 +484,57 @@ _GLOBAL(ret_from_kernel_thread)
li  r3,0
b   .Lsyscall_exit
 
+#ifdef CONFIG_PPC_BOOK3S_64
+
+#define FLUSH_COUNT_CACHE  \
+1: nop;\
+   patch_site 1b, patch__call_flush_count_cache
+
+
+#define BCCTR_FLUSH.long 0x4c400420
+
+.macro nops number
+   .rept \number
+   nop
+   .endr
+.endm
+
+.balign 32
+.global flush_count_cache
+flush_count_cache:
+   /* Save LR into r9 */
+   mflrr9
+
+   .rept 64
+   bl  .+4
+   .endr
+   b   1f
+   nops6
+
+   .balign 32
+   /* Restore LR */
+1: mtlrr9
+   li  r9,0x7fff
+   mtctr   r9
+
+   BCCTR_FLUSH
+
+2: nop
+   patch_site 2b patch__flush_count_cache_return
+
+   nops3
+
+   .rept 278
+   .balign 32
+   BCCTR_FLUSH
+   nops7
+   .endr
+
+   blr
+#else
+#define FLUSH_COUNT_CACHE
+#endif /* CONFIG_PPC_BOOK3S_64 */
+
 /*
  * This routine switches between two different tasks.  The process
  * state of one is saved on its kernel stack.  Then the state
@@ -514,6 +566,8 @@ _GLOBAL(_switch)
std r23,_CCR(r1)
std r1,KSP(r3)  /* Set old stack pointer */
 
+   FLUSH_COUNT_CACHE
+
 #ifdef CONFIG_SMP
/* We need a sync somewhere here to make sure that if the
 * previous task gets rescheduled on another CPU, it sees all
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 2f30fc8ed0a8..fd4703b6ddc0 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -9,6 +9,8 @@
 #include 
 #include 
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -16,6 +18,13 @@
 
 unsigned long powerpc_security_features __read_mostly = SEC_FTR_DEFAULT;
 
+enum count_cache_flush_type {
+   COUNT_CACHE_FLUSH_NONE  = 0x1,
+   COUNT_CACHE_FLUSH_SW= 0x2,
+   COUNT_CACHE_FLUSH_HW= 0x4,
+};
+static enum count_cache_flush_type count_cache_flush_type;
+
 bool barrier_nospec_enabled;
 static bool no_nospec;
 
@@ -160,17 +169,29 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct 
device_attribute *attr, c
bcs = security_ftr_enabled(SEC_FTR_BCCTRL_SERIALISED);
ccd = security_ftr_enabled(SEC_FTR_COUNT_CACHE_DISABLED);
 
-   if (bcs || ccd) {
+   if (bcs || ccd || count_cache_flush_type != COUNT_CACHE_FLUSH_NONE) {
+   bool comma = false;
seq_buf_printf(, "Mitigation: ");
 
-   if (bcs)
+   if (bcs) {
seq_buf_printf(, "Indirect branch 

[PATCH stable v4.9 19/35] powerpc/64s: Add new security feature flags for count cache flush

2019-04-11 Thread Michael Ellerman
commit dc8c6cce9a26a51fc19961accb978217a3ba8c75 upstream.

Add security feature flags to indicate the need for software to flush
the count cache on context switch, and for the presence of a hardware
assisted count cache flush.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/security_features.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/powerpc/include/asm/security_features.h 
b/arch/powerpc/include/asm/security_features.h
index 44989b22383c..a0d47bc18a5c 100644
--- a/arch/powerpc/include/asm/security_features.h
+++ b/arch/powerpc/include/asm/security_features.h
@@ -59,6 +59,9 @@ static inline bool security_ftr_enabled(unsigned long feature)
 // Indirect branch prediction cache disabled
 #define SEC_FTR_COUNT_CACHE_DISABLED   0x0020ull
 
+// bcctr 2,0,0 triggers a hardware assisted count cache flush
+#define SEC_FTR_BCCTR_FLUSH_ASSIST 0x0800ull
+
 
 // Features indicating need for Spectre/Meltdown mitigations
 
@@ -74,6 +77,9 @@ static inline bool security_ftr_enabled(unsigned long feature)
 // Firmware configuration indicates user favours security over performance
 #define SEC_FTR_FAVOUR_SECURITY0x0200ull
 
+// Software required to flush count cache on context switch
+#define SEC_FTR_FLUSH_COUNT_CACHE  0x0400ull
+
 
 // Features enabled by default
 #define SEC_FTR_DEFAULT \
-- 
2.20.1



[PATCH stable v4.9 18/35] powerpc/asm: Add a patch_site macro & helpers for patching instructions

2019-04-11 Thread Michael Ellerman
commit 06d0bbc6d0f56dacac3a79900e9a9a0d5972d818 upstream.

Add a macro and some helper C functions for patching single asm
instructions.

The gas macro means we can do something like:

  1:nop
patch_site 1b, patch__foo

Which is less visually distracting than defining a GLOBAL symbol at 1,
and also doesn't pollute the symbol table which can confuse eg. perf.

These are obviously similar to our existing feature sections, but are
not automatically patched based on CPU/MMU features, rather they are
designed to be manually patched by C code at some arbitrary point.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/code-patching-asm.h | 18 ++
 arch/powerpc/include/asm/code-patching.h |  2 ++
 arch/powerpc/lib/code-patching.c | 16 
 3 files changed, 36 insertions(+)
 create mode 100644 arch/powerpc/include/asm/code-patching-asm.h

diff --git a/arch/powerpc/include/asm/code-patching-asm.h 
b/arch/powerpc/include/asm/code-patching-asm.h
new file mode 100644
index ..ed7b1448493a
--- /dev/null
+++ b/arch/powerpc/include/asm/code-patching-asm.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2018, Michael Ellerman, IBM Corporation.
+ */
+#ifndef _ASM_POWERPC_CODE_PATCHING_ASM_H
+#define _ASM_POWERPC_CODE_PATCHING_ASM_H
+
+/* Define a "site" that can be patched */
+.macro patch_site label name
+   .pushsection ".rodata"
+   .balign 4
+   .global \name
+\name:
+   .4byte  \label - .
+   .popsection
+.endm
+
+#endif /* _ASM_POWERPC_CODE_PATCHING_ASM_H */
diff --git a/arch/powerpc/include/asm/code-patching.h 
b/arch/powerpc/include/asm/code-patching.h
index b4ab1f497335..ab934f8232bd 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -28,6 +28,8 @@ unsigned int create_cond_branch(const unsigned int *addr,
unsigned long target, int flags);
 int patch_branch(unsigned int *addr, unsigned long target, int flags);
 int patch_instruction(unsigned int *addr, unsigned int instr);
+int patch_instruction_site(s32 *addr, unsigned int instr);
+int patch_branch_site(s32 *site, unsigned long target, int flags);
 
 int instr_is_relative_branch(unsigned int instr);
 int instr_is_relative_link_branch(unsigned int instr);
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index c77c486fbf24..14535ad4cdd1 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -40,6 +40,22 @@ int patch_branch(unsigned int *addr, unsigned long target, 
int flags)
return patch_instruction(addr, create_branch(addr, target, flags));
 }
 
+int patch_branch_site(s32 *site, unsigned long target, int flags)
+{
+   unsigned int *addr;
+
+   addr = (unsigned int *)((unsigned long)site + *site);
+   return patch_instruction(addr, create_branch(addr, target, flags));
+}
+
+int patch_instruction_site(s32 *site, unsigned int instr)
+{
+   unsigned int *addr;
+
+   addr = (unsigned int *)((unsigned long)site + *site);
+   return patch_instruction(addr, instr);
+}
+
 unsigned int create_branch(const unsigned int *addr,
   unsigned long target, int flags)
 {
-- 
2.20.1



[PATCH stable v4.9 17/35] powerpc/fsl: Sanitize the syscall table for NXP PowerPC 32 bit platforms

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit c28218d4abbf4f2035495334d8bfcba64bda4787 upstream.

Used barrier_nospec to sanitize the syscall table.

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/entry_32.S | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 370645687cc7..bdd88f9d7926 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * MSR_KERNEL is > 0x1 on 4xx/Book-E since it include MSR_CE.
@@ -347,6 +348,15 @@ _GLOBAL(DoSyscall)
ori r10,r10,sys_call_table@l
slwir0,r0,2
bge-66f
+
+   barrier_nospec_asm
+   /*
+* Prevent the load of the handler below (based on the user-passed
+* system call number) being speculatively executed until the test
+* against NR_syscalls and branch to .66f above has
+* committed.
+*/
+
lwzxr10,r10,r0  /* Fetch system call handler [ptr] */
mtlrr10
addir9,r1,STACK_FRAME_OVERHEAD
-- 
2.20.1



[PATCH stable v4.9 16/35] powerpc/fsl: Add barrier_nospec implementation for NXP PowerPC Book3E

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit ebcd1bfc33c7a90df941df68a6e5d4018c022fba upstream.

Implement the barrier_nospec as a isync;sync instruction sequence.
The implementation uses the infrastructure built for BOOK3S 64.

Signed-off-by: Diana Craciun 
[mpe: Split out of larger patch]
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/Kconfig   |  2 +-
 arch/powerpc/include/asm/barrier.h |  8 +++-
 arch/powerpc/lib/feature-fixups.c  | 31 ++
 3 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a238698178fc..fa8f2aa88189 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -167,7 +167,7 @@ config PPC
 config PPC_BARRIER_NOSPEC
 bool
 default y
-depends on PPC_BOOK3S_64
+depends on PPC_BOOK3S_64 || PPC_FSL_BOOK3E
 
 config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
diff --git a/arch/powerpc/include/asm/barrier.h 
b/arch/powerpc/include/asm/barrier.h
index 465a64316897..80024c4f2093 100644
--- a/arch/powerpc/include/asm/barrier.h
+++ b/arch/powerpc/include/asm/barrier.h
@@ -77,12 +77,18 @@ do {
\
 
 #define smp_mb__before_spinlock()   smp_mb()
 
+#ifdef CONFIG_PPC_BOOK3S_64
+#define NOSPEC_BARRIER_SLOT   nop
+#elif defined(CONFIG_PPC_FSL_BOOK3E)
+#define NOSPEC_BARRIER_SLOT   nop; nop
+#endif
+
 #ifdef CONFIG_PPC_BARRIER_NOSPEC
 /*
  * Prevent execution of subsequent instructions until preceding branches have
  * been fully resolved and are no longer executing speculatively.
  */
-#define barrier_nospec_asm NOSPEC_BARRIER_FIXUP_SECTION; nop
+#define barrier_nospec_asm NOSPEC_BARRIER_FIXUP_SECTION; NOSPEC_BARRIER_SLOT
 
 // This also acts as a compiler barrier due to the memory clobber.
 #define barrier_nospec() asm (stringify_in_c(barrier_nospec_asm) ::: "memory")
diff --git a/arch/powerpc/lib/feature-fixups.c 
b/arch/powerpc/lib/feature-fixups.c
index 5df57f7bae0a..b3e362437ec4 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -318,6 +318,37 @@ void do_barrier_nospec_fixups(bool enable)
 }
 #endif /* CONFIG_PPC_BARRIER_NOSPEC */
 
+#ifdef CONFIG_PPC_FSL_BOOK3E
+void do_barrier_nospec_fixups_range(bool enable, void *fixup_start, void 
*fixup_end)
+{
+   unsigned int instr[2], *dest;
+   long *start, *end;
+   int i;
+
+   start = fixup_start;
+   end = fixup_end;
+
+   instr[0] = PPC_INST_NOP;
+   instr[1] = PPC_INST_NOP;
+
+   if (enable) {
+   pr_info("barrier-nospec: using isync; sync as speculation 
barrier\n");
+   instr[0] = PPC_INST_ISYNC;
+   instr[1] = PPC_INST_SYNC;
+   }
+
+   for (i = 0; start < end; start++, i++) {
+   dest = (void *)start + *start;
+
+   pr_devel("patching dest %lx\n", (unsigned long)dest);
+   patch_instruction(dest, instr[0]);
+   patch_instruction(dest + 1, instr[1]);
+   }
+
+   printk(KERN_DEBUG "barrier-nospec: patched %d locations\n", i);
+}
+#endif /* CONFIG_PPC_FSL_BOOK3E */
+
 void do_lwsync_fixups(unsigned long value, void *fixup_start, void *fixup_end)
 {
long *start, *end;
-- 
2.20.1



[PATCH stable v4.9 15/35] powerpc/64: Make meltdown reporting Book3S 64 specific

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit 406d2b6ae3420f5bb2b3db6986dc6f0b6dbb637b upstream.

In a subsequent patch we will enable building security.c for Book3E.
However the NXP platforms are not vulnerable to Meltdown, so make the
Meltdown vulnerability reporting PPC_BOOK3S_64 specific.

Signed-off-by: Diana Craciun 
[mpe: Split out of larger patch]
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/security.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 926ed3c38741..2f30fc8ed0a8 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -93,6 +93,7 @@ static __init int barrier_nospec_debugfs_init(void)
 device_initcall(barrier_nospec_debugfs_init);
 #endif /* CONFIG_DEBUG_FS */
 
+#ifdef CONFIG_PPC_BOOK3S_64
 ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, 
char *buf)
 {
bool thread_priv;
@@ -125,6 +126,7 @@ ssize_t cpu_show_meltdown(struct device *dev, struct 
device_attribute *attr, cha
 
return sprintf(buf, "Vulnerable\n");
 }
+#endif
 
 ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr, 
char *buf)
 {
-- 
2.20.1



[PATCH stable v4.9 14/35] powerpc/64: Call setup_barrier_nospec() from setup_arch()

2019-04-11 Thread Michael Ellerman
commit af375eefbfb27cbb5b831984e66d724a40d26b5c upstream.

Currently we require platform code to call setup_barrier_nospec(). But
if we add an empty definition for the !CONFIG_PPC_BARRIER_NOSPEC case
then we can call it in setup_arch().

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/setup.h   | 4 
 arch/powerpc/kernel/setup-common.c | 2 ++
 arch/powerpc/platforms/powernv/setup.c | 1 -
 arch/powerpc/platforms/pseries/setup.c | 1 -
 4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 38525bd2ed65..d3e9da62d029 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -51,7 +51,11 @@ enum l1d_flush_type {
 
 void setup_rfi_flush(enum l1d_flush_type, bool enable);
 void do_rfi_flush_fixups(enum l1d_flush_type types);
+#ifdef CONFIG_PPC_BARRIER_NOSPEC
 void setup_barrier_nospec(void);
+#else
+static inline void setup_barrier_nospec(void) { };
+#endif
 void do_barrier_nospec_fixups(bool enable);
 extern bool barrier_nospec_enabled;
 
diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index bf0f712ac0e0..d5a128f54537 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -918,6 +918,8 @@ void __init setup_arch(char **cmdline_p)
if (ppc_md.setup_arch)
ppc_md.setup_arch();
 
+   setup_barrier_nospec();
+
paging_init();
 
/* Initialize the MMU context management stuff. */
diff --git a/arch/powerpc/platforms/powernv/setup.c 
b/arch/powerpc/platforms/powernv/setup.c
index eb5464648810..17203abf38e8 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -123,7 +123,6 @@ static void pnv_setup_rfi_flush(void)
  security_ftr_enabled(SEC_FTR_L1D_FLUSH_HV));
 
setup_rfi_flush(type, enable);
-   setup_barrier_nospec();
 }
 
 static void __init pnv_setup_arch(void)
diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index 2b2759c98c7e..91ade7755823 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -525,7 +525,6 @@ void pseries_setup_rfi_flush(void)
 security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR);
 
setup_rfi_flush(types, enable);
-   setup_barrier_nospec();
 }
 
 static void __init pSeries_setup_arch(void)
-- 
2.20.1



[PATCH stable v4.9 13/35] powerpc/64: Add CONFIG_PPC_BARRIER_NOSPEC

2019-04-11 Thread Michael Ellerman
commit 179ab1cbf883575c3a585bcfc0f2160f1d22a149 upstream.

Add a config symbol to encode which platforms support the
barrier_nospec speculation barrier. Currently this is just Book3S 64
but we will add Book3E in a future patch.

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/Kconfig   | 7 ++-
 arch/powerpc/include/asm/barrier.h | 6 +++---
 arch/powerpc/include/asm/setup.h   | 2 +-
 arch/powerpc/kernel/Makefile   | 3 ++-
 arch/powerpc/kernel/module.c   | 4 +++-
 arch/powerpc/kernel/vmlinux.lds.S  | 4 +++-
 arch/powerpc/lib/feature-fixups.c  | 6 --
 7 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 0a6bb48854e3..a238698178fc 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -128,7 +128,7 @@ config PPC
select ARCH_HAS_GCOV_PROFILE_ALL
select GENERIC_SMP_IDLE_THREAD
select GENERIC_CMOS_UPDATE
-   select GENERIC_CPU_VULNERABILITIES  if PPC_BOOK3S_64
+   select GENERIC_CPU_VULNERABILITIES  if PPC_BARRIER_NOSPEC
select GENERIC_TIME_VSYSCALL_OLD
select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
@@ -164,6 +164,11 @@ config PPC
select HAVE_ARCH_HARDENED_USERCOPY
select HAVE_KERNEL_GZIP
 
+config PPC_BARRIER_NOSPEC
+bool
+default y
+depends on PPC_BOOK3S_64
+
 config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
 
diff --git a/arch/powerpc/include/asm/barrier.h 
b/arch/powerpc/include/asm/barrier.h
index a8131162104f..465a64316897 100644
--- a/arch/powerpc/include/asm/barrier.h
+++ b/arch/powerpc/include/asm/barrier.h
@@ -77,7 +77,7 @@ do {  
\
 
 #define smp_mb__before_spinlock()   smp_mb()
 
-#ifdef CONFIG_PPC_BOOK3S_64
+#ifdef CONFIG_PPC_BARRIER_NOSPEC
 /*
  * Prevent execution of subsequent instructions until preceding branches have
  * been fully resolved and are no longer executing speculatively.
@@ -87,10 +87,10 @@ do {
\
 // This also acts as a compiler barrier due to the memory clobber.
 #define barrier_nospec() asm (stringify_in_c(barrier_nospec_asm) ::: "memory")
 
-#else /* !CONFIG_PPC_BOOK3S_64 */
+#else /* !CONFIG_PPC_BARRIER_NOSPEC */
 #define barrier_nospec_asm
 #define barrier_nospec()
-#endif
+#endif /* CONFIG_PPC_BARRIER_NOSPEC */
 
 #include 
 
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 84ae150ce6a6..38525bd2ed65 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -55,7 +55,7 @@ void setup_barrier_nospec(void);
 void do_barrier_nospec_fixups(bool enable);
 extern bool barrier_nospec_enabled;
 
-#ifdef CONFIG_PPC_BOOK3S_64
+#ifdef CONFIG_PPC_BARRIER_NOSPEC
 void do_barrier_nospec_fixups_range(bool enable, void *start, void *end);
 #else
 static inline void do_barrier_nospec_fixups_range(bool enable, void *start, 
void *end) { };
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 13885786282b..d80fbf0884ff 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -44,9 +44,10 @@ obj-$(CONFIG_PPC64)  += setup_64.o sys_ppc32.o \
 obj-$(CONFIG_VDSO32)   += vdso32/
 obj-$(CONFIG_HAVE_HW_BREAKPOINT)   += hw_breakpoint.o
 obj-$(CONFIG_PPC_BOOK3S_64)+= cpu_setup_ppc970.o cpu_setup_pa6t.o
-obj-$(CONFIG_PPC_BOOK3S_64)+= cpu_setup_power.o security.o
+obj-$(CONFIG_PPC_BOOK3S_64)+= cpu_setup_power.o
 obj-$(CONFIG_PPC_BOOK3S_64)+= mce.o mce_power.o
 obj-$(CONFIG_PPC_BOOK3E_64)+= exceptions-64e.o idle_book3e.o
+obj-$(CONFIG_PPC_BARRIER_NOSPEC) += security.o
 obj-$(CONFIG_PPC64)+= vdso64/
 obj-$(CONFIG_ALTIVEC)  += vecemu.o
 obj-$(CONFIG_PPC_970_NAP)  += idle_power4.o
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index d30f0626dcd0..3b1c3bb91025 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -72,13 +72,15 @@ int module_finalize(const Elf_Ehdr *hdr,
do_feature_fixups(powerpc_firmware_features,
  (void *)sect->sh_addr,
  (void *)sect->sh_addr + sect->sh_size);
+#endif /* CONFIG_PPC64 */
 
+#ifdef CONFIG_PPC_BARRIER_NOSPEC
sect = find_section(hdr, sechdrs, "__spec_barrier_fixup");
if (sect != NULL)
do_barrier_nospec_fixups_range(barrier_nospec_enabled,
  (void *)sect->sh_addr,
  (void *)sect->sh_addr + sect->sh_size);
-#endif
+#endif /* CONFIG_PPC_BARRIER_NOSPEC */
 
sect = find_section(hdr, sechdrs, "__lwsync_fixup");
if (sect != NULL)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
b/arch/powerpc/kernel/vmlinux.lds.S
index 61def0be6914..5c6cf58943b9 100644
--- 

[PATCH stable v4.9 11/35] powerpc/64: Disable the speculation barrier from the command line

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit cf175dc315f90185128fb061dc05b6fbb211aa2f upstream.

The speculation barrier can be disabled from the command line
with the parameter: "nospectre_v1".

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/security.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index bf298d0c475f..813e38ff81ce 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -17,6 +17,7 @@
 unsigned long powerpc_security_features __read_mostly = SEC_FTR_DEFAULT;
 
 bool barrier_nospec_enabled;
+static bool no_nospec;
 
 static void enable_barrier_nospec(bool enable)
 {
@@ -43,9 +44,18 @@ void setup_barrier_nospec(void)
enable = security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) &&
 security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR);
 
-   enable_barrier_nospec(enable);
+   if (!no_nospec)
+   enable_barrier_nospec(enable);
 }
 
+static int __init handle_nospectre_v1(char *p)
+{
+   no_nospec = true;
+
+   return 0;
+}
+early_param("nospectre_v1", handle_nospectre_v1);
+
 #ifdef CONFIG_DEBUG_FS
 static int barrier_nospec_set(void *data, u64 val)
 {
-- 
2.20.1



[PATCH stable v4.9 12/35] powerpc/64: Make stf barrier PPC_BOOK3S_64 specific.

2019-04-11 Thread Michael Ellerman
From: Diana Craciun 

commit 6453b532f2c8856a80381e6b9a1f5ea2f12294df upstream.

NXP Book3E platforms are not vulnerable to speculative store
bypass, so make the mitigations PPC_BOOK3S_64 specific.

Signed-off-by: Diana Craciun 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/security.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 813e38ff81ce..926ed3c38741 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -177,6 +177,7 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct 
device_attribute *attr, c
return s.len;
 }
 
+#ifdef CONFIG_PPC_BOOK3S_64
 /*
  * Store-forwarding barrier support.
  */
@@ -324,3 +325,4 @@ static __init int stf_barrier_debugfs_init(void)
 }
 device_initcall(stf_barrier_debugfs_init);
 #endif /* CONFIG_DEBUG_FS */
+#endif /* CONFIG_PPC_BOOK3S_64 */
-- 
2.20.1



[PATCH stable v4.9 10/35] powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2

2019-04-11 Thread Michael Ellerman
commit 6d44acae1937b81cf8115ada8958e04f601f3f2e upstream.

When I added the spectre_v2 information in sysfs, I included the
availability of the ori31 speculation barrier.

Although the ori31 barrier can be used to mitigate v2, it's primarily
intended as a spectre v1 mitigation. Spectre v2 is mitigated by
hardware changes.

So rework the sysfs files to show the ori31 information in the
spectre_v1 file, rather than v2.

Currently we display eg:

  $ grep . spectre_v*
  spectre_v1:Mitigation: __user pointer sanitization
  spectre_v2:Mitigation: Indirect branch cache disabled, ori31 speculation 
barrier enabled

After:

  $ grep . spectre_v*
  spectre_v1:Mitigation: __user pointer sanitization, ori31 speculation barrier 
enabled
  spectre_v2:Mitigation: Indirect branch cache disabled

Fixes: d6fbe1c55c55 ("powerpc/64s: Wire up cpu_show_spectre_v2()")
Cc: sta...@vger.kernel.org # v4.17+
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/security.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index f189f946d935..bf298d0c475f 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -118,25 +118,35 @@ ssize_t cpu_show_meltdown(struct device *dev, struct 
device_attribute *attr, cha
 
 ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr, 
char *buf)
 {
-   if (!security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR))
-   return sprintf(buf, "Not affected\n");
+   struct seq_buf s;
+
+   seq_buf_init(, buf, PAGE_SIZE - 1);
 
-   if (barrier_nospec_enabled)
-   return sprintf(buf, "Mitigation: __user pointer 
sanitization\n");
+   if (security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR)) {
+   if (barrier_nospec_enabled)
+   seq_buf_printf(, "Mitigation: __user pointer 
sanitization");
+   else
+   seq_buf_printf(, "Vulnerable");
 
-   return sprintf(buf, "Vulnerable\n");
+   if (security_ftr_enabled(SEC_FTR_SPEC_BAR_ORI31))
+   seq_buf_printf(, ", ori31 speculation barrier 
enabled");
+
+   seq_buf_printf(, "\n");
+   } else
+   seq_buf_printf(, "Not affected\n");
+
+   return s.len;
 }
 
 ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr, 
char *buf)
 {
-   bool bcs, ccd, ori;
struct seq_buf s;
+   bool bcs, ccd;
 
seq_buf_init(, buf, PAGE_SIZE - 1);
 
bcs = security_ftr_enabled(SEC_FTR_BCCTRL_SERIALISED);
ccd = security_ftr_enabled(SEC_FTR_COUNT_CACHE_DISABLED);
-   ori = security_ftr_enabled(SEC_FTR_SPEC_BAR_ORI31);
 
if (bcs || ccd) {
seq_buf_printf(, "Mitigation: ");
@@ -152,9 +162,6 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct 
device_attribute *attr, c
} else
seq_buf_printf(, "Vulnerable");
 
-   if (ori)
-   seq_buf_printf(, ", ori31 speculation barrier enabled");
-
seq_buf_printf(, "\n");
 
return s.len;
-- 
2.20.1



[PATCH stable v4.9 09/35] powerpc/64s: Enhance the information in cpu_show_spectre_v1()

2019-04-11 Thread Michael Ellerman
From: Michal Suchanek 

commit a377514519b9a20fa1ea9adddbb4129573129cef upstream.

We now have barrier_nospec as mitigation so print it in
cpu_show_spectre_v1() when enabled.

Signed-off-by: Michal Suchanek 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/security.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index d0e974da4918..f189f946d935 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -121,6 +121,9 @@ ssize_t cpu_show_spectre_v1(struct device *dev, struct 
device_attribute *attr, c
if (!security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR))
return sprintf(buf, "Not affected\n");
 
+   if (barrier_nospec_enabled)
+   return sprintf(buf, "Mitigation: __user pointer 
sanitization\n");
+
return sprintf(buf, "Vulnerable\n");
 }
 
-- 
2.20.1



[PATCH stable v4.9 08/35] powerpc/64: Use barrier_nospec in syscall entry

2019-04-11 Thread Michael Ellerman
commit 51973a815c6b46d7b23b68d6af371ad1c9d503ca upstream.

Our syscall entry is done in assembly so patch in an explicit
barrier_nospec.

Based on a patch by Michal Suchanek.

Signed-off-by: Michal Suchanek 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/entry_64.S | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index e24ae0fa80ed..11e390662384 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #ifdef CONFIG_PPC_BOOK3S
 #include 
@@ -180,6 +181,15 @@ system_call:   /* label this so stack 
traces look sane */
clrldi  r8,r8,32
 15:
slwir0,r0,4
+
+   barrier_nospec_asm
+   /*
+* Prevent the load of the handler below (based on the user-passed
+* system call number) being speculatively executed until the test
+* against NR_syscalls and branch to .Lsyscall_enosys above has
+* committed.
+*/
+
ldx r12,r11,r0  /* Fetch system call handler [ptr] */
mtctr   r12
bctrl   /* Call handler */
-- 
2.20.1



[PATCH stable v4.9 07/35] powerpc: Use barrier_nospec in copy_from_user()

2019-04-11 Thread Michael Ellerman
commit ddf35cf3764b5a182b178105f57515b42e2634f8 upstream.

Based on the x86 commit doing the same.

See commit 304ec1b05031 ("x86/uaccess: Use __uaccess_begin_nospec()
and uaccess_try_nospec") and b3bbfb3fb5d2 ("x86: Introduce
__uaccess_begin_nospec() and uaccess_try_nospec") for more detail.

In all cases we are ordering the load from the potentially
user-controlled pointer vs a previous branch based on an access_ok()
check or similar.

Base on a patch from Michal Suchanek.

Signed-off-by: Michal Suchanek 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/uaccess.h | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/uaccess.h 
b/arch/powerpc/include/asm/uaccess.h
index 31913b3ac7ab..da852153c1f8 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -269,6 +269,7 @@ do {
\
__chk_user_ptr(ptr);\
if (!is_kernel_addr((unsigned long)__gu_addr))  \
might_fault();  \
+   barrier_nospec();   \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err;   \
@@ -280,8 +281,10 @@ do {   
\
unsigned long  __gu_val = 0;\
__typeof__(*(ptr)) __user *__gu_addr = (ptr);   \
might_fault();  \
-   if (access_ok(VERIFY_READ, __gu_addr, (size)))  \
+   if (access_ok(VERIFY_READ, __gu_addr, (size))) {\
+   barrier_nospec();   \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
+   }   \
(x) = (__force __typeof__(*(ptr)))__gu_val; 
\
__gu_err;   \
 })
@@ -292,6 +295,7 @@ do {
\
unsigned long __gu_val; \
__typeof__(*(ptr)) __user *__gu_addr = (ptr);   \
__chk_user_ptr(ptr);\
+   barrier_nospec();   \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__force __typeof__(*(ptr)))__gu_val; \
__gu_err;   \
@@ -348,15 +352,19 @@ static inline unsigned long 
__copy_from_user_inatomic(void *to,
 
switch (n) {
case 1:
+   barrier_nospec();
__get_user_size(*(u8 *)to, from, 1, ret);
break;
case 2:
+   barrier_nospec();
__get_user_size(*(u16 *)to, from, 2, ret);
break;
case 4:
+   barrier_nospec();
__get_user_size(*(u32 *)to, from, 4, ret);
break;
case 8:
+   barrier_nospec();
__get_user_size(*(u64 *)to, from, 8, ret);
break;
}
@@ -366,6 +374,7 @@ static inline unsigned long __copy_from_user_inatomic(void 
*to,
 
check_object_size(to, n, false);
 
+   barrier_nospec();
return __copy_tofrom_user((__force void __user *)to, from, n);
 }
 
-- 
2.20.1



[PATCH stable v4.9 06/35] powerpc/64s: Enable barrier_nospec based on firmware settings

2019-04-11 Thread Michael Ellerman
From: Michal Suchanek 

commit cb3d6759a93c6d0aea1c10deb6d00e111c29c19c upstream.

Check what firmware told us and enable/disable the barrier_nospec as
appropriate.

We err on the side of enabling the barrier, as it's no-op on older
systems, see the comment for more detail.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/setup.h   |  1 +
 arch/powerpc/kernel/security.c | 60 ++
 arch/powerpc/platforms/powernv/setup.c |  1 +
 arch/powerpc/platforms/pseries/setup.c |  1 +
 4 files changed, 63 insertions(+)

diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index a225b5c42e76..84ae150ce6a6 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -51,6 +51,7 @@ enum l1d_flush_type {
 
 void setup_rfi_flush(enum l1d_flush_type, bool enable);
 void do_rfi_flush_fixups(enum l1d_flush_type types);
+void setup_barrier_nospec(void);
 void do_barrier_nospec_fixups(bool enable);
 extern bool barrier_nospec_enabled;
 
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 34d436fe2498..d0e974da4918 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -23,6 +24,65 @@ static void enable_barrier_nospec(bool enable)
do_barrier_nospec_fixups(enable);
 }
 
+void setup_barrier_nospec(void)
+{
+   bool enable;
+
+   /*
+* It would make sense to check SEC_FTR_SPEC_BAR_ORI31 below as well.
+* But there's a good reason not to. The two flags we check below are
+* both are enabled by default in the kernel, so if the hcall is not
+* functional they will be enabled.
+* On a system where the host firmware has been updated (so the ori
+* functions as a barrier), but on which the hypervisor (KVM/Qemu) has
+* not been updated, we would like to enable the barrier. Dropping the
+* check for SEC_FTR_SPEC_BAR_ORI31 achieves that. The only downside is
+* we potentially enable the barrier on systems where the host firmware
+* is not updated, but that's harmless as it's a no-op.
+*/
+   enable = security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) &&
+security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR);
+
+   enable_barrier_nospec(enable);
+}
+
+#ifdef CONFIG_DEBUG_FS
+static int barrier_nospec_set(void *data, u64 val)
+{
+   switch (val) {
+   case 0:
+   case 1:
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   if (!!val == !!barrier_nospec_enabled)
+   return 0;
+
+   enable_barrier_nospec(!!val);
+
+   return 0;
+}
+
+static int barrier_nospec_get(void *data, u64 *val)
+{
+   *val = barrier_nospec_enabled ? 1 : 0;
+   return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(fops_barrier_nospec,
+   barrier_nospec_get, barrier_nospec_set, "%llu\n");
+
+static __init int barrier_nospec_debugfs_init(void)
+{
+   debugfs_create_file("barrier_nospec", 0600, powerpc_debugfs_root, NULL,
+   _barrier_nospec);
+   return 0;
+}
+device_initcall(barrier_nospec_debugfs_init);
+#endif /* CONFIG_DEBUG_FS */
+
 ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, 
char *buf)
 {
bool thread_priv;
diff --git a/arch/powerpc/platforms/powernv/setup.c 
b/arch/powerpc/platforms/powernv/setup.c
index 17203abf38e8..eb5464648810 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -123,6 +123,7 @@ static void pnv_setup_rfi_flush(void)
  security_ftr_enabled(SEC_FTR_L1D_FLUSH_HV));
 
setup_rfi_flush(type, enable);
+   setup_barrier_nospec();
 }
 
 static void __init pnv_setup_arch(void)
diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index 91ade7755823..2b2759c98c7e 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -525,6 +525,7 @@ void pseries_setup_rfi_flush(void)
 security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR);
 
setup_rfi_flush(types, enable);
+   setup_barrier_nospec();
 }
 
 static void __init pSeries_setup_arch(void)
-- 
2.20.1



[PATCH stable v4.9 04/35] powerpc: Avoid code patching freed init sections

2019-04-11 Thread Michael Ellerman
From: Michael Neuling 

commit 51c3c62b58b357e8d35e4cc32f7b4ec907426fe3 upstream.

This stops us from doing code patching in init sections after they've
been freed.

In this chain:
  kvm_guest_init() ->
kvm_use_magic_page() ->
  fault_in_pages_readable() ->
 __get_user() ->
   __get_user_nocheck() ->
 barrier_nospec();

We have a code patching location at barrier_nospec() and
kvm_guest_init() is an init function. This whole chain gets inlined,
so when we free the init section (hence kvm_guest_init()), this code
goes away and hence should no longer be patched.

We seen this as userspace memory corruption when using a memory
checker while doing partition migration testing on powervm (this
starts the code patching post migration via
/sys/kernel/mobility/migration). In theory, it could also happen when
using /sys/kernel/debug/powerpc/barrier_nospec.

Cc: sta...@vger.kernel.org # 4.13+
Signed-off-by: Michael Neuling 
Reviewed-by: Nicholas Piggin 
Reviewed-by: Christophe Leroy 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/setup.h | 1 +
 arch/powerpc/lib/code-patching.c | 8 
 arch/powerpc/mm/mem.c| 2 ++
 3 files changed, 11 insertions(+)

diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 703ddf752516..709f4e739ae8 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -8,6 +8,7 @@ extern void ppc_printk_progress(char *s, unsigned short hex);
 
 extern unsigned int rtas_data;
 extern unsigned long long memory_limit;
+extern bool init_mem_is_free;
 extern unsigned long klimit;
 extern void *zalloc_maybe_bootmem(size_t size, gfp_t mask);
 
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 753d591f1b52..c77c486fbf24 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -14,12 +14,20 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 
 int patch_instruction(unsigned int *addr, unsigned int instr)
 {
int err;
 
+   /* Make sure we aren't patching a freed init section */
+   if (init_mem_is_free && init_section_contains(addr, 4)) {
+   pr_debug("Skipping init section patching addr: 0x%px\n", addr);
+   return 0;
+   }
+
__put_user_size(instr, addr, 4, err);
if (err)
return err;
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 5f844337de21..1e93dbc88e80 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -62,6 +62,7 @@
 #endif
 
 unsigned long long memory_limit;
+bool init_mem_is_free;
 
 #ifdef CONFIG_HIGHMEM
 pte_t *kmap_pte;
@@ -396,6 +397,7 @@ void __init mem_init(void)
 void free_initmem(void)
 {
ppc_md.progress = ppc_printk_progress;
+   init_mem_is_free = true;
free_initmem_default(POISON_FREE_INITMEM);
 }
 
-- 
2.20.1



[PATCH stable v4.9 05/35] powerpc/64s: Patch barrier_nospec in modules

2019-04-11 Thread Michael Ellerman
From: Michal Suchanek 

commit 815069ca57c142eb71d27439bc27f41a433a67b3 upstream.

Note that unlike RFI which is patched only in kernel the nospec state
reflects settings at the time the module was loaded.

Iterating all modules and re-patching every time the settings change
is not implemented.

Based on lwsync patching.

Signed-off-by: Michal Suchanek 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/setup.h  |  7 +++
 arch/powerpc/kernel/module.c  |  6 ++
 arch/powerpc/kernel/security.c|  2 +-
 arch/powerpc/lib/feature-fixups.c | 16 +---
 4 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 709f4e739ae8..a225b5c42e76 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -52,6 +52,13 @@ enum l1d_flush_type {
 void setup_rfi_flush(enum l1d_flush_type, bool enable);
 void do_rfi_flush_fixups(enum l1d_flush_type types);
 void do_barrier_nospec_fixups(bool enable);
+extern bool barrier_nospec_enabled;
+
+#ifdef CONFIG_PPC_BOOK3S_64
+void do_barrier_nospec_fixups_range(bool enable, void *start, void *end);
+#else
+static inline void do_barrier_nospec_fixups_range(bool enable, void *start, 
void *end) { };
+#endif
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index 30b89d5cbb03..d30f0626dcd0 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -72,6 +72,12 @@ int module_finalize(const Elf_Ehdr *hdr,
do_feature_fixups(powerpc_firmware_features,
  (void *)sect->sh_addr,
  (void *)sect->sh_addr + sect->sh_size);
+
+   sect = find_section(hdr, sechdrs, "__spec_barrier_fixup");
+   if (sect != NULL)
+   do_barrier_nospec_fixups_range(barrier_nospec_enabled,
+ (void *)sect->sh_addr,
+ (void *)sect->sh_addr + sect->sh_size);
 #endif
 
sect = find_section(hdr, sechdrs, "__lwsync_fixup");
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 8b1cf9c81b82..34d436fe2498 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -15,7 +15,7 @@
 
 unsigned long powerpc_security_features __read_mostly = SEC_FTR_DEFAULT;
 
-static bool barrier_nospec_enabled;
+bool barrier_nospec_enabled;
 
 static void enable_barrier_nospec(bool enable)
 {
diff --git a/arch/powerpc/lib/feature-fixups.c 
b/arch/powerpc/lib/feature-fixups.c
index f82ae6bb2365..a1222c441df5 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -278,14 +278,14 @@ void do_rfi_flush_fixups(enum l1d_flush_type types)
: "unknown");
 }
 
-void do_barrier_nospec_fixups(bool enable)
+void do_barrier_nospec_fixups_range(bool enable, void *fixup_start, void 
*fixup_end)
 {
unsigned int instr, *dest;
long *start, *end;
int i;
 
-   start = PTRRELOC(&__start___barrier_nospec_fixup),
-   end = PTRRELOC(&__stop___barrier_nospec_fixup);
+   start = fixup_start;
+   end = fixup_end;
 
instr = 0x6000; /* nop */
 
@@ -304,6 +304,16 @@ void do_barrier_nospec_fixups(bool enable)
printk(KERN_DEBUG "barrier-nospec: patched %d locations\n", i);
 }
 
+void do_barrier_nospec_fixups(bool enable)
+{
+   void *start, *end;
+
+   start = PTRRELOC(&__start___barrier_nospec_fixup),
+   end = PTRRELOC(&__stop___barrier_nospec_fixup);
+
+   do_barrier_nospec_fixups_range(enable, start, end);
+}
+
 #endif /* CONFIG_PPC_BOOK3S_64 */
 
 void do_lwsync_fixups(unsigned long value, void *fixup_start, void *fixup_end)
-- 
2.20.1



[PATCH stable v4.9 03/35] powerpc/64s: Add support for ori barrier_nospec patching

2019-04-11 Thread Michael Ellerman
From: Michal Suchanek 

commit 2eea7f067f495e33b8b116b35b5988ab2b8aec55 upstream.

Based on the RFI patching. This is required to be able to disable the
speculation barrier.

Only one barrier type is supported and it does nothing when the
firmware does not enable it. Also re-patching modules is not supported
So the only meaningful thing that can be done is patching out the
speculation barrier at boot when the user says it is not wanted.

Signed-off-by: Michal Suchanek 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/barrier.h|  2 +-
 arch/powerpc/include/asm/feature-fixups.h |  9 
 arch/powerpc/include/asm/setup.h  |  1 +
 arch/powerpc/kernel/security.c|  9 
 arch/powerpc/kernel/vmlinux.lds.S |  7 ++
 arch/powerpc/lib/feature-fixups.c | 27 +++
 6 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/barrier.h 
b/arch/powerpc/include/asm/barrier.h
index 352ea3e3cc05..a8131162104f 100644
--- a/arch/powerpc/include/asm/barrier.h
+++ b/arch/powerpc/include/asm/barrier.h
@@ -82,7 +82,7 @@ do {  
\
  * Prevent execution of subsequent instructions until preceding branches have
  * been fully resolved and are no longer executing speculatively.
  */
-#define barrier_nospec_asm ori 31,31,0
+#define barrier_nospec_asm NOSPEC_BARRIER_FIXUP_SECTION; nop
 
 // This also acts as a compiler barrier due to the memory clobber.
 #define barrier_nospec() asm (stringify_in_c(barrier_nospec_asm) ::: "memory")
diff --git a/arch/powerpc/include/asm/feature-fixups.h 
b/arch/powerpc/include/asm/feature-fixups.h
index 0bf8202feca6..afd3efd38938 100644
--- a/arch/powerpc/include/asm/feature-fixups.h
+++ b/arch/powerpc/include/asm/feature-fixups.h
@@ -213,6 +213,14 @@ void setup_feature_keys(void);
FTR_ENTRY_OFFSET 951b-952b; \
.popsection;
 
+#define NOSPEC_BARRIER_FIXUP_SECTION   \
+953:   \
+   .pushsection __barrier_nospec_fixup,"a";\
+   .align 2;   \
+954:   \
+   FTR_ENTRY_OFFSET 953b-954b; \
+   .popsection;
+
 
 #ifndef __ASSEMBLY__
 
@@ -220,6 +228,7 @@ extern long stf_barrier_fallback;
 extern long __start___stf_entry_barrier_fixup, 
__stop___stf_entry_barrier_fixup;
 extern long __start___stf_exit_barrier_fixup, __stop___stf_exit_barrier_fixup;
 extern long __start___rfi_flush_fixup, __stop___rfi_flush_fixup;
+extern long __start___barrier_nospec_fixup, __stop___barrier_nospec_fixup;
 
 #endif
 
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 3f160cd20107..703ddf752516 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -50,6 +50,7 @@ enum l1d_flush_type {
 
 void setup_rfi_flush(enum l1d_flush_type, bool enable);
 void do_rfi_flush_fixups(enum l1d_flush_type types);
+void do_barrier_nospec_fixups(bool enable);
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 2277df84ef6e..8b1cf9c81b82 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -10,10 +10,19 @@
 #include 
 
 #include 
+#include 
 
 
 unsigned long powerpc_security_features __read_mostly = SEC_FTR_DEFAULT;
 
+static bool barrier_nospec_enabled;
+
+static void enable_barrier_nospec(bool enable)
+{
+   barrier_nospec_enabled = enable;
+   do_barrier_nospec_fixups(enable);
+}
+
 ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, 
char *buf)
 {
bool thread_priv;
diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
b/arch/powerpc/kernel/vmlinux.lds.S
index c16fddbb6ab8..61def0be6914 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -153,6 +153,13 @@ SECTIONS
*(__rfi_flush_fixup)
__stop___rfi_flush_fixup = .;
}
+
+   . = ALIGN(8);
+   __spec_barrier_fixup : AT(ADDR(__spec_barrier_fixup) - LOAD_OFFSET) {
+   __start___barrier_nospec_fixup = .;
+   *(__barrier_nospec_fixup)
+   __stop___barrier_nospec_fixup = .;
+   }
 #endif
 
EXCEPTION_TABLE(0)
diff --git a/arch/powerpc/lib/feature-fixups.c 
b/arch/powerpc/lib/feature-fixups.c
index cf1398e3c2e0..f82ae6bb2365 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -277,6 +277,33 @@ void do_rfi_flush_fixups(enum l1d_flush_type types)
(types &  L1D_FLUSH_MTTRIG) ? "mttrig type"
: "unknown");
 }
+
+void do_barrier_nospec_fixups(bool enable)
+{
+   unsigned int instr, *dest;
+   long *start, *end;
+   int i;
+
+   start = 

[PATCH stable v4.9 02/35] powerpc/64s: Add barrier_nospec

2019-04-11 Thread Michael Ellerman
From: Michal Suchanek 

commit a6b3964ad71a61bb7c61d80a60bea7d42187b2eb upstream.

A no-op form of ori (or immediate of 0 into r31 and the result stored
in r31) has been re-tasked as a speculation barrier. The instruction
only acts as a barrier on newer machines with appropriate firmware
support. On older CPUs it remains a harmless no-op.

Implement barrier_nospec using this instruction.

mpe: The semantics of the instruction are believed to be that it
prevents execution of subsequent instructions until preceding branches
have been fully resolved and are no longer executing speculatively.
There is no further documentation available at this time.

Signed-off-by: Michal Suchanek 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/barrier.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/powerpc/include/asm/barrier.h 
b/arch/powerpc/include/asm/barrier.h
index 798ab37c9930..352ea3e3cc05 100644
--- a/arch/powerpc/include/asm/barrier.h
+++ b/arch/powerpc/include/asm/barrier.h
@@ -77,6 +77,21 @@ do { 
\
 
 #define smp_mb__before_spinlock()   smp_mb()
 
+#ifdef CONFIG_PPC_BOOK3S_64
+/*
+ * Prevent execution of subsequent instructions until preceding branches have
+ * been fully resolved and are no longer executing speculatively.
+ */
+#define barrier_nospec_asm ori 31,31,0
+
+// This also acts as a compiler barrier due to the memory clobber.
+#define barrier_nospec() asm (stringify_in_c(barrier_nospec_asm) ::: "memory")
+
+#else /* !CONFIG_PPC_BOOK3S_64 */
+#define barrier_nospec_asm
+#define barrier_nospec()
+#endif
+
 #include 
 
 #endif /* _ASM_POWERPC_BARRIER_H */
-- 
2.20.1



[PATCH stable v4.9 01/35] powerpc: Fix invalid use of register expressions

2019-04-11 Thread Michael Ellerman
From: Andreas Schwab 

commit 8a583c0a8d316d8ea52ea78491174ab1a3e9ef9d upstream.

binutils >= 2.26 now warns about misuse of register expressions in
assembler operands that are actually literals, for example:

  arch/powerpc/kernel/entry_64.S:535: Warning: invalid register expression

In practice these are almost all uses of r0 that should just be a
literal 0.

Signed-off-by: Andreas Schwab 
[mpe: Mention r0 is almost always the culprit, fold in purgatory change]
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/ppc_asm.h |  2 +-
 arch/powerpc/kernel/swsusp_asm64.S |  2 +-
 arch/powerpc/lib/copypage_power7.S | 14 +++
 arch/powerpc/lib/copyuser_power7.S | 66 +++---
 arch/powerpc/lib/memcpy_power7.S   | 66 +++---
 arch/powerpc/lib/string_64.S   |  2 +-
 6 files changed, 76 insertions(+), 76 deletions(-)

diff --git a/arch/powerpc/include/asm/ppc_asm.h 
b/arch/powerpc/include/asm/ppc_asm.h
index c73750b0d9fa..24e95be3bfaf 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -437,7 +437,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
 .machine push ;\
 .machine "power4" ;\
lis scratch,0x6000@h;   \
-   dcbtr0,scratch,0b01010; \
+   dcbt0,scratch,0b01010;  \
 .machine pop
 
 /*
diff --git a/arch/powerpc/kernel/swsusp_asm64.S 
b/arch/powerpc/kernel/swsusp_asm64.S
index 988f38dced0f..82d8aae81c6a 100644
--- a/arch/powerpc/kernel/swsusp_asm64.S
+++ b/arch/powerpc/kernel/swsusp_asm64.S
@@ -179,7 +179,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
sld r3, r3, r0
li  r0, 0
 1:
-   dcbfr0,r3
+   dcbf0,r3
addir3,r3,0x20
bdnz1b
 
diff --git a/arch/powerpc/lib/copypage_power7.S 
b/arch/powerpc/lib/copypage_power7.S
index a84d333ecb09..ca5fc8fa7efc 100644
--- a/arch/powerpc/lib/copypage_power7.S
+++ b/arch/powerpc/lib/copypage_power7.S
@@ -45,13 +45,13 @@ _GLOBAL(copypage_power7)
 .machine push
 .machine "power4"
/* setup read stream 0  */
-   dcbtr0,r4,0b01000   /* addr from */
-   dcbtr0,r7,0b01010   /* length and depth from */
+   dcbt0,r4,0b01000/* addr from */
+   dcbt0,r7,0b01010   /* length and depth from */
/* setup write stream 1 */
-   dcbtst  r0,r9,0b01000   /* addr to */
-   dcbtst  r0,r10,0b01010  /* length and depth to */
+   dcbtst  0,r9,0b01000   /* addr to */
+   dcbtst  0,r10,0b01010  /* length and depth to */
eieio
-   dcbtr0,r8,0b01010   /* all streams GO */
+   dcbt0,r8,0b01010/* all streams GO */
 .machine pop
 
 #ifdef CONFIG_ALTIVEC
@@ -83,7 +83,7 @@ _GLOBAL(copypage_power7)
li  r12,112
 
.align  5
-1: lvx v7,r0,r4
+1: lvx v7,0,r4
lvx v6,r4,r6
lvx v5,r4,r7
lvx v4,r4,r8
@@ -92,7 +92,7 @@ _GLOBAL(copypage_power7)
lvx v1,r4,r11
lvx v0,r4,r12
addir4,r4,128
-   stvxv7,r0,r3
+   stvxv7,0,r3
stvxv6,r3,r6
stvxv5,r3,r7
stvxv4,r3,r8
diff --git a/arch/powerpc/lib/copyuser_power7.S 
b/arch/powerpc/lib/copyuser_power7.S
index da0c568d18c4..391694814691 100644
--- a/arch/powerpc/lib/copyuser_power7.S
+++ b/arch/powerpc/lib/copyuser_power7.S
@@ -327,13 +327,13 @@ err1; stb r0,0(r3)
 .machine push
 .machine "power4"
/* setup read stream 0 */
-   dcbtr0,r6,0b01000   /* addr from */
-   dcbtr0,r7,0b01010   /* length and depth from */
+   dcbt0,r6,0b01000   /* addr from */
+   dcbt0,r7,0b01010   /* length and depth from */
/* setup write stream 1 */
-   dcbtst  r0,r9,0b01000   /* addr to */
-   dcbtst  r0,r10,0b01010  /* length and depth to */
+   dcbtst  0,r9,0b01000   /* addr to */
+   dcbtst  0,r10,0b01010  /* length and depth to */
eieio
-   dcbtr0,r8,0b01010   /* all streams GO */
+   dcbt0,r8,0b01010/* all streams GO */
 .machine pop
 
beq cr1,.Lunwind_stack_nonvmx_copy
@@ -388,26 +388,26 @@ err3; std r0,0(r3)
li  r11,48
 
bf  cr7*4+3,5f
-err3;  lvx v1,r0,r4
+err3;  lvx v1,0,r4
addir4,r4,16
-err3;  stvxv1,r0,r3
+err3;  stvxv1,0,r3
addir3,r3,16
 
 5: bf  cr7*4+2,6f
-err3;  lvx v1,r0,r4
+err3;  lvx v1,0,r4
 err3;  lvx v0,r4,r9
addir4,r4,32
-err3;  stvxv1,r0,r3
+err3;  stvxv1,0,r3
 err3;  stvxv0,r3,r9
addir3,r3,32
 
 6: bf  cr7*4+1,7f
-err3;  lvx v3,r0,r4
+err3;  lvx v3,0,r4
 err3;  lvx v2,r4,r9
 err3;  lvx v1,r4,r10
 err3;  lvx v0,r4,r11
addir4,r4,64
-err3;  stvxv3,r0,r3
+err3;  stvxv3,0,r3
 err3;  stvxv2,r3,r9
 err3;  stvxv1,r3,r10
 err3;  stvxv0,r3,r11
@@ -433,7 +433,7 @@ err3; 

[PATCH stable v4.9 00/35] powerpc spectre backports for 4.9

2019-04-11 Thread Michael Ellerman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Greg,

Please queue up these powerpc patches for 4.9 if you have no objections.

There's one build fix for newer toolchains, and the rest are spectre related.

cheers

Andreas Schwab (1):
  powerpc: Fix invalid use of register expressions

Christophe Leroy (1):
  powerpc/fsl: Fix the flush of branch predictor.

Diana Craciun (16):
  powerpc/64: Disable the speculation barrier from the command line
  powerpc/64: Make stf barrier PPC_BOOK3S_64 specific.
  powerpc/64: Make meltdown reporting Book3S 64 specific
  powerpc/fsl: Add barrier_nospec implementation for NXP PowerPC Book3E
  powerpc/fsl: Sanitize the syscall table for NXP PowerPC 32 bit
platforms
  powerpc/fsl: Add infrastructure to fixup branch predictor flush
  powerpc/fsl: Add macro to flush the branch predictor
  powerpc/fsl: Fix spectre_v2 mitigations reporting
  powerpc/fsl: Emulate SPRN_BUCSR register
  powerpc/fsl: Add nospectre_v2 command line argument
  powerpc/fsl: Flush the branch predictor at each kernel entry (64bit)
  powerpc/fsl: Flush the branch predictor at each kernel entry (32 bit)
  powerpc/fsl: Flush branch predictor when entering KVM
  powerpc/fsl: Enable runtime patching if nospectre_v2 boot arg is used
  powerpc/fsl: Update Spectre v2 reporting
  powerpc/fsl: Fixed warning: orphan section `__btb_flush_fixup'

Michael Ellerman (11):
  powerpc: Use barrier_nospec in copy_from_user()
  powerpc/64: Use barrier_nospec in syscall entry
  powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2
  powerpc/64: Add CONFIG_PPC_BARRIER_NOSPEC
  powerpc/64: Call setup_barrier_nospec() from setup_arch()
  powerpc/asm: Add a patch_site macro & helpers for patching
instructions
  powerpc/64s: Add new security feature flags for count cache flush
  powerpc/64s: Add support for software count cache flush
  powerpc/pseries: Query hypervisor for count cache flush settings
  powerpc/powernv: Query firmware for count cache flush settings
  powerpc/security: Fix spectre_v2 reporting

Michael Neuling (1):
  powerpc: Avoid code patching freed init sections

Michal Suchanek (5):
  powerpc/64s: Add barrier_nospec
  powerpc/64s: Add support for ori barrier_nospec patching
  powerpc/64s: Patch barrier_nospec in modules
  powerpc/64s: Enable barrier_nospec based on firmware settings
  powerpc/64s: Enhance the information in cpu_show_spectre_v1()

 arch/powerpc/Kconfig |   7 +-
 arch/powerpc/include/asm/asm-prototypes.h|   6 +
 arch/powerpc/include/asm/barrier.h   |  21 ++
 arch/powerpc/include/asm/code-patching-asm.h |  18 ++
 arch/powerpc/include/asm/code-patching.h |   2 +
 arch/powerpc/include/asm/feature-fixups.h|  21 ++
 arch/powerpc/include/asm/hvcall.h|   2 +
 arch/powerpc/include/asm/ppc_asm.h   |  23 +-
 arch/powerpc/include/asm/security_features.h |   7 +
 arch/powerpc/include/asm/setup.h |  21 ++
 arch/powerpc/include/asm/uaccess.h   |  11 +-
 arch/powerpc/kernel/Makefile |   3 +-
 arch/powerpc/kernel/entry_32.S   |  10 +
 arch/powerpc/kernel/entry_64.S   |  69 ++
 arch/powerpc/kernel/exceptions-64e.S |  27 ++-
 arch/powerpc/kernel/head_booke.h |  12 ++
 arch/powerpc/kernel/head_fsl_booke.S |  15 ++
 arch/powerpc/kernel/module.c |  10 +-
 arch/powerpc/kernel/security.c   | 216 ++-
 arch/powerpc/kernel/setup-common.c   |   3 +
 arch/powerpc/kernel/swsusp_asm64.S   |   2 +-
 arch/powerpc/kernel/vmlinux.lds.S|  19 +-
 arch/powerpc/kvm/bookehv_interrupts.S|   4 +
 arch/powerpc/kvm/e500_emulate.c  |   7 +
 arch/powerpc/lib/code-patching.c |  24 +++
 arch/powerpc/lib/copypage_power7.S   |  14 +-
 arch/powerpc/lib/copyuser_power7.S   |  66 +++---
 arch/powerpc/lib/feature-fixups.c|  93 
 arch/powerpc/lib/memcpy_power7.S |  66 +++---
 arch/powerpc/lib/string_64.S |   2 +-
 arch/powerpc/mm/mem.c|   2 +
 arch/powerpc/mm/tlb_low_64e.S|   7 +
 arch/powerpc/platforms/powernv/setup.c   |   7 +
 arch/powerpc/platforms/pseries/setup.c   |   7 +
 34 files changed, 733 insertions(+), 91 deletions(-)
 create mode 100644 arch/powerpc/include/asm/code-patching-asm.h

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 0a6bb48854e3..fa8f2aa88189 100644
- --- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -128,7 +128,7 @@ config PPC
select ARCH_HAS_GCOV_PROFILE_ALL
select GENERIC_SMP_IDLE_THREAD
select GENERIC_CMOS_UPDATE
- - select GENERIC_CPU_VULNERABILITIES  if PPC_BOOK3S_64
+   select GENERIC_CPU_VULNERABILITIES  if PPC_BARRIER_NOSPEC
select GENERIC_TIME_VSYSCALL_OLD
select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
@@ -164,6 

Re: [PATCH] MAINTAINERS: Update remaining @linux.vnet.ibm.com addresses

2019-04-11 Thread Joe Perches
On Thu, 2019-04-11 at 06:27 +0200, Lukas Bulwahn wrote:
> Paul McKenney attempted to update all email addresses @linux.vnet.ibm.com
> to @linux.ibm.com in commit 1dfddcdb95c4
> ("MAINTAINERS: Update from @linux.vnet.ibm.com to @linux.ibm.com"), but
> some still remained.
> 
> We update the remaining email addresses in MAINTAINERS, hopefully finally
> catching all cases for good.

Perhaps update all the similar addresses in other files too

$ git grep --name-only 'linux\.vnet\.ibm\.com' | wc -l
315



Re: [PATCH] MAINTAINERS: Update remaining @linux.vnet.ibm.com addresses

2019-04-11 Thread Paul E. McKenney
On Thu, Apr 11, 2019 at 06:27:52AM +0200, Lukas Bulwahn wrote:
> Paul McKenney attempted to update all email addresses @linux.vnet.ibm.com
> to @linux.ibm.com in commit 1dfddcdb95c4
> ("MAINTAINERS: Update from @linux.vnet.ibm.com to @linux.ibm.com"), but
> some still remained.
> 
> We update the remaining email addresses in MAINTAINERS, hopefully finally
> catching all cases for good.
> 
> Fixes: 1dfddcdb95c4 ("MAINTAINERS: Update from @linux.vnet.ibm.com to 
> @linux.ibm.com")
> Signed-off-by: Lukas Bulwahn 

For whatever it is worth:

Acked-by: Paul E. McKenney 

> ---
> 
> Tyrel, please take this patch. Thanks.
> 
>  MAINTAINERS | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2359e12e4c41..454b3cf36aa4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7439,14 +7439,14 @@ F:drivers/crypto/vmx/ghash*
>  F:   drivers/crypto/vmx/ppc-xlate.pl
>  
>  IBM Power PCI Hotplug Driver for RPA-compliant PPC64 platform
> -M:   Tyrel Datwyler 
> +M:   Tyrel Datwyler 
>  L:   linux-...@vger.kernel.org
>  L:   linuxppc-dev@lists.ozlabs.org
>  S:   Supported
>  F:   drivers/pci/hotplug/rpaphp*
>  
>  IBM Power IO DLPAR Driver for RPA-compliant PPC64 platform
> -M:   Tyrel Datwyler 
> +M:   Tyrel Datwyler 
>  L:   linux-...@vger.kernel.org
>  L:   linuxppc-dev@lists.ozlabs.org
>  S:   Supported
> @@ -10388,7 +10388,7 @@ F:arch/arm/mach-mmp/
>  
>  MMU GATHER AND TLB INVALIDATION
>  M:   Will Deacon 
> -M:   "Aneesh Kumar K.V" 
> +M:   "Aneesh Kumar K.V" 
>  M:   Andrew Morton 
>  M:   Nick Piggin 
>  M:   Peter Zijlstra 
> -- 
> 2.17.1
> 



Re: [PATCH V2 1/2] ASoC: fsl_asrc: replace the process_option table with function

2019-04-11 Thread Daniel Baluta
Hi Shengjiu,

Mostly looking good. See few comments inline:



> +/*
> + * Select the pre-processing and post-processing options
> + *
> + * Fsin: input sample rate
> + * Fsout: output sample rate
> + * pre_proc: return value for pre-processing option
> + * post_proc: return value for post-processing option
> + */
> +static int fsl_asrc_sel_proc(int Fsin, int Fsout, int *pre_proc, int 
> *post_proc)

Lets be naming consistent here: Fsin -> fs_in, Fsout -> fs_out.

> +{
> +   bool det_out_op2_cond;
> +   bool det_out_op0_cond;
> +
> +   /* Codition for selection of post-processing */
> +   det_out_op2_cond = (((Fsin * 15 > Fsout * 16) & (Fsout < 56000)) |
> +   ((Fsin > 56000) & (Fsout < 56000)));
Remove outer parenthesis. Also should here be a logical or (||)
instead of bitwise or (|)?
Same for && vs &.

> +   det_out_op0_cond = (Fsin * 23 < Fsout * 8);

Remove outer parenthesis.
> +
> +   /*
> +* unsupported case: Tsout>16.125*Tsin, and Tsout>8.125*Tsin.
> +* Tsout>16.125*Tsin -> Fsin * 8 > 129 * Fsout
> +* Tsout>8.125*Tsin  -> Fsin * 8 > 65 * Fsout
> +* Tsout>4.125*Tsin  -> Fsin * 8 > 33 * Fsout
> +* Tsout>1.875*Tsin  -> Fsin * 8 > 15 * Fsout
> +*/
> +   if (Fsin * 8 > 129 * Fsout)
> +   *pre_proc = 5;
> +   else if (Fsin * 8 > 65 * Fsout)
> +   *pre_proc = 4;
> +   else if (Fsin * 8 > 33 * Fsout)
> +   *pre_proc = 2;
> +   else if (Fsin * 8 > 15 * Fsout) {
> +   if (Fsin > 152000)
> +   *pre_proc = 2;
> +   else
> +   *pre_proc = 1;
> +   } else if (Fsin < 76000)
> +   *pre_proc = 0;
> +   else if (Fsin > 152000)
> +   *pre_proc = 2;
> +   else
> +   *pre_proc = 1;
> +
> +   if (det_out_op2_cond)
> +   *post_proc = 2;
> +   else if (det_out_op0_cond)
> +   *post_proc = 0;
> +   else
> +   *post_proc = 1;
> +
> +   /* unsupported options */
> +   if (*pre_proc == 4 || *pre_proc == 5)
> +   return -EINVAL;
> +
> +   return 0;
> +}
> +
>  /**
>   * Request ASRC pair
>   *
> @@ -239,8 +278,10 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair 
> *pair)
> u32 inrate, outrate, indiv, outdiv;
> u32 clk_index[2], div[2];
> int in, out, channels;
> +   int pre_proc, post_proc;
> struct clk *clk;
> bool ideal;
> +   int ret;
>
> if (!config) {
> pair_err("invalid pair config\n");
> @@ -289,6 +330,12 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair 
> *pair)
> return -EINVAL;
> }
>
> +   ret = fsl_asrc_sel_proc(inrate, outrate, _proc, _proc);
> +   if (ret) {
> +   pair_err("No supported pre-processing options\n");
> +   return ret;
> +   }
> +
> /* Validate input and output clock sources */
> clk_index[IN] = clk_map[IN][config->inclk];
> clk_index[OUT] = clk_map[OUT][config->outclk];
> @@ -380,8 +427,8 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair 
> *pair)
> /* Apply configurations for pre- and post-processing */
> regmap_update_bits(asrc_priv->regmap, REG_ASRCFG,
>ASRCFG_PREMODi_MASK(index) | 
> ASRCFG_POSTMODi_MASK(index),
> -  ASRCFG_PREMOD(index, process_option[in][out][0]) |
> -  ASRCFG_POSTMOD(index, process_option[in][out][1]));
> +  ASRCFG_PREMOD(index, pre_proc) |
> +  ASRCFG_POSTMOD(index, post_proc));
>
> return fsl_asrc_set_ideal_ratio(pair, inrate, outrate);
>  }
> --
> 1.9.1
>


Re: [PATCH] Linux: Define struct termios2 in under _GNU_SOURCE [BZ #10339]

2019-04-11 Thread Florian Weimer
* Adhemerval Zanella:

> This allows us to adjust the baud rates to non-standard values using termios
> interfaces without to resorting to add new headers and use a different API
> (ioctl).

How much symbol versioning will be required for this change?

> As Peter Anvin has indicated, he create a POC [1] with the aforementioned
> new interfaces.  It has not been rebased against master, more specially 
> against
> my termios refactor to simplify the multiple architecture header definitions,
> but I intend to use as a base.

Reference [1] is still missing. 8-(

Thanks,
Florian


Re: [PATCH] powerpc/security: Show powerpc_security_features in debugfs

2019-04-11 Thread Joel Stanley
On Tue, 9 Apr 2019 at 22:45, Michael Ellerman  wrote:
>
> This can be helpful for debugging problems with the security feature
> flags, especially on guests where the flags come from the hypervisor
> via an hcall and so can't be observed in the device tree.
>
> Signed-off-by: Michael Ellerman 

Reviewed-by: Joel Stanley 


> ---
>  arch/powerpc/kernel/security.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
> index b33bafb8fcea..d6ba696d0ed0 100644
> --- a/arch/powerpc/kernel/security.c
> +++ b/arch/powerpc/kernel/security.c
> @@ -104,6 +104,14 @@ static __init int barrier_nospec_debugfs_init(void)
> return 0;
>  }
>  device_initcall(barrier_nospec_debugfs_init);
> +
> +static __init int security_feature_debugfs_init(void)
> +{
> +   debugfs_create_x64("security_features", 0400, powerpc_debugfs_root,
> +  (u64 *)_security_features);
> +   return 0;
> +}
> +device_initcall(security_feature_debugfs_init);
>  #endif /* CONFIG_DEBUG_FS */
>
>  #ifdef CONFIG_PPC_FSL_BOOK3E
> --
> 2.20.1
>


Re: [PATCH v5 16/16] KVM: PPC: Book3S HV: XIVE: introduce a 'release' device operation

2019-04-11 Thread Paul Mackerras
On Wed, Apr 10, 2019 at 07:04:48PM +0200, Cédric Le Goater wrote:
> When a P9 sPAPR VM boots, the CAS negotiation process determines which
> interrupt mode to use (XICS legacy or XIVE native) and invokes a
> machine reset to activate the chosen mode.
> 
> To be able to switch from one mode to another, we introduce the
> capability to release a KVM device without destroying the VM. The KVM
> device interface is extended with a new 'release' operation which is
> called when the file descriptor of the device is closed.

Unfortunately, I think there is now a memory leak:

> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index ea2018ae1cd7..ea2619d5ca98 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2938,6 +2938,19 @@ static int kvm_device_release(struct inode *inode, 
> struct file *filp)
>   struct kvm_device *dev = filp->private_data;
>   struct kvm *kvm = dev->kvm;
>  
> + if (!dev)
> + return -ENODEV;
> +
> + if (dev->kvm != kvm)
> + return -EPERM;
> +
> + if (dev->ops->release) {
> + mutex_lock(>lock);
> + list_del(>vm_node);

Because the device is now no longer in the kvm->devices list,
kvm_destroy_devices() won't find it there and therefore won't call the
device's destroy method.  In fact now the device's destroy method will
never get called; I can't see how kvmppc_xive_free() or
kvmppc_xive_native_free() will ever get called.  Thus the memory for
the kvmppc_xive structs will never get freed as far as I can see.

We could fix that by freeing both of the kvm->arch.xive_devices
entries at VM destruction time.

If it is true that any device that has a release method will never see
its destroy method being called, then that needs to be documented
clearly somewhere.

Paul.


Re: [PATCH 1/6] mm: change locked_vm's type from unsigned long to atomic64_t

2019-04-11 Thread Mark Rutland
On Thu, Apr 11, 2019 at 02:22:23PM +1000, Alexey Kardashevskiy wrote:
> On 03/04/2019 07:41, Daniel Jordan wrote:

> > -   dev_dbg(dev, "[%d] RLIMIT_MEMLOCK %c%ld %ld/%ld%s\n", current->pid,
> > +   dev_dbg(dev, "[%d] RLIMIT_MEMLOCK %c%ld %lld/%lu%s\n", current->pid,
> > incr ? '+' : '-', npages << PAGE_SHIFT,
> > -   current->mm->locked_vm << PAGE_SHIFT, rlimit(RLIMIT_MEMLOCK),
> > -   ret ? "- exceeded" : "");
> > +   (s64)atomic64_read(>mm->locked_vm) << PAGE_SHIFT,
> > +   rlimit(RLIMIT_MEMLOCK), ret ? "- exceeded" : "");
> 
> 
> 
> atomic64_read() returns "long" which matches "%ld", why this change (and
> similar below)? You did not do this in the two pr_debug()s above anyway.

Unfortunately, architectures return inconsistent types for atomic64 ops.

Some return long (e..g. powerpc), some return long long (e.g. arc), and
some return s64 (e.g. x86).

I'm currently trying to clean things up so that all use s64 [1], but in
the mean time it's necessary for generic code use a cast or temporarly
variable to ensure a consistent type. Once that's cleaned up, we can
remove the redundant casts.

Thanks,
Mark.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=atomics/type-cleanup


[PATCH V2 2/2] ASoC: fsl_asrc: Unify the supported input and output rate

2019-04-11 Thread S.j. Wang
Unify the supported input and output rate, add the
12kHz/24kHz/128kHz to the support list

Signed-off-by: Shengjiu Wang 
---
 sound/soc/fsl/fsl_asrc.c | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 5857d383d962..44bcc4a7b23b 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -27,13 +27,14 @@
dev_dbg(_priv->pdev->dev, "Pair %c: " fmt, 'A' + index, 
##__VA_ARGS__)
 
 /* Corresponding to process_option */
-static int supported_input_rate[] = {
-   5512, 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000, 88200,
-   96000, 176400, 192000,
+static unsigned int supported_asrc_rate[] = {
+   5512, 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000,
+   64000, 88200, 96000, 128000, 176400, 192000,
 };
 
-static int supported_asrc_rate[] = {
-   8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000, 88200, 96000, 
176400, 192000,
+static struct snd_pcm_hw_constraint_list fsl_asrc_rate_constraints = {
+   .count = ARRAY_SIZE(supported_asrc_rate),
+   .list = supported_asrc_rate,
 };
 
 /**
@@ -305,11 +306,11 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair 
*pair)
ideal = config->inclk == INCLK_NONE;
 
/* Validate input and output sample rates */
-   for (in = 0; in < ARRAY_SIZE(supported_input_rate); in++)
-   if (inrate == supported_input_rate[in])
+   for (in = 0; in < ARRAY_SIZE(supported_asrc_rate); in++)
+   if (inrate == supported_asrc_rate[in])
break;
 
-   if (in == ARRAY_SIZE(supported_input_rate)) {
+   if (in == ARRAY_SIZE(supported_asrc_rate)) {
pair_err("unsupported input sample rate: %dHz\n", inrate);
return -EINVAL;
}
@@ -502,7 +503,9 @@ static int fsl_asrc_dai_startup(struct snd_pcm_substream 
*substream,
snd_pcm_hw_constraint_step(substream->runtime, 0,
   SNDRV_PCM_HW_PARAM_CHANNELS, 2);
 
-   return 0;
+
+   return snd_pcm_hw_constraint_list(substream->runtime, 0,
+   SNDRV_PCM_HW_PARAM_RATE, _asrc_rate_constraints);
 }
 
 static int fsl_asrc_dai_hw_params(struct snd_pcm_substream *substream,
@@ -626,14 +629,18 @@ static int fsl_asrc_dai_probe(struct snd_soc_dai *dai)
.stream_name = "ASRC-Playback",
.channels_min = 1,
.channels_max = 10,
-   .rates = FSL_ASRC_RATES,
+   .rate_min = 5512,
+   .rate_max = 192000,
+   .rates = SNDRV_PCM_RATE_KNOT,
.formats = FSL_ASRC_FORMATS,
},
.capture = {
.stream_name = "ASRC-Capture",
.channels_min = 1,
.channels_max = 10,
-   .rates = FSL_ASRC_RATES,
+   .rate_min = 5512,
+   .rate_max = 192000,
+   .rates = SNDRV_PCM_RATE_KNOT,
.formats = FSL_ASRC_FORMATS,
},
.ops = _asrc_dai_ops,
-- 
1.9.1



[PATCH V2 1/2] ASoC: fsl_asrc: replace the process_option table with function

2019-04-11 Thread S.j. Wang
When we want to support more sample rate, for example 12kHz/24kHz
we need update the process_option table, if we want to support more
sample rate next time, the table need to be updated again. which
is not flexible.

We got a function fsl_asrc_sel_proc to replace the table, which can
give the pre-processing and post-processing options according to
the sample rate.

Signed-off-by: Shengjiu Wang 
---
 sound/soc/fsl/fsl_asrc.c | 87 +---
 1 file changed, 67 insertions(+), 20 deletions(-)

diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 0b937924d2e4..5857d383d962 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -26,24 +26,6 @@
 #define pair_dbg(fmt, ...) \
dev_dbg(_priv->pdev->dev, "Pair %c: " fmt, 'A' + index, 
##__VA_ARGS__)
 
-/* Sample rates are aligned with that defined in pcm.h file */
-static const u8 process_option[][12][2] = {
-   /* 8kHz 11.025kHz 16kHz 22.05kHz 32kHz 44.1kHz 48kHz   64kHz   88.2kHz 
96kHz   176kHz  192kHz */
-   {{0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 
0}, {0, 0}, {0, 0}, {0, 0},},  /* 5512Hz */
-   {{0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 
0}, {0, 0}, {0, 0}, {0, 0},},  /* 8kHz */
-   {{0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 
0}, {0, 0}, {0, 0}, {0, 0},},  /* 11025Hz */
-   {{1, 2}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 
0}, {0, 0}, {0, 0}, {0, 0},},  /* 16kHz */
-   {{1, 2}, {1, 2}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 
0}, {0, 0}, {0, 0}, {0, 0},},  /* 22050Hz */
-   {{1, 2}, {2, 1}, {2, 1}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 
1}, {0, 0}, {0, 0}, {0, 0},},  /* 32kHz */
-   {{2, 2}, {2, 2}, {2, 1}, {2, 1}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 
1}, {0, 1}, {0, 0}, {0, 0},},  /* 44.1kHz */
-   {{2, 2}, {2, 2}, {2, 1}, {2, 1}, {0, 2}, {0, 2}, {0, 1}, {0, 1}, {0, 
1}, {0, 1}, {0, 0}, {0, 0},},  /* 48kHz */
-   {{2, 2}, {2, 2}, {2, 2}, {2, 1}, {1, 2}, {0, 2}, {0, 2}, {0, 1}, {0, 
1}, {0, 1}, {0, 1}, {0, 0},},  /* 64kHz */
-   {{2, 2}, {2, 2}, {2, 2}, {2, 2}, {1, 2}, {1, 2}, {1, 2}, {1, 1}, {1, 
1}, {1, 1}, {1, 1}, {1, 1},},  /* 88.2kHz */
-   {{2, 2}, {2, 2}, {2, 2}, {2, 2}, {1, 2}, {1, 2}, {1, 2}, {1, 1}, {1, 
1}, {1, 1}, {1, 1}, {1, 1},},  /* 96kHz */
-   {{2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 1}, {2, 
1}, {2, 1}, {2, 1}, {2, 1},},  /* 176kHz */
-   {{2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 1}, {2, 
1}, {2, 1}, {2, 1}, {2, 1},},  /* 192kHz */
-};
-
 /* Corresponding to process_option */
 static int supported_input_rate[] = {
5512, 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000, 88200,
@@ -79,6 +61,63 @@
 
 static unsigned char *clk_map[2];
 
+/*
+ * Select the pre-processing and post-processing options
+ *
+ * Fsin: input sample rate
+ * Fsout: output sample rate
+ * pre_proc: return value for pre-processing option
+ * post_proc: return value for post-processing option
+ */
+static int fsl_asrc_sel_proc(int Fsin, int Fsout, int *pre_proc, int 
*post_proc)
+{
+   bool det_out_op2_cond;
+   bool det_out_op0_cond;
+
+   /* Codition for selection of post-processing */
+   det_out_op2_cond = (((Fsin * 15 > Fsout * 16) & (Fsout < 56000)) |
+   ((Fsin > 56000) & (Fsout < 56000)));
+   det_out_op0_cond = (Fsin * 23 < Fsout * 8);
+
+   /*
+* unsupported case: Tsout>16.125*Tsin, and Tsout>8.125*Tsin.
+* Tsout>16.125*Tsin -> Fsin * 8 > 129 * Fsout
+* Tsout>8.125*Tsin  -> Fsin * 8 > 65 * Fsout
+* Tsout>4.125*Tsin  -> Fsin * 8 > 33 * Fsout
+* Tsout>1.875*Tsin  -> Fsin * 8 > 15 * Fsout
+*/
+   if (Fsin * 8 > 129 * Fsout)
+   *pre_proc = 5;
+   else if (Fsin * 8 > 65 * Fsout)
+   *pre_proc = 4;
+   else if (Fsin * 8 > 33 * Fsout)
+   *pre_proc = 2;
+   else if (Fsin * 8 > 15 * Fsout) {
+   if (Fsin > 152000)
+   *pre_proc = 2;
+   else
+   *pre_proc = 1;
+   } else if (Fsin < 76000)
+   *pre_proc = 0;
+   else if (Fsin > 152000)
+   *pre_proc = 2;
+   else
+   *pre_proc = 1;
+
+   if (det_out_op2_cond)
+   *post_proc = 2;
+   else if (det_out_op0_cond)
+   *post_proc = 0;
+   else
+   *post_proc = 1;
+
+   /* unsupported options */
+   if (*pre_proc == 4 || *pre_proc == 5)
+   return -EINVAL;
+
+   return 0;
+}
+
 /**
  * Request ASRC pair
  *
@@ -239,8 +278,10 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
u32 inrate, outrate, indiv, outdiv;
u32 clk_index[2], div[2];
int in, out, channels;
+   int pre_proc, post_proc;
struct 

[PATCH V2 0/2] Support more sample rate in asrc

2019-04-11 Thread S.j. Wang
Support more sample rate in asrc

Shengjiu Wang (2):
  ASoC: fsl_asrc: replace the process_option table with function
  ASoC: fsl_asrc: Unify the supported input and output rate

Changes in v2
- add more comments in code
- add commit "Unify the supported input and output rate"

 sound/soc/fsl/fsl_asrc.c | 116 ++-
 1 file changed, 85 insertions(+), 31 deletions(-)

-- 
1.9.1



[PATCH V5] ASoC: fsl_esai: Fix missing break in switch statement

2019-04-11 Thread S.j. Wang
case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be
independent of each other, so replace fall-through with break.

Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
Signed-off-by: Shengjiu Wang 
Acked-by: Nicolin Chen 
Cc: 
---
Changes in v5
- remove new line after Fixes

Changes in v4
- Add acked-by

Changes in v3
- Update subject line and cc stable

Changes in v2
- Fix "Fixes" tag

 sound/soc/fsl/fsl_esai.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 3623aa9a6f2e..15202a637197 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -251,7 +251,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai, 
int clk_id,
break;
case ESAI_HCKT_EXTAL:
ecr |= ESAI_ECR_ETI;
-   /* fall through */
+   break;
case ESAI_HCKR_EXTAL:
ecr |= ESAI_ECR_ERI;
break;
-- 
1.9.1



[PATCH] powerpc/lib: remove memcpy_flushcache redundant return

2019-04-11 Thread Li RongQing
Align it with other architectures and none of the callers has
been interested its return

Signed-off-by: Li RongQing 
---
 arch/powerpc/lib/pmem.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/powerpc/lib/pmem.c b/arch/powerpc/lib/pmem.c
index 53c018762e1c..a7a1b3fc6720 100644
--- a/arch/powerpc/lib/pmem.c
+++ b/arch/powerpc/lib/pmem.c
@@ -48,14 +48,12 @@ long __copy_from_user_flushcache(void *dest, const void 
__user *src,
return copied;
 }
 
-void *memcpy_flushcache(void *dest, const void *src, size_t size)
+void memcpy_flushcache(void *dest, const void *src, size_t size)
 {
unsigned long start = (unsigned long) dest;
 
memcpy(dest, src, size);
flush_inval_dcache_range(start, start + size);
-
-   return dest;
 }
 EXPORT_SYMBOL(memcpy_flushcache);
 
-- 
2.16.2



Backwards compatiblity for QorIQ FMAN LIODN entries

2019-04-11 Thread Hamish Martin
Hi Rob and Mark,

I am upgrading the kernel on a Freescale P2040 based system and have
struck an issue with LIODNs not being updated by uboot for an FMAN
ethernet port.

My system has an old uboot running which fails in its attempt to update
the fman rx port node with the required LIODN entry. This is because my
old uboot installation is looking for compatibility value "fsl,fman-
port-1g-rx" while the latest kernel defines the compatible value as
"fsl,fman-v2-port-rx" (see for
instance arch/powerpc/boot/dts/fsl/qoriq-fman-0-1g-3.dtsi).
Newer uboot looks for both values per this commit:
https://github.com/u-boot/u-boot/commit/97a8d010e029111e5711a45264a726b
edbeb24c4#diff-43243b910837283bb1d5d626f4d89d75

I am unable to update bootloaders for devices of this type in the field
so I am wondering if the correct approach is to adjust my DTS file
locally to add the compatible string my old uboot is searching for, or
if we should add this to the various qoriq-fman dtsi files in the
kernel to make this work in a nice backwards compatible way.

Let me know your opinion. I'm happy to work up a patch if you'd like to
make the change in the kernel, otherwise I'll handle it locally by
overriding the compatible string in my system's dts file.

Thanks,
Hamish M

[PATCH kernel v3] powerpc/powernv: Isolate NVLinks between GV100GL on Witherspoon

2019-04-11 Thread Alexey Kardashevskiy
The NVIDIA V100 SXM2 GPUs are connected to the CPU via PCIe links and
(on POWER9) NVLinks. In addition to that, GPUs themselves have direct
peer-to-peer NVLinks in groups of 2 to 4 GPUs with no buffers/latches
between GPUs.

Because of these interconnected NVLinks, the POWERNV platform puts such
interconnected GPUs to the same IOMMU group. However users want to pass
GPUs through individually which requires separate IOMMU groups.

Thankfully V100 GPUs implement an interface to disable arbitrary links
by programming link disabling mask via the GPU's BAR0. Once a link is
disabled, it only can be enabled after performing the secondary bus reset
(SBR) on the GPU. Since these GPUs do not advertise any other type of
reset, it is reset by the platform's SBR handler.

This adds an extra step to the POWERNV's SBR handler to block NVLinks to
GPUs which do not belong to the same group as the GPU being reset.

This adds a new "isolate_nvlink" kernel parameter to force GPU isolation;
when enabled, every GPU gets placed in its own IOMMU group. The new
parameter is off by default to preserve the existing behaviour.

Before isolating:
[nvdbg ~]$ nvidia-smi topo -m
GPU0GPU1GPU2CPU Affinity
GPU0 X  NV2 NV2 0-0
GPU1NV2  X  NV2 0-0
GPU2NV2 NV2  X  0-0

After isolating:
[nvdbg ~]$ nvidia-smi topo -m
GPU0GPU1GPU2CPU Affinity
GPU0 X  PHB PHB 0-0
GPU1PHB  X  PHB 0-0
GPU2PHB PHB  X  0-0

Where:
  X= Self
  PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically 
the CPU)
  NV#  = Connection traversing a bonded set of # NVLinks

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v3:
* added pci_err() for failed ioremap
* reworked commit log

v2:
* this is rework of [PATCH kernel RFC 0/2] vfio, powerpc/powernv: Isolate 
GV100GL
but this time it is contained in the powernv platform
---
 arch/powerpc/platforms/powernv/Makefile  |   2 +-
 arch/powerpc/platforms/powernv/pci.h |   1 +
 arch/powerpc/platforms/powernv/eeh-powernv.c |   1 +
 arch/powerpc/platforms/powernv/npu-dma.c |  24 +++-
 arch/powerpc/platforms/powernv/nvlinkgpu.c   | 137 +++
 5 files changed, 162 insertions(+), 3 deletions(-)
 create mode 100644 arch/powerpc/platforms/powernv/nvlinkgpu.c

diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index da2e99efbd04..60a10d3b36eb 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -6,7 +6,7 @@ obj-y   += opal-msglog.o opal-hmi.o 
opal-power.o opal-irqchip.o
 obj-y  += opal-kmsg.o opal-powercap.o opal-psr.o 
opal-sensor-groups.o
 
 obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
-obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o
+obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o nvlinkgpu.o
 obj-$(CONFIG_CXL_BASE) += pci-cxl.o
 obj-$(CONFIG_EEH)  += eeh-powernv.o
 obj-$(CONFIG_PPC_SCOM) += opal-xscom.o
diff --git a/arch/powerpc/platforms/powernv/pci.h 
b/arch/powerpc/platforms/powernv/pci.h
index 8e36da379252..9fd3f391482c 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -250,5 +250,6 @@ extern void pnv_pci_unlink_table_and_group(struct 
iommu_table *tbl,
 extern void pnv_pci_setup_iommu_table(struct iommu_table *tbl,
void *tce_mem, u64 tce_size,
u64 dma_offset, unsigned int page_shift);
+extern void pnv_try_isolate_nvidia_v100(struct pci_dev *gpdev);
 
 #endif /* __POWERNV_PCI_H */
diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c 
b/arch/powerpc/platforms/powernv/eeh-powernv.c
index f38078976c5d..464b097d9635 100644
--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
+++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
@@ -937,6 +937,7 @@ void pnv_pci_reset_secondary_bus(struct pci_dev *dev)
pnv_eeh_bridge_reset(dev, EEH_RESET_HOT);
pnv_eeh_bridge_reset(dev, EEH_RESET_DEACTIVATE);
}
+   pnv_try_isolate_nvidia_v100(dev);
 }
 
 static void pnv_eeh_wait_for_pending(struct pci_dn *pdn, const char *type,
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
b/arch/powerpc/platforms/powernv/npu-dma.c
index dc23d9d2a7d9..d4f9ee6222b5 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -22,6 +22,23 @@
 
 #include "pci.h"
 
+static bool isolate_nvlink;
+
+static int __init parse_isolate_nvlink(char *p)
+{
+   bool val;
+
+   if (!p)
+   val = true;
+   else if (kstrtobool(p, ))
+   return -EINVAL;
+
+   isolate_nvlink = val;
+
+   return 0;
+}
+early_param("isolate_nvlink", parse_isolate_nvlink);
+
 /*
  * spinlock to protect initialisation of an npu_context for a particular
  * mm_struct.
@@ -549,7 +566,7 @@ struct iommu_table_group 

Re: [alsa-devel] [PATCH V4] ASoC: fsl_esai: Fix missing break in switch statement

2019-04-11 Thread Daniel Baluta
Hi Shengjiu,

On Thu, Apr 11, 2019 at 6:06 AM S.j. Wang  wrote:
>
> case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be
> independent of each other, so replace fall-through with break.
>
> Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
>
Since it is obvious that you will need to send v5 please remove the new line
between Fixes and Signed-off-by. This is a common practice and some tools
might depend on this to parse the Fixes tag.

> Signed-off-by: Shengjiu Wang 
> Acked-by: Nicolin Chen 
> Cc: 


Re: [PATCH v5 16/16] KVM: PPC: Book3S HV: XIVE: introduce a 'release' device operation

2019-04-11 Thread Cédric Le Goater
On 4/11/19 6:38 AM, David Gibson wrote:
> On Thu, Apr 11, 2019 at 01:16:25PM +1000, Paul Mackerras wrote:
>> On Wed, Apr 10, 2019 at 07:04:48PM +0200, Cédric Le Goater wrote:
>>> When a P9 sPAPR VM boots, the CAS negotiation process determines which
>>> interrupt mode to use (XICS legacy or XIVE native) and invokes a
>>> machine reset to activate the chosen mode.
>>>
>>> To be able to switch from one mode to another, we introduce the
>>> capability to release a KVM device without destroying the VM. The KVM
>>> device interface is extended with a new 'release' operation which is
>>> called when the file descriptor of the device is closed.
>>
>> I believe the release operation is not called until all of the mmaps
>> using the fd are unmapped - which is a good thing for us, since it
>> means the guest can't possibly be accessing the XIVE directly.
yes.

>> You might want to reword that last paragraph to mention that.

ok. 

>>> Such operations are defined for the XICS-on-XIVE and the XIVE native
>>> KVM devices. They clear the vCPU interrupt presenters that could be
>>> attached and then destroy the device.
>>>
>>> This is not considered as a safe operation as the vCPUs are still
>>> running and could be referencing the KVM device through their
>>> presenters. To protect the system from any breakage, the kvmppc_xive
>>> objects representing both KVM devices are now stored in an array under
>>> the VM. Allocation is performed on first usage and memory is freed
>>> only when the VM exits.
>>
>> One quick comment below:
>>
>>> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
>>> index 480a3fc6b9fd..064a9f2ae678 100644
>>> --- a/arch/powerpc/kvm/book3s_xive.c
>>> +++ b/arch/powerpc/kvm/book3s_xive.c
>>> @@ -1100,11 +1100,19 @@ void kvmppc_xive_disable_vcpu_interrupts(struct 
>>> kvm_vcpu *vcpu)
>>>  void kvmppc_xive_cleanup_vcpu(struct kvm_vcpu *vcpu)
>>>  {
>>> struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
>>> -   struct kvmppc_xive *xive = xc->xive;
>>> +   struct kvmppc_xive *xive;
>>> int i;
>>>  
>>> +   if (!kvmppc_xics_enabled(vcpu))
>>> +   return;
>>
>> Should that be kvmppc_xive_enabled() rather than xics?
> 
> I think I asked that on an earlier iteration, and the answer is no.
> The names are confusing, but this file is all about xics-on-xive
> rather than xive native.  So here we're checking what's available from
> the guest's point of view, so "xics", but most of the surrounding
> functions are named "xive" because that's the backend.
> 

yes. 

The relevant part is at the end of the kvmppc_xive_connect_vcpu() routine :

  int kvmppc_xive_connect_vcpu(struct kvm_device *dev,
 struct kvm_vcpu *vcpu, u32 cpu)
  {
...
vcpu->arch.irq_type = KVMPPC_IRQ_XICS;
return 0;
  }



David suggested a few cleanups that we could do in the xics-on-xive 
device. We might want to introduce a KVMPPC_IRQ_XICS_ON_XIVE flag also. 
First, I would like to get rid of references to the kvmppc_xive struct 
and remove some useless attributes to improve locking.

Once the XIVE native mode is merged, all kernels above 4.14 running on 
a P9 sPAPR guest will switch to XIVE and the xics-on-xive device will 
only be useful for nested.


C.