This even allows simd in preemptible kernel code,
as does x86, although this is rarely safe (could be used with
kthread_create_on_cpu). All callers are disabling preemption.
v4: fix build without CONFIG_AVX
change commit message
Signed-off-by: Shawn Landden
---
arch/powerpc/include/asm/switc
Based off the x86 one.
WireGuard really wants to be able to do SIMD in interrupts,
so it can accelerate its in-bound path.
v4: allow using the may_use_simd symbol even when it always
returns false (via include guards)
Signed-off-by: Shawn Landden
---
arch/powerpc/include/asm/simd.h | 17 +++
From: Michael Anderson
- Check for MSR_S so that kvmppc_set_msr will include. Prior to this
change return to guest would not have the S bit set.
- Patch based on comment from Paul Mackerras
Signed-off-by: Michael Anderson
Signed-off-by: Claudio Carvalho
---
arch/powerpc/kvm/book3s_64_m
From: Paul Mackerras
- Pass SRR1 in r11 for UV_RETURN because SRR0 and SRR1 get set by
the sc 2 instruction. (Note r3 - r10 potentially have hcall return
values in them.)
- Fix kvmppc_msr_interrupt to preserve the MSR_S bit.
Signed-off-by: Paul Mackerras
Signed-off-by: Claudio Carvalho
--
From: Sukadev Bhattiprolu
All hcalls from a secure VM go to the ultravisor from where they are
reflected into the HV. When we (HV) complete processing such hcalls,
we should return to the UV rather than to the guest kernel.
Have fast_guest_return check the kvm_arch.secure_guest field so that
eve
From: Ram Pai
When the ultravisor firmware is available, it takes control over the
LDBAR register. In this case, thread-imc updates and save/restore
operations on the LDBAR register are handled by ultravisor.
Signed-off-by: Ram Pai
[Restrict LDBAR access in assembly code and some in C, update t
From: Ram Pai
Ultravisor is responsible for flushing the tlb cache, since it manages
the PATE entries. Hence skip tlb flush, if the ultravisor firmware is
available.
Signed-off-by: Ram Pai
Signed-off-by: Claudio Carvalho
---
arch/powerpc/mm/book3s64/pgtable.c | 33 +---
From: Michael Anderson
When running under an ultravisor, the ultravisor controls the real
partition table and has it in secure memory where the hypervisor can't
access it, and therefore we (the HV) have to do a ucall whenever we want
to update an entry.
The HV still keeps a copy of its view of t
This feature tells if the ultravisor firmware is available to handle
ucalls.
Signed-off-by: Claudio Carvalho
[Device node name to "ibm,ultravisor"]
Signed-off-by: Michael Anderson
---
arch/powerpc/include/asm/firmware.h | 5 +++--
arch/powerpc/include/asm/ultravisor.h | 15 +++
a
From: Ram Pai
Add the ucall() function, which can be used to make ultravisor calls
with varied number of in and out arguments. Ultravisor calls can be made
from the host or guests.
This copies the implementation of plpar_hcall().
Signed-off-by: Ram Pai
[Change ucall.S to not save CR, rename an
From: Sukadev Bhattiprolu
The ultravisor processor mode is introduced in POWER platforms that
supports the Protected Execution Facility (PEF). Ultravisor is higher
privileged than hypervisor mode.
In PEF enabled platforms, the MSR_S bit is used to indicate if the
thread is in secure state. With
From: Anshuman Khandual
CONFIG_PPC_UV adds support for ultravisor.
Signed-off-by: Anshuman Khandual
Signed-off-by: Bharata B Rao
Signed-off-by: Ram Pai
[Update config help and commit message]
Signed-off-by: Claudio Carvalho
---
arch/powerpc/Kconfig | 20
1 file changed,
POWER platforms that supports the Protected Execution Facility (PEF)
introduce features that combine hardware facilities and firmware to
enable secure virtual machines. That includes a new processor mode
(ultravisor mode) and the ultravisor firmware.
In PEF enabled systems, the ultravisor firmware
On Thu, May 16, 2019 at 07:44:20PM +0530, srikanth wrote:
> Hello,
>
> On power9 host, performing memory hotunplug from ppc64le guest results in
> kernel oops.
>
> Kernel used : https://github.com/torvalds/linux/tree/v5.1 built using
> ppc64le_defconfig for host and ppc64le_guest_defconfig for gu
On Thu, 2019-05-16 at 11:50:54 UTC, "Aneesh Kumar K.V" wrote:
> Different parts of the code do the limit check by ignoring the top nibble
> of EA. ie. we do checks like
>
> if ((ea & EA_MASK) >= H_PGTABLE_RANGE)
> error
>
> This patch makes sure we don't insert SLB entries fo
On Wed, 2019-05-15 at 09:45:23 UTC, "Aneesh Kumar K.V" wrote:
> We can call get_region_id without validating the ea value. That means
> with a wrong ea value we hit the BUG as below.
>
> kernel BUG at arch/powerpc/include/asm/book3s/64/hash.h:129!
> Oops: Exception in kernel mode, sig: 5 [#1]
>
On Wed, 2019-05-15 at 09:07:50 UTC, "Tobin C. Harding" wrote:
> kfree() after kobject_put(). Who ever wrote this was on crack.
>
> Fixes: 7e8039795a80 ("powerpc/cacheinfo: Fix kobject memleak")
> Signed-off-by: Tobin C. Harding
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c
On Tue, 2019-05-14 at 13:43:21 UTC, Michael Ellerman wrote:
> The recent commit to cleanup ifdefs in the hugepage initialisation led
> to crashes when using 4K pages as reported by Sachin:
>
> BUG: Kernel NULL pointer dereference at 0x001c
> Faulting instruction address: 0xc1d1e58c
On Thu, 2019-05-09 at 12:59:38 UTC, Christophe Leroy wrote:
> flush_hash_pages() runs with data translation off, so current
> task_struct has to be accesssed using physical address.
>
> Reported-by: Erhard F.
> Fixes: f7354ccac844 ("powerpc/32: Remove CURRENT_THREAD_INFO and rename
> TI_CPU")
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Linus,
Please pull some powerpc fixes for 5.2:
The following changes since commit b970afcfcabd63cd3832e95db096439c177c3592:
Merge tag 'powerpc-5.2-1' of
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2019-05-10
05:29:27 -07
Nicholas Piggin writes:
> Michael Ellerman's on May 17, 2019 11:29 pm:
>> From: "Aneesh Kumar K.V"
>>
>> Accesses by userspace to random addresses outside the user or kernel
>> address range will generate an SLB fault. When we handle that fault we
>> classify the effective address into several c
On Sat, May 18, 2019 at 05:48:03AM -0400, Joel Fernandes wrote:
> Hi Christian,
>
> For next revision, could you also CC sur...@google.com as well? He is also
> working on the low memory killer. And also suggest CC to
> kernel-t...@android.com. And mentioned some comments below, thanks.
Yip, tota
Hi Christian,
For next revision, could you also CC sur...@google.com as well? He is also
working on the low memory killer. And also suggest CC to
kernel-t...@android.com. And mentioned some comments below, thanks.
On Thu, May 16, 2019 at 03:59:42PM +0200, Christian Brauner wrote:
[snip]
> diff
23 matches
Mail list logo
