Re: [PATCH 1/4] 44x/fsp2: add fsp2 headers

On Mon, 2017-11-27 at 15:58 +1100, Alistair Popple wrote: > Hi Ivan, > > Does it make sense to have these in a seperate include file? From what I could > see these defines were only used in fsp2.c so you could just put them directly > in there. Or at least have an fsp2.h next to fsp2.c rather

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

On Fri, 2017-11-24 at 17:37 +0100, christophe lombard wrote: > You are right. We will insert a checking in the cxl driver to allow > updating the TIDR if a P9 is present. This will be in the patch V2. > Thanks Best is to actually: 1) Add something to the device-tree in skiboot (and work with

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

On Fri, 2017-11-24 at 11:14 +0100, christophe lombard wrote: > To my knowledge, there is no property (or similar), somewhere, that > indicating that the TIDR is supported or not. > For the time being, if I am not wrong, the only check we have, is > this condition in the function

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

On Thu, 2017-11-23 at 12:05 +0100, Christophe Lombard wrote: > The POWER9 core supports a new feature: ASB_Notify which requires the > support of the Special Purpose Register: TIDR. > > The ASB_Notify command, generated by the AFU, will attempt to > wake-up the host thread identified by the

Re: [PATCH] powerpc/xive: store server for masked interrupt in kvmppc_xive_set_xive()

On Thu, 2017-11-23 at 10:06 +0100, Laurent Vivier wrote: > This is needed to map kvmppc_xive_set_xive() behavior > to kvmppc_xics_set_xive(). > > As we store the server, kvmppc_xive_get_xive() can return > the good value and we can also allow kvmppc_xive_int_on(). > > Signed-off-by: Laurent

[PATCH 2/2] powerpc: Reduce log level of "OPAL detected !" message

This message isn't terribly useful. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/platforms/powernv/opal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c

[PATCH 1/2] powerpc: Remove DEBUG define in 64-bit early setup code

This statement causes some not very useful messages to always be printed on the serial port at boot, even on quiet boots. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/kernel/setup_64.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/

Re: [PATCH v2] powerpc: fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX

On Tue, 2017-11-21 at 19:28 +0200, Meelis Roos wrote: > For wider powerpc audience: this warning-like INFO bit is present > independently of theis patch. Is it dangerous for some configuration? > > INFO: Uncompressed kernel (size 0x5d6c54) overlaps the address of the > wrapper(0x40) > INFO:

Re: [PATCH] ibmveth: Kernel crash LSO offload flag toggle

On Wed, 2017-11-15 at 10:45 -0600, Bryant G. Ly wrote: > This patch just closes the window, bad things can still happen. I wanted to > leave it > up to the people who actively develop in ibmveth to close the window, since > introducing > a lock can be expensive in tx. You don't need to

Re: [PATCH] ibmveth: Kernel crash LSO offload flag toggle

On Wed, 2017-11-15 at 13:47 +1100, Daniel Axtens wrote: > Hi Bryant, > > This looks a bit better, but... > > > The following patch ensures that the bounce_buffer is not null > > prior to using it within skb_copy_from_linear_data. > > How would this occur? > > Looking at ibmveth.c, I see

Re: [RFC PATCH kernel] powerpc/pci: Get rid of unused @parent pointer in pci_controller

On Mon, 2017-11-06 at 14:24 +1100, Alexey Kardashevskiy wrote: > The @parent pointer is supposed to point to a device which represents > a PCI controller, however it is never set to anything and remains NULL; > it is also quite common to pass NULL to pci_create_root_bus(). > > Signed-off-by:

[PATCH] powerpc/xive: Remove incorrect debug code

WORD2 if the TIMA isn't byte accessible and isn't that useful to know about, take out the pr_devel statement. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/sysdev/xive/common.c | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/powerpc/sysde

Re: [PATCH] powerpc/xmon: check before calling xive functions

On Thu, 2017-10-19 at 15:09 +0200, Cédric Le Goater wrote: > > No that's wrong. xive_enabled() is only set if Linux is using native > > xive mode but some of those xmon functions dump the emulated state. > > > > We should fix the actual cause of the crash. > > which should be in the OPAL XIVE

Re: [PATCH] powerpc/xmon: check before calling xive functions

On Thu, 2017-10-19 at 00:02 +1100, Michael Ellerman wrote: > Breno Leitao writes: > > > Currently xmon could call XIVE functions from OPAL even if the XIVE is > > disabled or does not exist in the system, as in POWER8 machines. This > > causes the following exception: > > >

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

On Fri, 2017-10-13 at 19:37 +1100, Michael Ellerman wrote: > > We recently had a situation in which i40e driver couldn't start, > > even after a full power cycle, due to a bug in its FW triggered > > by a DCB condition in switch (thanks Mauro for narrowing this). > > This patch enabled us to

Re: [PATCH 3/3] powerpc/tm: P9 disable transactionally suspended sigcontexts

On Fri, 2017-10-06 at 18:46 +1100, Cyril Bur wrote: > From: Michael Neuling > > Unfortunately userspace can construct a sigcontext which enables > suspend. Thus userspace can force Linux into a path where trechkpt is > executed. > > This patch blocks this from happening on

Re: [PATCH 2/3] powerpc/tm: P9 disabled suspend mode workaround

On Fri, 2017-10-06 at 18:46 +1100, Cyril Bur wrote: > [from Michael Neulings original patch] > Each POWER9 core is made of two super slices. Each super slice can > only have one thread at a time in TM suspend mode. The super slice > restricts ever entering a state where both threads are in suspend

Re: [PATCH 0/2] powerpc/xive: fix CPU hot unplug

On Tue, 2017-10-03 at 17:58 +1100, David Gibson wrote: > > Ok.. why do you think this isn't of use? I'm pretty sure this is > necessary for the TCG case, since MSR is checked in cpu_has_work(), > which could otherwise wake up the "dead" cpu. Ony if it's not in a PM state, in that case we check

Re: [PATCH 0/2] powerpc/xive: fix CPU hot unplug

On Mon, 2017-10-02 at 18:27 +0200, Cédric Le Goater wrote: > On 09/23/2017 10:26 AM, Cédric Le Goater wrote: > > Hi, > > > > Here are a couple of small fixes to support CPU hot unplug. There are > > still some issues to be investigated as, in some occasions, after a > > couple of plug and unplug,

Re: [PATCH] powernv: Add OCC driver to mmap sensor area

On Mon, 2017-10-02 at 14:14 +1100, Stewart Smith wrote: > Shilpasri G Bhat writes: > > This driver provides interface to mmap the OCC sensor area > > to userspace to parse and read OCC inband sensors. > > Why? > > Is this for debug? If so, the existing exports

Re: [PATCH 1/1] KVM: PPC: Book3S: Fix server always zero from kvmppc_xive_get_xive()

that approach seemed better. > > Paolo, again this is a pretty urgent fix for KVM on Power and Paulus > is away. We're hoping BenH will ack shortly (he's the logical > technical reviewer), after which can you merge this direct into the > KVM staging tree? (RHBZ 1477391, and we suspec

Re: [PATCH 1/2] powerpc/eeh: Create PHB PEs after EEH is initialized

On Wed, 2017-09-20 at 20:59 +1000, Michael Ellerman wrote: > Benjamin Herrenschmidt <b...@kernel.crashing.org> writes: > > > Otherwise we end up not yet having computed the right > > diag data size on powernv where EEH initialization > > is delayed, thus c

Re: [PATCH kernel] powerpc/powernv: Update comment about shifting IOV BAR

On Thu, 2017-09-14 at 09:27 +, David Laight wrote: > You can logically 'hotplug' PCI(e) on any system [1]. > > The 'problem' is that whatever enumerates the PCI(e) at system > powerup doesn't normally assign extra resources to bridges to allow > for devices that aren't present at boot time. >

Re: [PATCH 4/7] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages

On Fri, 2017-09-08 at 15:44 -0700, Ram Pai wrote: > The second part of the PTE will hold > (H_PAGE_F_SECOND|H_PAGE_F_GIX) at bit 60,61,62,63. > NOTE: None of the bits in the secondary PTE were not used > by 64k-HPTE backed PTE. Have you measured the performance impact of this ? The second part of

Re: [PATCH 02/25] powerpc: define an additional vma bit for protection keys.

On Thu, 2017-09-14 at 14:38 +1000, Balbir Singh wrote: > On Fri, 8 Sep 2017 15:44:50 -0700 > Ram Pai wrote: > > > powerpc needs an additional vma bit to support 32 keys. > > Till the additional vma bit lands in include/linux/mm.h > > we have to define it in powerpc

Re: [PATCH kernel] powerpc/powernv: Update comment about shifting IOV BAR

On Thu, 2017-09-14 at 13:18 +1000, Alexey Kardashevskiy wrote: > On 14/09/17 13:07, Benjamin Herrenschmidt wrote: > > On Thu, 2017-09-14 at 12:45 +1000, Alexey Kardashevskiy wrote: > > > On 31/08/17 13:34, Alexey Kardashevskiy wrote: > > > > From: Benjamin Herrensch

Re: [PATCH kernel] powerpc/powernv: Update comment about shifting IOV BAR

On Thu, 2017-09-14 at 12:45 +1000, Alexey Kardashevskiy wrote: > On 31/08/17 13:34, Alexey Kardashevskiy wrote: > > From: Benjamin Herrenschmidt <b...@kernel.crashing.org> > > Oops, this was not right :) > > Anyway, Ben, please comment. Thanks. This is incorrec

