Hi Aneesh,
Some comments ...
"Aneesh Kumar K.V" writes:
> For address above 512TB we allocate additional mmu context. To make it all
> easy address above 512TB is handled with IR/DR=1 and with stack frame setup.
>
> We do the additional context allocation in SLB miss handler. If the context is
>
Hi all,
These warnings have beeen around for a while now;
drivers/macintosh/rack-meter.c:157:2: warning: 'memset' used with length equal
to number of elements without multiplication by element size [-Wmemset-elt-size]
memset(rdma->buf1, 0, ARRAY_SIZE(rdma->buf1));
^~
drivers/macintosh/ra
On Thu, 15 Mar 2018 20:15:52 +0100
Michal Suchanek wrote:
> On powerpc syscall entry is done in assembly so patch in an explicit
> barrier_nospec.
Same comment as Linus for this -- the barriers are before the branch here,
so is it possible the branch instruction can be speculative while the inde
On Wed, 2018-03-14 at 17:58 +0100, Frederic Barrat wrote:
> + if (irq == hw_irq) {
> + cur &= 1 << 31;
> + cur |= XIVE_BAD_IRQ;
> + *(q->qpage + idx) = cpu_to_be32(cur);
> +
On Wed, 2018-03-14 at 18:47 +0100, Cédric Le Goater wrote:
> We could also loop on the ESB 'P' bit to wait for the irqs to be handled,
> using :
>
> xive_esb_read(irq, XIVE_ESB_GET)
>
> which has no side effect. It looks simpler to me. Is that possible ?
But you can race with something
On Thu, Mar 15, 2018 at 12:15 PM, Michal Suchanek wrote:
> This is based on x86 patch doing the same.
>
> Signed-off-by: Michal Suchanek
> ---
> --- a/arch/powerpc/include/asm/uaccess.h
> +++ b/arch/powerpc/include/asm/uaccess.h
> @@ -258,8 +259,10 @@ do {
On 03/14/2018 07:40 PM, Mauricio Faria de Oliveira wrote:
> From: Michael Ellerman
>
> rfi_flush_enable() includes a check to see if we're already
> enabled (or disabled), and in that case does nothing.
>
> But that means calling setup_rfi_flush() a 2nd time doesn't actually
> work, which is a b
Adapted from the RFI implementation
Signed-off-by: Michal Suchanek
---
arch/powerpc/platforms/pseries/mobility.c | 2 +-
arch/powerpc/platforms/pseries/pseries.h | 2 +-
arch/powerpc/platforms/pseries/setup.c| 37 ++-
3 files changed, 29 insertions(+), 12 delet
Add commandline options spectre_v2 and nospectre_v2
These are named same as similar x86 options regardless of actual effect
to not require platform-specific configuration.
Supported options:
nospectre_v2 or spectre_v2=off - speculation barrier not used
spectre_v2=on or spectre_v2=auto - speculati
Copypasta from rfi implementation
Signed-off-by: Michal Suchanek
---
arch/powerpc/kernel/setup_64.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index f60e0e3b5ad2..f6678a7b6114 100644
---
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 specul
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
---
arch/powerpc/include/
The RFI flush support patches the speculation barrier into
RFI_FLUSH_SLOT as part of the RFI flush. Use separate barrier_nospec
instead.
Signed-off-by: Michal Suchanek
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/lib/feature-fixups.c| 9 +++--
2 files changed, 4
This is based on x86 patch doing the same.
Signed-off-by: Michal Suchanek
---
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 51bfeb8777f0..af9b0e731f
On powerpc syscall entry is done in assembly so patch in an explicit
barrier_nospec.
Signed-off-by: Michal Suchanek
---
arch/powerpc/kernel/entry_64.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 2cb5109a7ea3..7bfc4c
When the firmware supports it an otherwise useless combination of ORI
instruction arguments is interpreted as speculation barrier. Implement
barrier_nospec using this instruction.
Based on the out-of-tree gmb() implementation.
Signed-off-by: Michal Suchanek
---
arch/powerpc/include/asm/barrier.
Yes, it is good idea to add some commit messages.
Also I rebased the patches on top v3 of series
Setup RFI flush after PowerVM LPM migration
Thanks
Michal
Michal Suchanek (9):
powerpc: Add barrier_nospec
powerpc: Use barrier_nospec in copy_from_user
powerpc/64: Use barrier_nospec in sysc
Joe Perches writes:
> On Thu, 2018-03-15 at 14:57 +0300, Dan Carpenter wrote:
>> On Wed, Mar 14, 2018 at 06:22:07PM -0300, Thiago Jung Bauermann wrote:
>> >
>> > SF Markus Elfring writes:
>> >
>> > > From: Markus Elfring
>> > > Date: Sun, 11 Mar 2018 09:03:42 +0100
>> > >
>> > > Add a jump
On Thu, Mar 15, 2018 at 10:31:51AM -0700, Dave Hansen wrote:
> On 03/15/2018 10:21 AM, Ram Pai wrote:
> > On Thu, Mar 15, 2018 at 08:55:31AM -0700, Dave Hansen wrote:
> >> On 03/15/2018 02:46 AM, Thomas Gleixner wrote:
> +if (!pkey || !mm_pkey_is_allocated(mm, pkey))
> >>> Why this ext
On 03/15/2018 10:21 AM, Ram Pai wrote:
> On Thu, Mar 15, 2018 at 08:55:31AM -0700, Dave Hansen wrote:
>> On 03/15/2018 02:46 AM, Thomas Gleixner wrote:
+ if (!pkey || !mm_pkey_is_allocated(mm, pkey))
>>> Why this extra check? mm_pkey_is_allocated(mm, 0) should not return true
>>> ever. If it
On Thu, Mar 15, 2018 at 08:55:31AM -0700, Dave Hansen wrote:
> On 03/15/2018 02:46 AM, Thomas Gleixner wrote:
> >> + if (!pkey || !mm_pkey_is_allocated(mm, pkey))
> > Why this extra check? mm_pkey_is_allocated(mm, 0) should not return true
> > ever. If it does, then this wants to be fixed.
>
> I
On 11 March 2018 at 12:38, Ard Biesheuvel wrote:
> This adds support for emitting special sections such as initcall arrays,
> PCI fixups and tracepoints as relative references rather than absolute
> references. This reduces the size by 50% on 64-bit architectures, but
> more importantly, it remove
On Thu, 15 Mar 2018, Dave Hansen wrote:
> On 03/15/2018 02:46 AM, Thomas Gleixner wrote:
> >> + if (!pkey || !mm_pkey_is_allocated(mm, pkey))
> > Why this extra check? mm_pkey_is_allocated(mm, 0) should not return true
> > ever. If it does, then this wants to be fixed.
>
> I was thinking that we
On 03/15/2018 02:46 AM, Thomas Gleixner wrote:
>> +if (!pkey || !mm_pkey_is_allocated(mm, pkey))
> Why this extra check? mm_pkey_is_allocated(mm, 0) should not return true
> ever. If it does, then this wants to be fixed.
I was thinking that we _do_ actually want it to seem allocated. It just
On Wed, Mar 14, 2018 at 06:22:07PM -0300, Thiago Jung Bauermann wrote:
>
> SF Markus Elfring writes:
>
> > From: Markus Elfring
> > Date: Sun, 11 Mar 2018 09:03:42 +0100
> >
> > Add a jump target so that a bit of exception handling can be better reused
> > at the end of this function.
> >
> > T
From: Madalin-cristian Bucur
Date: Thu, 15 Mar 2018 09:32:35 +
>> -Original Message-
>> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
>> Sent: Wednesday, March 14, 2018 8:43 PM
>> To: da...@davemloft.net; Madalin-cristian Bucur
>>
>>
>> On Wed, 2018-03-14 at 08:37 -0
On Thu, 2018-03-15 at 14:57 +0300, Dan Carpenter wrote:
> On Wed, Mar 14, 2018 at 06:22:07PM -0300, Thiago Jung Bauermann wrote:
> >
> > SF Markus Elfring writes:
> >
> > > From: Markus Elfring
> > > Date: Sun, 11 Mar 2018 09:03:42 +0100
> > >
> > > Add a jump target so that a bit of exception
On Wed, 14 Mar 2018, Ram Pai wrote:
> Applications need the ability to associate an address-range with some
> key and latter revert to its initial default key. Pkey-0 comes close to
> providing this function but falls short, because the current
> implementation disallows applications to explicitly
> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> Sent: Wednesday, March 14, 2018 8:43 PM
> To: da...@davemloft.net; Madalin-cristian Bucur
>
>
> On Wed, 2018-03-14 at 08:37 -0500, Madalin Bucur wrote:
> > Hi,
> >
> > This patch set is addressing sever
Hi Balbir,
On Thu, 15 Mar 2018 19:42:33 +1100 Balbir Singh wrote:
>
> On Wed, Mar 14, 2018 at 4:23 PM, Stephen Rothwell
> wrote:
> >
> > I also get these from a powerpc allyesconfig build of linux-next:
> >
> > WARNING: vmlinux.o(.text+0x7c81c): Section mismatch in reference from the
> > funct
On Wed, Mar 14, 2018 at 4:23 PM, Stephen Rothwell wrote:
> Hi all,
>
> I also get these from a powerpc allyesconfig build of linux-next:
>
> WARNING: vmlinux.o(.text+0x7c81c): Section mismatch in reference from the
> function .stop_machine_change_mapping() to the function
> .meminit.text:.create
On Thu, Mar 15, 2018 at 3:51 AM, Deepa Dinamani wrote:
> On Wed, Mar 14, 2018 at 1:52 PM, Arnd Bergmann wrote:
>> On Wed, Mar 14, 2018 at 4:50 AM, Deepa Dinamani
>> wrote:
>>> The file arch/arm64/kernel/process.c needs asm/compat.h also to be
>>> included directly since this is included conditi
On 15/3/18 4:18 pm, Alistair Popple wrote:
> I must admit I haven't really looked at the iommu_table_group code in depth so
> don't fully understand it, but I was wondering why we don't hit this for
> NVLink1
> as well?
>
> The error that Skiboot is printing is because the requested page size doe
33 matches
Mail list logo
