> On 13-Dec-2021, at 11:15 PM, Sean Christopherson wrote:
>
> Use kvm_arch_vcpu_get_wait() to get a vCPU's rcuwait object instead of
> using vcpu->wait directly in kvmhv_run_single_vcpu(). Functionally, this
> is a nop as vcpu->arch.waitp is guaranteed to point at vcpu->wait. But
> that is n
On Mon, Dec 13 2021 at 12:29, Nishanth Menon wrote:
> On 23:18-20211210, Thomas Gleixner wrote:
> Also while testing on TI K3 platforms, I noticed:
>
> msi_device_data_release/msi_device_destroy_sysfs in am64xx-evm / j7200
The warning complains about a device being released with MSI descriptors
st
On 12/13/2021 10:43 PM, Matthew Wilcox wrote:
On Mon, Dec 13, 2021 at 08:30:33AM +, David Laight wrote:
From: Matthew Wilcox
Sent: 12 December 2021 11:48
On Sat, Dec 11, 2021 at 05:53:46PM +, David Laight wrote:
From: Tiezhu Yang
Sent: 11 December 2021 03:33
v2:
-- add copy_to_use
Rob Herring writes:
> On Mon, Dec 13, 2021 at 6:47 AM Michael Ellerman wrote:
>> Rob Herring writes:
>> > Use of the of_scan_flat_dt() function predates libfdt and is discouraged
>> > as libfdt provides a nicer set of APIs. Rework
>> > early_init_dt_scan_memory() to be called directly and use li
From: Russell Currey
Livepatching a loaded module involves applying relocations through
apply_relocate_add(), which attempts to write to read-only memory when
CONFIG_STRICT_MODULE_RWX=y. Work around this by performing these
writes through the text poke area by using patch_instruction().
R_PPC_R
Le 13/12/2021 à 18:26, Joe Lawrence a écrit :
> On 12/13/21 11:36 AM, Christophe Leroy wrote:
>>
>>
>> Le 13/12/2021 à 15:47, Joe Lawrence a écrit :
>>> On 12/13/21 2:42 AM, Christophe Leroy wrote:
Hello Joe,
I'm implementing LIVEPATCH on PPC32 and I wanted to test with
S
On 12/14/21 7:44 AM, Christophe Leroy wrote:
>
>
> Le 13/12/2021 à 18:26, Joe Lawrence a écrit :
>> On 12/13/21 11:36 AM, Christophe Leroy wrote:
>>>
>>>
>>> Le 13/12/2021 à 15:47, Joe Lawrence a écrit :
On 12/13/21 2:42 AM, Christophe Leroy wrote:
>
> Hello Joe,
>
> I'm impl
On Tue, Dec 14, 2021 at 06:03:11PM +0800, Tiezhu Yang wrote:
> On 12/13/2021 10:43 PM, Matthew Wilcox wrote:
> > On Mon, Dec 13, 2021 at 08:30:33AM +, David Laight wrote:
> > > From: Matthew Wilcox
> > > > Sent: 12 December 2021 11:48
> > > >
> > > > On Sat, Dec 11, 2021 at 05:53:46PM +, D
Le 14/12/2021 à 14:00, Joe Lawrence a écrit :
> On 12/14/21 7:44 AM, Christophe Leroy wrote:
>>
>>
>> Le 13/12/2021 à 18:26, Joe Lawrence a écrit :
>>> On 12/13/21 11:36 AM, Christophe Leroy wrote:
Le 13/12/2021 à 15:47, Joe Lawrence a écrit :
> On 12/13/21 2:42 AM, Christophe
On Tue, 14 Dec 2021 08:35:14 +0100
Christophe Leroy wrote:
> > Will continue investigating.
> >
>
> trace_selftest_startup_function_graph() calls register_ftrace_direct()
> which returns -ENOSUPP because powerpc doesn't select
> CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS.
>
> Should TEST_DIRE
On Mon, Dec 13, 2021 at 05:50:52PM +, Christophe Leroy wrote:
> Le 13/12/2021 à 18:33, Steven Rostedt a écrit :
> > On Mon, 13 Dec 2021 17:30:48 +
> > Christophe Leroy wrote:
> >
> >> Thanks, I will try that.
> >>
> >> I can't find ftrace_graph_func() in s390. Does it mean that s390 doesn
On Tue, Dec 14, 2021 at 5:18 AM Michael Ellerman wrote:
>
> Rob Herring writes:
> > On Mon, Dec 13, 2021 at 6:47 AM Michael Ellerman
> > wrote:
> >> Rob Herring writes:
> >> > Use of the of_scan_flat_dt() function predates libfdt and is discouraged
> >> > as libfdt provides a nicer set of APIs
Le 14/12/2021 à 15:25, Heiko Carstens a écrit :
> On Mon, Dec 13, 2021 at 05:50:52PM +, Christophe Leroy wrote:
>> Le 13/12/2021 à 18:33, Steven Rostedt a écrit :
>>> On Mon, 13 Dec 2021 17:30:48 +
>>> Christophe Leroy wrote:
>>>
Thanks, I will try that.
I can't find ftrac
https://bugzilla.kernel.org/show_bug.cgi?id=215217
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #300015|0 |1
is obsolete|
On Tue, Dec 14 2021 at 10:22, Nishanth Menon wrote:
> On 10:41-20211214, Thomas Gleixner wrote:
> Agreed that the warning is fine, the null pointer exception that follows
> [1] [2] it however does'nt look right and it can be trivially fixed with the
> following fixup for ee907874
On Tue, Dec 14 2021 at 17:36, Thomas Gleixner wrote:
> On Tue, Dec 14 2021 at 10:22, Nishanth Menon wrote:
>> On 10:41-20211214, Thomas Gleixner wrote:
> [ 13.478122] Call trace:
> [ 13.509042] msi_device_destroy_sysfs+0x18/0x88
> [ 13.509058] msi_domain_free_irqs+0x34/0x
Le 27/10/2021 à 16:18, Paul Moore a écrit :
> On Wed, Oct 27, 2021 at 7:41 AM Christophe Leroy
> wrote:
>> Le 27/10/2021 à 13:29, Michael Ellerman a écrit :
>>> Paul Moore writes:
On Tue, Oct 26, 2021 at 6:55 AM Michael Ellerman
wrote:
> Stephen Rothwell writes:
>> Hi all,
On Tue, Dec 14, 2021 at 12:59 PM Christophe Leroy
wrote:
> Hello Paul,
>
> I've been trying to setup your test suite on my powerpc board but it's
> based on Perl and on a lot of optional Perl packages. I was able to add
> them one by one until some of them require some .so libraries
> (Pathtools-C
Le 14/12/2021 à 19:23, Paul Moore a écrit :
> On Tue, Dec 14, 2021 at 12:59 PM Christophe Leroy
> wrote:
>> Hello Paul,
>>
>> I've been trying to setup your test suite on my powerpc board but it's
>> based on Perl and on a lot of optional Perl packages. I was able to add
>> them one by one until
Nishanth,
On Tue, Dec 14 2021 at 18:03, Thomas Gleixner wrote:
> msi_device_data_release()
> ...
> pcim_release()
>pci_disable_msi[x]()
>
> Groan
I think I managed to distangle this. Can you please give:
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-
Use of the of_scan_flat_dt() function predates libfdt and is discouraged
as libfdt provides a nicer set of APIs. Rework
early_init_dt_scan_memory() to be called directly and use libfdt.
Cc: John Crispin
Cc: Thomas Bogendoerfer
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
On 12/14/21 20:32, Christophe Leroy wrote:
Le 14/12/2021 à 19:23, Paul Moore a écrit :
On Tue, Dec 14, 2021 at 12:59 PM Christophe Leroy
wrote:
Hello Paul,
I've been trying to setup your test suite on my powerpc board but it's
based on Perl and on a lot of optional Perl packages. I was able
Nishanth,
On Tue, Dec 14 2021 at 14:56, Nishanth Menon wrote:
> On 21:15-20211214, Thomas Gleixner wrote:
>> I think I managed to distangle this. Can you please give:
>>
>>git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v4-part-2
>
>
> Umm..
On Tue, 7 Dec 2021 10:05:57 -0300, Thadeu Lima de Souza Cascardo wrote:
> A mis-match between reported and actual mitigation is not restricted to the
> Vulnerable case. The guest might also report the mitigation as "Software
> count cache flush" and the host will still mitigate with branch cache
>
On Tue, 7 Dec 2021 12:02:28 +0100, Anders Roxell wrote:
> Clang warns:
>
> arch/powerpc/platforms/cell/pervasive.c:81:2: error: unannotated fall-through
> between switch labels [-Werror,-Wimplicit-fallthrough]
> case SRR1_WAKEEE:
> ^
> arch/powerpc/platforms/cell/pervasive.c:81:2:
On Fri, 26 Nov 2021 13:40:35 +0100, Christophe Leroy wrote:
> Today we have the following IBATs allocated:
>
> ---[ Instruction Block Address Translation ]---
> 0: 0xc000-0xc03f 0x 4M Kernel x m
> 1: 0xc040-0xc05f 0x0040 2M Kernel
On Wed, 8 Dec 2021 17:36:52 +, Christophe Leroy wrote:
> Commit df1f679d19ed ("powerpc/powermac: Add missing
> lockdep_register_key()") fixed a problem that was causing a WARNING.
>
> There are two other places in the same file with the same problem
> originating from commit 9e607f72748d ("i2c
On Tue, 19 Oct 2021 09:29:11 +0200, Christophe Leroy wrote:
> On booke/40x we don't have segments like book3s/32.
> On booke/40x we don't have access protection groups like 8xx.
>
> Use the PID register to provide user access protection.
> Kernel address space can be accessed with any PID.
> User
On Mon, 29 Nov 2021 18:49:37 +0100, Christophe Leroy wrote:
> PPC64 version of ___get_user_instr() can be used for PPC32 as well,
> by simply disabling the suffix part with IS_ENABLED(CONFIG_PPC64).
>
>
Applied to powerpc/next.
[1/5] powerpc/inst: Refactor ___get_user_instr()
https://git.
On Mon, 27 Sep 2021 17:12:39 +0200, Christophe Leroy wrote:
> As reported by Carlo, 16Mbytes is not enough with modern kernels
> that tend to be a bit big, so map another 16M page at boot.
>
>
Applied to powerpc/next.
[1/1] powerpc/40x: Map 32Mbytes of memory at startup
https://git.kernel
On Tue, 7 Dec 2021 16:07:18 +0530, Hari Bathini wrote:
> Kdump can be triggered after panic_notifers since commit f06e5153f4ae2
> ("kernel/panic.c: add "crash_kexec_post_notifiers" option for kdump
> after panic_notifers") introduced crash_kexec_post_notifiers option.
> But using this option would
On Thu, 2 Dec 2021 00:41:35 +1000, Nicholas Piggin wrote:
> Now that there's a platform that can make good use of it, here's
> a series that can prevent the hash MMU code being built for 64s
> platforms that don't need it.
>
> Since v5:
> - Make cxl select hash.
> - Add new patch (15) to prevent r
On Sun, 5 Dec 2021 21:09:25 +0800, Xiang wangx wrote:
> struct of_device_id should normally be const
>
>
Applied to powerpc/next.
[1/1] macintosh:add const to of_device_id
https://git.kernel.org/powerpc/c/8cffe0b0b6b3342d75e5469f07496173feace6bc
cheers
On Sun, Nov 28, 2021 at 10:10 AM Michał Mirosław
wrote:
>
> On Sat, Nov 27, 2021 at 07:56:57PM -0800, Yury Norov wrote:
> > Now as we have bitmap_weight_eq(), switch bitmap_full() and
> > bitmap_empty() to using it.
> >
> > Signed-off-by: Yury Norov
> > ---
> > include/linux/bitmap.h | 26 ++
On Wed, 1 Sep 2021 18:45:50 +1000, Alexey Kardashevskiy wrote:
> H_COPY_TOFROM_GUEST is an hcall for an upper level VM to access its nested
> VMs memory. The userspace can trigger WARN_ON_ONCE(!(gfp & __GFP_NOWARN))
> in __alloc_pages() by constructing a tiny VM which only does
> H_COPY_TOFROM_GUES
On Wed, 1 Sep 2021 18:45:12 +1000, Alexey Kardashevskiy wrote:
> The userspace can trigger "vmalloc size %lu allocation failure: exceeds
> total pages" via the KVM_SET_USER_MEMORY_REGION ioctl.
>
> This silences the warning by checking the limit before calling vzalloc()
> and returns ENOMEM if fai
On Wed, 1 Dec 2021 15:21:12 +1000, Nicholas Piggin wrote:
> ri_set is set and never used.
>
>
Applied to powerpc/next.
[1/1] KVM: PPC: Book3S HV P9: Remove unused ri_set local variable
https://git.kernel.org/powerpc/c/f6a1987773a5908bae7bcadbeec0bcab25df7b20
cheers
On Mon, 13 Dec 2021 17:45:56 +, Sean Christopherson wrote:
> Use kvm_arch_vcpu_get_wait() to get a vCPU's rcuwait object instead of
> using vcpu->wait directly in kvmhv_run_single_vcpu(). Functionally, this
> is a nop as vcpu->arch.waitp is guaranteed to point at vcpu->wait. But
> that is not
On Tue, 23 Nov 2021 18:15:20 +1000, Russell Currey wrote:
> Livepatching a loaded module involves applying relocations through
> apply_relocate_add(), which attempts to write to read-only memory when
> CONFIG_STRICT_MODULE_RWX=y. Work around this by performing these
> writes through the text poke
At the moment KVM on PPC creates 3 types of entries under the kvm debugfs:
1) "%pid-%fd" per a KVM instance (for all platforms);
2) "vm%pid" (for PPC Book3s HV KVM);
3) "vm%u_vcpu%u_timing" (for PPC Book3e KVM).
The problem with this is that multiple VMs per process is not allowed for
2) and 3) wh
allmodconfig
i386 randconfig-c001-20211214
i386 randconfig-c001-20211215
sh kfr2r09-romimage_defconfig
powerpcklondike_defconfig
xtensaxip_kc705_defconfig
mips bmips_stb_defconfig
arm
nfig
arm64 defconfig
i386 randconfig-c001-20211214
sh kfr2r09-romimage_defconfig
xtensaxip_kc705_defconfig
powerpcklondike_defconfig
powerpc motionpro_defconfig
powerpc mpc834x_itx_de
allmodconfig
i386 randconfig-c001-20211214
mips randconfig-c004-20211214
i386 randconfig-c001-20211215
sh kfr2r09-romimage_defconfig
powerpcklondike_defconfig
xtensaxip_kc705_defconfig
mips
On Mon, 2021-12-13 at 22:12 +0530, Sachin Sant wrote:
> Mitigation patching test iterates over a set of mitigations
> irrespective
> of whether a certain mitigation is supported/available in the kernel.
> This causes following messages on a kernel where some mitigations
> are unavailable:
>
> Sp
From: Minghao Chi
Return value from ocxl_context_attach() directly instead
of taking this in another redundant variable.
Reported-by: Zeal Robot
Signed-off-by: Minghao Chi
---
drivers/misc/ocxl/file.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/misc/ocxl/fil
Commit e7142bf5d231 ("arm64, mm: make randomization selected by
generic topdown mmap layout") introduced a default version of
arch_randomize_brk() provided when
CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT is selected.
powerpc could select CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
but needs to
Unlike most architectures, powerpc can only define at runtime
if it is going to use the generic arch_get_unmapped_area() or not.
Today, powerpc has a copy of the generic arch_get_unmapped_area()
because when selection HAVE_ARCH_UNMAPPED_AREA the generic
arch_get_unmapped_area() is not available.
Powerpc needs flags and len to make decision on arch_get_mmap_end().
So add them as parameters to arch_get_mmap_end().
Signed-off-by: Christophe Leroy
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm64/include/asm/processor.h | 4 ++--
mm/mmap.c | 6 +++---
2 files ch
Rebased on top of powerpc/next branch
This series converts powerpc to default topdown mmap layout.
powerpc requires its own arch_get_unmapped_area() only when
slices are needed, which is only for book3s/64. First part of
the series moves slices into book3s/64 specific directories
and cleans up ot
vma_mmu_pagesize() is only required for slices,
otherwise there is a generic weak version doing the
exact same thing.
Move it to slice.c
Signed-off-by: Christophe Leroy
Reviewed-by: Nicholas Piggin
---
arch/powerpc/mm/hugetlbpage.c | 11 ---
arch/powerpc/mm/slice.c | 9 +
Do like most other architectures and provide randomisation also to
"legacy" memory mappings, by adding the random factor to
mm->mmap_base in arch_pick_mmap_layout().
See commit 8b8addf891de ("x86/mm/32: Enable full randomization on
i386 and X86_32") for all explanations and benefits of that mmap
r
Since commit 555904d07eef ("powerpc/8xx: MM_SLICE is not needed
anymore") only book3s/64 selects CONFIG_PPC_MM_SLICES.
Move slice.c into mm/book3s64/
Move necessary stuff in asm/book3s/64/slice.h and
remove asm/slice.h
Signed-off-by: Christophe Leroy
Reviewed-by: Nicholas Piggin
---
arch/powe
CONFIG_PPC_MM_SLICES is always selected by hash book3s/64.
CONFIG_PPC_MM_SLICES is never selected by other platforms.
Remove it.
Signed-off-by: Christophe Leroy
Reviewed-by: Nicholas Piggin
---
arch/powerpc/include/asm/hugetlb.h | 2 +-
arch/powerpc/include/asm/paca.h| 7 ---
Use the generic version of arch_get_unmapped_area() which
is now available at all time instead of its copy
radix__arch_get_unmapped_area()
To allow that for PPC64, add arch_get_mmap_base() and
arch_get_mmap_end() macros.
Instead of setting mm->get_unmapped_area() to either
arch_get_unmapped_area(
hugetlb_get_unmapped_area() is now identical to the
generic version if only RADIX is enabled, so move it
to slice.c and let it fallback on the generic one
when HASH MMU is not compiled in.
Do the same with arch_get_unmapped_area() and
arch_get_unmapped_area_topdown().
Signed-off-by: Christophe Le
Use the generic version of arch_hugetlb_get_unmapped_area()
which is now available at all time.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/64/hugetlb.h | 4 --
arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 55
arch/powerpc/mm/hugetlbpage.c
Select CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT and
remove arch/powerpc/mm/mmap.c
This change reuses the generic framework added by
commit 67f3977f805b ("arm64, mm: move generic mmap layout
functions to mm") without any functional change.
Comparison between powerpc implementation and the gene
57 matches
Mail list logo