Re: [RFC PATCH 1/2] core: implement OPAL_SIGNAL_SYSTEM_RESET with POWER9 scoms

On Wed, 2017-09-13 at 23:27 +1000, Nicholas Piggin wrote: > On Wed, 13 Sep 2017 09:18:34 +1000 > Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > > > On Wed, 2017-09-13 at 02:05 +1000, Nicholas Piggin wrote: > > > This implements a way to raise sy

Re: [RFC PATCH 2/2] powerpc/powernv: implement NMI IPIs with OPAL_SIGNAL_SYSTEM_RESET

On Wed, 2017-09-13 at 23:13 +1000, Nicholas Piggin wrote: > On Wed, 13 Sep 2017 02:05:53 +1000 > Nicholas Piggin wrote: > > > There are two complications. The first is that sreset from stop states > > come in with SRR1 set to do a powersave wakeup, with an sreset reason > >

Re: [RFC PATCH 1/2] core: implement OPAL_SIGNAL_SYSTEM_RESET with POWER9 scoms

On Wed, 2017-09-13 at 02:05 +1000, Nicholas Piggin wrote: > This implements a way to raise system reset interrupts on other > cores. This has not yet been tested on DD2 or with deeper sleep > states. Reminds me, we need to workaround a bug with XSCOMs on P9 PSCOMs to core in the range

Re: [PATCH v2 3/9] powerpc/powernv: Remove real mode access limit for early allocations

On Tue, 2017-09-12 at 15:43 +0530, Aneesh Kumar K.V wrote: > Yes. I added the limit to radix after I observed that we have MSR[SF] = > 0. > > IIRC it was PACA access that was causing it to crash on return from RTAS. > > hmm the commit also explains that. > > powerpc/mm/radix: Limit paca

Re: [RFC PATCH 8/8] powerpc/64s/radix: Only flush local TLB for spurious fault flushes

On Fri, 2017-09-08 at 14:44 +1000, Nicholas Piggin wrote: > On Fri, 08 Sep 2017 08:05:38 +1000 > Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > > > On Fri, 2017-09-08 at 00:51 +1000, Nicholas Piggin wrote: > > > When permissiveness is relaxed,

Re: UIO memmap of PCi devices not working?

On Thu, 2017-09-07 at 10:19 +, Joakim Tjernlund wrote: > > Problem is that pci_mem_offset is gone, the closed I can find is mem_offset > > but that is an array,maybe just mem_offset[0] ? > > > > > I'm not sure exactly what's going > > > on in your case, if you have a problem can you add

Re: UIO memmap of PCi devices not working?

On Thu, 2017-09-07 at 08:59 +, Joakim Tjernlund wrote: > > > Hrm it's tricky, you shouldn't just turn that ifdef back on without > > also changing pci_resource_to_user(). > > There are two ifdef to change: > __pci_mmap_make_offset(): > #if 0 /* See comment in pci_resource_to_user() for why

Re: [RFC PATCH 8/8] powerpc/64s/radix: Only flush local TLB for spurious fault flushes

On Fri, 2017-09-08 at 00:51 +1000, Nicholas Piggin wrote: > When permissiveness is relaxed, or found to have been relaxed by > another thread, we flush that address out of the TLB to avoid a > future fault or micro-fault due to a stale TLB entry. > > Currently for processes with TLBs on other

Re: UIO memmap of PCi devices not working?

On Thu, 2017-09-07 at 07:22 +, Joakim Tjernlund wrote: > On Thu, 2017-09-07 at 17:16 +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2017-09-06 at 15:20 +, Joakim Tjernlund wrote: > > > Having problems to mmap PCI UIO devices and stumbeled over this

Re: [PATCH] powerpc/powernv: Increase memory block size to 1GB on radix

On Thu, 2017-09-07 at 15:17 +1000, Anton Blanchard wrote: > Hi, > > > There is a similar issue being worked on w.r.t pseries. > > > > https://lkml.kernel.org/r/1502357028-27465-1-git-send-email-bhar...@linux.vnet.ibm.com > > > > The question is should we map these regions ? ie, we need to tell

Re: UIO memmap of PCi devices not working?

On Wed, 2017-09-06 at 15:20 +, Joakim Tjernlund wrote: > Having problems to mmap PCI UIO devices and stumbeled over this page: > http://billfarrow.blogspot.se/2010/09/userspace-access-to-pci-memory.html > it claims some adjustments are needed for UIO mmap over PCI to work. > These are #if 0

[PATCH 2/2] powerpc/powernv: Rework EEH initialization on powernv

nly bails out of the PEs haven't been created yet and we force a re-probe where we used to call eeh_init() again. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/include/asm/eeh.h | 8 ++--- arch/powerpc/kernel/eeh.c

[PATCH 1/2] powerpc/eeh: Create PHB PEs after EEH is initialized

Otherwise we end up not yet having computed the right diag data size on powernv where EEH initialization is delayed, thus causing memory corruption later on when calling OPAL. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/kernel/eeh.c | 4

Re: [rfc 2/3] powerpc/mce: Extract physical_address for UE errors

On Tue, 2017-09-05 at 14:15 +1000, Balbir Singh wrote: > void save_mce_event(struct pt_regs *regs, long handled, > struct mce_error_info *mce_err, > - uint64_t nip, uint64_t addr) > + uint64_t nip, uint64_t addr, uint64_t phys_addr) > { >

[PATCH] powerpc/kvm/xive: Don't access TIMA using byte accesses

The TIMA only supports byte stores to the CPPR, for everything else, we need to do a 32-bit or 64-bit load. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> Fixes: 2c4fb78f78b6e420604ee1b05bdfb5c1d637869f --- arch/powerpc/kvm/book3s_hv_rm_xive.c| 1 - arch/power

[RFC/PATCH] powerpc/eeh: Create PHB PEs after EEH is initialized

Otherwise we end up not yet having computed the right diag data size on powernv where EEH initialization is delayed, thus causing memory corruption later on when calling OPAL. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- Russell, what do you think ? The end

Re: [PATCH] devicetree: Remove remaining references/tests for "chosen@0"

On Sun, 2017-09-03 at 06:43 -0400, Robert P. J. Day wrote: > however, given the diff stat of the change to remove every single > reference to that node name in the current kernel source: > > arch/microblaze/kernel/prom.c | 3 +-- > arch/mips/generic/yamon-dt.c | 4 >

Re: [PATCH] devicetree: Remove remaining references/tests for "chosen@0"

On Sat, 2017-09-02 at 04:43 -0400, Robert P. J. Day wrote: > Since, according to a recent devicetree ML posting by Rob Herring, > the node "/chosen@0" is most likely for real Open Firmware and does > not apply to DTSpec, remove all remaining tests and references for > that node, of which there are

Re: [PATCH 14/19] powerpc: Add ppc_strict_facility_enable boot option

On Thu, 2015-10-29 at 11:44 +1100, Anton Blanchard wrote: > > +extern void msr_check_and_set(unsigned long bits); > +extern bool strict_msr_control; > +extern void __msr_check_and_clear(unsigned long bits); > +static inline void msr_check_and_clear(unsigned long bits) > +{ > + if

Re: [PATCH 07/19] powerpc: Create mtmsrd_isync()

On Thu, 2015-10-29 at 11:43 +1100, Anton Blanchard wrote: > mtmsrd_isync() will do an mtmsrd followed by an isync on older > processors. On newer processors we avoid the isync via a feature fixup. The isync is needed specifically when enabling/disable FP etc... right ? I'd like to make the name

Re: [PATCH 03/19] powerpc: Create context switch helpers save_sprs() and restore_sprs()

On Thu, 2015-10-29 at 11:43 +1100, Anton Blanchard wrote: > Move all our context switch SPR save and restore code into two > helpers. We do a few optimisations: To avoid confusion with other places where we might save and restore SPRs for things like power management etc... can you name these

Re: [PATCH v3 6/8] powerpc/xive: introduce H_INT_ESB hcall

: Cédric Le Goater <c...@kaod.org> Acked-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- > arch/powerpc/include/asm/xive.h | 1 + > arch/powerpc/sysdev/xive/common.c| 10 ++-- > arch/powerpc/sysdev/xive/spapr.c | 44 > +++

Re: [PATCH v3 8/8] powerpc/xive: improve debugging macros

On Wed, 2017-08-30 at 21:46 +0200, Cédric Le Goater wrote: > Having the CPU identifier in the debug logs is helpful when tracking > issues. Also add some more logging and fix a compile issue in > xive_do_source_eoi(). > > Signed-off-by: Cédric Le Goater <c...@kaod.org>

Re: [PATCH v3 5/8] powerpc/xive: add the HW IRQ number under xive_irq_data

On Wed, 2017-08-30 at 21:46 +0200, Cédric Le Goater wrote: > It will be required later by the H_INT_ESB hcall. > > Signed-off-by: Cédric Le Goater <c...@kaod.org> Acked-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> A little but unfortunate as the number is avai

Re: [PATCH v3 4/8] powerpc/xive: introduce xive_esb_write()

> Reviewed-by: David Gibson <da...@gibson.dropbear.id.au> Acked-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > --- > arch/powerpc/sysdev/xive/common.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/sysdev/x

Re: [PATCH v3 3/8] powerpc/xive: rename xive_poke_esb() in xive_esb_read()

; > Signed-off-by: Cédric Le Goater <c...@kaod.org> > Reviewed-by: David Gibson <da...@gibson.dropbear.id.au> Acked-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > --- > > Changes since v1: > > - fixed naming. > > arch/powerpc/sysdev/xive/common.

Re: [PATCH v3 2/8] powerpc/xive: guest exploitation of the XIVE interrupt controller

> - "ibm,xive-eq-sizes" > >the size of the event queues. One cell per size supported, contains >log2 of size, in ascending order. > > - "ibm,xive-lisn-ranges" > >the interrupt numbers ranges assigned to the guest. These are >al

Re: [PATCH v3 1/8] powerpc/xive: introduce a common routine xive_queue_page_alloc()

On Wed, 2017-08-30 at 21:46 +0200, Cédric Le Goater wrote: > This routine will be used in the spapr backend. Also introduce a short > xive_alloc_order() helper. > > Signed-off-by: Cédric Le Goater <c...@kaod.org> > Reviewed-by: David Gibson <da...@gibson.dropbear.id

Re: [PATCH v2 1/3] powerpc/mm: Export flush_all_mm()

On Wed, 2017-08-30 at 15:59 +0200, Frederic Barrat wrote: > > It's not clear why it makes sense for these to be empty. Either for the > > general idea of the "flush_all_mm()" API, or for your intended use by > > CXL. > > I was not too sure what to do for hash, but the idea is that the new >

Re: [PATCH v2 1/3] powerpc/mm: Export flush_all_mm()

On Wed, 2017-08-30 at 23:17 +1000, Michael Ellerman wrote: > It's not clear why it makes sense for these to be empty. Either for the > general idea of the "flush_all_mm()" API, or for your intended use by > CXL. Indeed. On hash we don't have a way to flush a PID out of the TLB, but you can flush

Re: [PATCH V3 6/6] crypto/nx: Add P9 NX support for 842 compression engine

On Tue, 2017-08-29 at 14:54 -0700, Haren Myneni wrote: > Opening send window for each crypto transform (crypto_alloc, > compression/decompression, ..., crypto_free) so that does not have to > wait for the previous copy/paste complete. VAS will map send and > receive windows, and can cache in send

Re: Question: handling early hotplug interrupts

On Tue, 2017-08-29 at 17:43 -0300, Daniel Henrique Barboza wrote: > Hi, > > This is a scenario I've been facing when working in early device > hotplugs in QEMU. When a device is added, a IRQ pulse is fired to warn > the guest of the event, then the kernel fetches it by calling >

Re: [PATCH V3 6/6] crypto/nx: Add P9 NX support for 842 compression engine

On Tue, 2017-08-29 at 09:58 -0400, Dan Streetman wrote: > > + > > + ret = -EINVAL; > > + if (coproc && coproc->vas.rxwin) { > > + wmem->txwin = nx842_alloc_txwin(coproc); > > this is wrong. the workmem is scratch memory that's valid only for > the duration of a single

Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure

On Tue, 2017-08-29 at 13:27 +0200, Peter Zijlstra wrote: > mpe helped me out and explained that is the PWC hint to TBLIE. > > So, you set need_flush_all when you unhook pud/pmd/pte which you then > use to set PWC. So free_pgtables() will do the PWC when it unhooks > higher level pages. > > But

Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure

On Mon, 2017-08-28 at 11:37 +0200, Peter Zijlstra wrote: > > Doing all this job and just give up because we cannot allocate page tables > > looks very wasteful to me. > > > > Have you considered to look how we can hand over from speculative to > > non-speculative path without starting from

Re: [PATCH 2/2] cxl: Enable global TLBIs for cxl contexts

On Mon, 2017-08-28 at 19:37 +0200, Frederic Barrat wrote: > Good point, I had missed the change. It looks like I now need to call > radix__flush_all_mm(), which I would have to export outside of > tlb-radix.c first. > > Any problem with having a flush_all_mm() to complement a flush_tlb_mm()? >

Re: [PATCH 2/2] cxl: Enable global TLBIs for cxl contexts

On Mon, 2017-08-28 at 10:47 +0200, Frederic Barrat wrote: > > > Signed-off-by: Frederic Barrat > diff --git a/arch/powerpc/include/asm/mmu_context.h > b/arch/powerpc/include/asm/mmu_context.h > index 309592589e30..6447c0df7ec4 100644 > ---

Re: [PATCH] powerpc/mm/cxl: Add barrier when setting mm cpumask

On Mon, 2017-08-28 at 13:23 +0530, Aneesh Kumar K.V wrote: > Benjamin Herrenschmidt <b...@kernel.crashing.org> writes: > > > On Mon, 2017-08-28 at 11:55 +0530, Aneesh Kumar K.V wrote: > > > We need to add memory barrier so that the page table walk doesn't happen >

Re: [PATCH] powerpc/mm/cxl: Add barrier when setting mm cpumask

he fault handling cpu to mm cpumask") > Cc: Andrew Donnellan <andrew.donnel...@au1.ibm.com> > Reported-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > Reported-by: Dan Carpenter <dan.carpen...@oracle.com> > Signed-off-by: Aneesh Kumar K.V <aneesh.ku...@linux

Re: [PATCH] powerpc/44x: mask and shift to zero bug

cpc0_cr0 & 0x3e) >> 1) + 1; That rings a bell... Is this something we tried to fix before and had problems ? The thing is when I opened the 405GP and EP manual PDF, evince had memorized that this register was the last page I looked at :-) And I don't remember how many years ago that is. According to the 405gp spec ppdv is IBM bits 17,18 so your patch is correct. Acked-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>

Re: [PATCH 5/6] powerpc/mm: Optimize detection of thread local mm's

On Fri, 2017-08-25 at 06:53 +0200, Frederic Barrat wrote: > > Le 24/08/2017 à 20:47, Benjamin Herrenschmidt a écrit : > > On Thu, 2017-08-24 at 18:40 +0200, Frederic Barrat wrote: > > > > > > The decrementing part is giving me troubles, and I think it mak

Re: [PATCH 5/6] powerpc/mm: Optimize detection of thread local mm's

On Thu, 2017-08-24 at 18:40 +0200, Frederic Barrat wrote: > > The decrementing part is giving me troubles, and I think it makes sense: > if I decrement the counter when detaching the context from the capi > card, then the next TLBIs for the memory context may be back to local. Yes, you need

Re: [PATCH 5/6] powerpc/mm: Optimize detection of thread local mm's

On Tue, 2017-08-22 at 15:18 +0200, Frederic Barrat wrote: > > Or you could just incrementer my counter. Just make sure you increment > > it at most once per CXL context and decrement when the context is gone. > > Ah great, I didn't dare messing with your counter, it makes it easier. > Arguably

Re: [v3,3/3] powerpc/mm/cxl: Add the fault handling cpu to mm cpumask

On Mon, 2017-08-21 at 23:39 +1000, Michael Ellerman wrote: > On Thu, 2017-07-27 at 06:24:55 UTC, "Aneesh Kumar K.V" wrote: > > We use mm cpumask for serializing against lockless page table walk. Anybody > > who is doing a lockless page table walk is expected to disable irq and only > > cpus in mm

Re: [PATCH 5/6] powerpc/mm: Optimize detection of thread local mm's

On Mon, 2017-08-21 at 19:27 +0200, Frederic Barrat wrote: > Hi Ben, > > Le 24/07/2017 à 06:28, Benjamin Herrenschmidt a écrit : > > Instead of comparing the whole CPU mask every time, let's > > keep a counter of how many bits are set in the mask. Thus > > testing f

Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

On Sat, 2017-08-19 at 10:47 -0500, Bjorn Helgaas wrote: > So if ARM64 doesn't have these PCI legacy resources, does that mean an > ARM64 host bridge cannot generate these legacy addresses on PCI? That > is, there's no host bridge window that maps to those PCI addresses? > That seems like a

Re: [RFC v7 24/25] powerpc: Deliver SEGV signal on pkey violation

On Fri, 2017-08-18 at 15:49 -0700, Ram Pai wrote: > Coming back to the your main question, "why we need to provide the > contents of AMR register to the signal handler?" -- the only reason > i can see is, probably tools like gdb and ptrace may find it useful. > > And since it was suggested that

Re: [RFC v7 24/25] powerpc: Deliver SEGV signal on pkey violation

On Fri, 2017-08-18 at 10:04 -0700, Ram Pai wrote: > Assume two threads of a task. > > T1: mprotect_key(foo, PAGE_SIZE, pkey=4); > T1: set AMR to disable access for pkey 4; > T1: key fault > T2: set AMR to enable access to pkey 4; > T1: fault handler called. > This fault handler

[PATCH 2/2] kvm/xive: Add missing barriers and document them

This adds missing memory barriers to order updates/tests of the virtual CPPR and MFRR, thus fixing a lost IPI problem. While at it also document all barriers in this file This fixes a bug causing guest IPIs to occasionally get lost. Signed-off-by: Benjamin Herrenschmidt &l

[PATCH 1/2] kvm/xive: Workaround P9 DD1.0 bug with IPB bit loss

Thankfully it only happens when manually manipulating CPPR which is rather quite rare. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/kvm/book3s_xive_template.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/power

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

On Wed, 2017-08-16 at 10:56 -0600, Alex Williamson wrote: > > > WTF Alex, can you stop once and for all with all that "POWER is > > not standard" bullshit please ? It's completely wrong. > > As you've stated, the MSI-X vector table on POWER is currently updated > via a hypercall. POWER is

[PATCH 5/5] powerpc: Remove more redundant VSX save/tests

__giveup_vsx/save_vsx are completely equivalent to testing MSR_FP and MSR_VEC and calling the corresponding giveup/save function so just remove the spurious VSX cases. Also add WARN_ONs checking that we never have VSX enabled without the two other. Signed-off-by: Benjamin Herrenschmidt &l

[PATCH 2/5] powerpc: Fix missing CR before {

Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/kernel/process.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c index 883216b4296a..14b9a3c46c5d 100644 --- a/arch/powerpc/

Re: [PATCH 1/5] powerpc: Test MSR_FP and MSR_VEC when enabling/flushing VSX

On Wed, 2017-08-16 at 16:01 +1000, Benjamin Herrenschmidt wrote: > VSX uses a combination of the old vector registers, the old FP registers > and new "second halves" of the FP registers. > > Thus when we need to see the VSX state in the thread struct > (flush_vsx_to_

[PATCH 1/5] powerpc: Test MSR_FP and MSR_VEC when enabling/flushing VSX

ey are all flushed into the thread struct if either of them is individually enabled. Unfortunately we only tested if the whole VSX was enabled, not if they were individually enabled. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/kernel/process.c | 5 +++-- 1

[PATCH 3/5] powerpc: Remove redundant fp/altivec giveup code

__giveup_vsx already calls those two functions Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/kernel/process.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c index 14b9a3c46c5d..bfbd60

[PATCH 4/5] powerpc: Remove redundant clear of MSR_VSX in __giveup_vsx()

__giveup_fpu() already does it and we cannot have MSR_VSX set without having MSR_FP also set. This also adds a warning to check we indeed do Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/kernel/process.c | 14 +++--- 1 file changed, 11 inse

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

On Tue, 2017-08-15 at 10:37 -0600, Alex Williamson wrote: > Of course I don't think either of those are worth imposing a > performance penalty where we don't otherwise need one. However, if we > look at a VM scenario where the guest is following the PCI standard for > programming MSI-X interrupts

Re: [PATCH v2 3/9] powerpc/powernv: Remove real mode access limit for early allocations

On Tue, 2017-08-15 at 22:10 +1000, Nicholas Piggin wrote: > On Mon, 14 Aug 2017 23:13:07 +1000 > Benjamin Herrenschmidt <b...@au1.ibm.com> wrote: > > > On Mon, 2017-08-14 at 22:49 +1000, Michael Ellerman wrote: > > > > - /* > > > >

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

On Mon, 2017-08-14 at 14:12 +0100, Robin Murphy wrote: > On the other hand, if the check is not so much to mitigate malicious > guests attacking the system as to prevent dumb guests breaking > themselves (e.g. if some or all of the MSI-X capability is actually > emulated), then allowing things to

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

On Tue, 2017-08-15 at 09:47 +0800, Jike Song wrote: > On 08/15/2017 09:33 AM, Benjamin Herrenschmidt wrote: > > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: > > > > Taking a step back, though, why does vfio-pci perform this check in the > > > > first place?

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote: > > Taking a step back, though, why does vfio-pci perform this check in the > > first place? If a malicious guest already has control of a device, any > > kind of interrupt spoofing it could do by fiddling with the MSI-X > > message address/data

Re: [PATCH v6 14/17] powerpc: Add support for setting SPRN_TIDR

On Mon, 2017-08-14 at 13:03 -0700, Sukadev Bhattiprolu wrote: > As Ben pointed out, we are going to be have limit the number of TIDs (to > be within the size limits), so we won't be able to use task_pid_nr()? But > if we assign the TIDs in the RX_WIN_OPEN ioctl, then only the FTW processes > will

Re: [PATCH v6 14/17] powerpc: Add support for setting SPRN_TIDR

On Mon, 2017-08-14 at 21:16 +1000, Michael Ellerman wrote: > Sukadev Bhattiprolu writes: > > > We need the SPRN_TIDR to bet set for use with fast thread-wakeup > > (core-to-core wakeup). Each thread in a process needs to have a > > unique id within the process but as

Re: [PATCH v6 14/17] powerpc: Add support for setting SPRN_TIDR

On Mon, 2017-08-14 at 17:02 +1000, Michael Neuling wrote: > > +/* > > + * We need to assign an unique thread id to each thread in a process. This > > + * thread id is intended to be used with the Fast Thread-wakeup (aka Core- > > + * to-core wakeup) mechanism being implemented on top of Virtual >

Re: [PATCH v2 3/9] powerpc/powernv: Remove real mode access limit for early allocations

On Mon, 2017-08-14 at 22:49 +1000, Michael Ellerman wrote: > > - /* > > - * We limit the allocation that depend on ppc64_rma_size > > - * to first_memblock_size. We also clamp it to 1GB to > > - * avoid some funky things such as RTAS bugs. > > That comment about RTAS is 7 years

Re: [PATCH v2 3/9] powerpc/powernv: Remove real mode access limit for early allocations

On Mon, 2017-08-14 at 22:49 +1000, Michael Ellerman wrote: > Nicholas Piggin writes: > > > This removes the RMA limit on powernv platform, which constrains > > early allocations such as PACAs and stacks. There are still other > > restrictions that must be followed, such as

Re: [PATCH 3/6] powerpc/mm: Ensure cpumask update is ordered

On Fri, 2017-08-11 at 21:06 +1000, Nicholas Piggin wrote: > Other than that your series seems good to me if you repost it you > can add > > Reviewed-by: Nicholas Piggin > > This one out of the series is the bugfix so it should go to stable > as well, right? Yup. Ben.

Re: [PATCH 02/10] powerpc/xive: guest exploitation of the XIVE interrupt controller

On Thu, 2017-08-10 at 09:19 +0200, Cédric Le Goater wrote: > > > > > + /* Perform the acknowledge hypervisor to register cycle */ > > > > > + ack = be16_to_cpu(__raw_readw(xive_tima + TM_SPC_ACK_OS_REG)); > > > > > > > > Why do you need the raw_readw() + be16_to_cpu + mb, rather than one of > >

Re: [PATCH 02/10] powerpc/xive: guest exploitation of the XIVE interrupt controller

On Thu, 2017-08-10 at 08:45 +0200, Cédric Le Goater wrote: > > The problem with doorbells on POWER9 guests is that they may have > > to trap and be emulated by the hypervisor, since the guest threads > > on P9 don't have to match the HW threads of the core. > > Well, the pseries cause_ipi()

Re: [PATCH 02/10] powerpc/xive: guest exploitation of the XIVE interrupt controller

On Thu, 2017-08-10 at 14:28 +1000, David Gibson wrote: > > Also, will POWER9 always have doorbells? In which case you could > reduce it to 3 options. The problem with doorbells on POWER9 guests is that they may have to trap and be emulated by the hypervisor, since the guest threads on P9 don't

Re: [PATCH] powerpc: xive: ensure active irqd when setting affinity

On Wed, 2017-08-09 at 16:15 +1000, Michael Ellerman wrote: > I'm not sure I'm convinced. We can't handle every possible case of the > higher level code calling us in situations we don't expect. > > For example irq_data could be NULL, but we trust the higher level code > not to do that to us. > >

Re: [PATCH 10/10] powerpc/xive: fix the size of the cpumask used in xive_find_target_in_mask()

On Wed, 2017-08-09 at 17:06 +1000, Michael Ellerman wrote: > /** >* cpumask_weight - Count of bits in *srcp >* @srcp: the cpumask to count bits (< nr_cpu_ids) in. >*/ > static inline unsigned int cpumask_weight(const struct cpumask *srcp) > { > return

<    1   2   3   4   5   6   7   8   9   10   >