On Sat, 14 Oct 2017 09:47:59 +1100
Paul Mackerras wrote:
> On Sun, Aug 13, 2017 at 11:33:44AM +1000, Nicholas Piggin wrote:
> > The "lppaca" is a structure registered with the hypervisor. This
> > is unnecessary when running on non-virtualised platforms. One field
> > from the lppaca (pmcregs_in_
On Mon, Oct 02, 2017 at 10:40:22AM +0200, Greg Kurz wrote:
> Userland passes an array of 64 SLB descriptors to KVM_SET_SREGS,
> some of which are valid (ie, SLB_ESID_V is set) and the rest are
> likely all-zeroes (with QEMU at least).
>
> Each of them is then passed to kvmppc_mmu_book3s_64_slbmte(
On Wed, Oct 11, 2017 at 04:00:34PM +1100, Alexey Kardashevskiy wrote:
> kvmppc_gpa_to_ua() accesses KVM memory slot array via
> srcu_dereference_check() and this produces warnings from RCU like below.
>
> This extends the existing srcu_read_lock/unlock to cover that
> kvmppc_gpa_to_ua() as well.
>
On Tue, Oct 10, 2017 at 08:18:28PM +1000, Nicholas Piggin wrote:
> - Add another case where msgsync is required.
> - Required barrier sequence for global doorbells is msgsync ; lwsync
> - POWER9 DD1 has a different barrier sequence that we don't implement,
> so remove
>
> When msgsnd is used for
On Thu, Sep 14, 2017 at 11:56:25PM +0200, Greg Kurz wrote:
> The following program causes a kernel oops:
>
> #include
> #include
> #include
> #include
> #include
>
> main()
> {
> int fd = open("/dev/kvm", O_RDWR);
> ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_PPC_HTM);
> }
>
> This happe
On Fri, Oct 13, 2017 at 06:14:00PM +0200, Paolo Bonzini wrote:
> On 13/10/2017 01:16, Greg Kurz wrote:
> > Ping ?
>
> When is Paul back from vacation? :)
Now. :)
Paul.
On Sun, Aug 13, 2017 at 11:33:44AM +1000, Nicholas Piggin wrote:
> The "lppaca" is a structure registered with the hypervisor. This
> is unnecessary when running on non-virtualised platforms. One field
> from the lppaca (pmcregs_in_use) is also used by the host, so move
> the host part out into the
Hi James, all,
(add linux-...@vger.kernel.org as it is user-visible,
Catalin Marinas and Arnd Bergmann )
On Thu, Jun 29, 2017 at 05:26:37PM +0100, James Morse wrote:
> compat_ptrace_request() lacks handlers for PTRACE_{G,S}ETSIGMASK,
> instead using those in ptrace_request(). The compat variant s
On 10/13/17 1:05 PM, Alex Williamson wrote:
On Fri, 13 Oct 2017 07:01:48 -0500
Steven Royer wrote:
On 2017-10-13 06:53, Steven Royer wrote:
On 2017-10-12 22:34, Bjorn Helgaas wrote:
[+cc Alex, Bodong, Eli, Saeed]
On Thu, Oct 12, 2017 at 02:59:23PM -0500, Bryant G. Ly wrote:
On 10/12/17 1
On Fri, 13 Oct 2017 07:01:48 -0500
Steven Royer wrote:
> On 2017-10-13 06:53, Steven Royer wrote:
> > On 2017-10-12 22:34, Bjorn Helgaas wrote:
> >> [+cc Alex, Bodong, Eli, Saeed]
> >>
> >> On Thu, Oct 12, 2017 at 02:59:23PM -0500, Bryant G. Ly wrote:
> >>> On 10/12/17 1:29 PM, Bjorn Helgaas
Add an optimized mm_zero_struct_page(), so struct page's are zeroed without
calling memset(). We do eight to ten regular stores based on the size of
struct page. Compiler optimizes out the conditions of switch() statement.
SPARC-M6 with 15T of memory, single thread performance:
* A new variant of memblock_virt_alloc_* allocations:
memblock_virt_alloc_try_nid_raw()
- Does not zero the allocated memory
- Does not panic if request cannot be satisfied
* optimize early system hash allocations
Clients can call alloc_large_system_hash() with flag: HASH_ZERO to specify
Changelog:
v12 - v11
- Improved comments for mm: zero reserved and unavailable struct pages
- Added back patch: mm: deferred_init_memmap improvements
- Added patch from Will Deacon: arm64: kasan: Avoid using
vmemmap_populate to initialise shadow
v11 - v10
- Moved kasan_map_populate() implementat
vmemmap_alloc_block() will no longer zero the block, so zero memory
at its call sites for everything except struct pages. Struct page memory
is zero'd by struct page initialization.
Replace allocators in sprase-vmemmap to use the non-zeroing version. So,
we will get the performance improvement by
Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT),
flags and other fields in "struct page"es are never changed prior to first
initializing struct pages by going through __init_single_page().
With deferred struct page feature enabled, however, we set fields in
register_page_bo
During early boot, kasan uses vmemmap_populate() to establish its shadow
memory. But, that interface is intended for struct pages use.
Because of the current project, vmemmap won't be zeroed during allocation,
but kasan expects that memory to be zeroed. We are adding a new
kasan_map_populate() fun
From: Will Deacon
The kasan shadow is currently mapped using vmemmap_populate since that
provides a semi-convenient way to map pages into swapper. However, since
that no longer zeroes the mapped pages, it is not suitable for kasan,
which requires that the shadow is zeroed in order to avoid false
Remove duplicating code by using common functions
vmemmap_pud_populate and vmemmap_pgd_populate.
Signed-off-by: Pavel Tatashin
Reviewed-by: Steven Sistare
Reviewed-by: Daniel Jordan
Reviewed-by: Bob Picco
Acked-by: David S. Miller
Acked-by: Michal Hocko
---
arch/sparc/mm/init_64.c | 23
Some memory is reserved but unavailable: not present in memblock.memory
(because not backed by physical pages), but present in memblock.reserved.
Such memory has backing struct pages, but they are not initialized by going
through __init_single_page().
In some cases these struct pages are accessed
Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT),
flags and other fields in "struct page"es are never changed prior to first
initializing struct pages by going through __init_single_page().
With deferred struct page feature enabled there is a case where we set some
fields pr
deferred_init_memmap() is called when struct pages are initialized later
in boot by slave CPUs. This patch simplifies and optimizes this function,
and also fixes a couple issues (described below).
The main change is that now we are iterating through free memblock areas
instead of all configured me
During early boot, kasan uses vmemmap_populate() to establish its shadow
memory. But, that interface is intended for struct pages use.
Because of the current project, vmemmap won't be zeroed during allocation,
but kasan expects that memory to be zeroed. We are adding a new
kasan_map_populate() fun
...which makes code slightly cleaner.
Requires: d43f59ce6c50 ("PCI: Add for_each_pci_bridge() helper")
Signed-off-by: Andy Shevchenko
---
arch/powerpc/kernel/pci-hotplug.c | 7 ++-
arch/powerpc/kernel/pci_of_scan.c | 7 ++-
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/
On Fri, Oct 13, 2017 at 12:00:27PM -0400, Pavel Tatashin wrote:
> BTW, don't we need the same aligments inside for_each_memblock() loop?
Hmm, yes actually, given that we shift them right for the shadow address.
> How about change kasan_map_populate() to accept regular VA start, end
> address, and
On 13/10/2017 01:16, Greg Kurz wrote:
> Ping ?
When is Paul back from vacation? :)
Paolo
> On Thu, 14 Sep 2017 23:56:25 +0200
> Greg Kurz wrote:
>
>> The following program causes a kernel oops:
>>
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> main()
>> {
>> int fd
From: Mathieu Desnoyers
Threads targeting the same VM but which belong to different thread
groups is a tricky case. It has a few consequences:
It turns out that we cannot rely on get_nr_threads(p) to count the
number of threads using a VM. We can use
(atomic_read(&mm->mm_users) == 1 && get_nr_th
From: Mathieu Desnoyers
Provide a new command allowing processes to register their intent to use
the private expedited command.
This allows PowerPC to skip the full memory barrier in switch_mm(), and
only issue the barrier when scheduling into a task belonging to a
process that has registered to
From: Mathieu Desnoyers
Architectures without membarrier hooks don't need to emit the
empty membarrier_arch_switch_mm() static inline when
CONFIG_MEMBARRIER=y.
Adapt the CONFIG_MEMBARRIER=n counterpart to only emit the empty
membarrier_arch_switch_mm() for architectures with membarrier hooks.
R
On Fri, Oct 13, 2017 at 6:08 PM, Julia Lawall wrote:
>
>
> On Fri, 13 Oct 2017, Bhumika Goyal wrote:
>
>> These structures are passed to the eeh_ops_register function during the
>> initialization phase. There they get stored in a structure variable
>> which only makes function calls through functi
On Fri, 13 Oct 2017, Bhumika Goyal wrote:
> These structures are passed to the eeh_ops_register function during the
> initialization phase. There they get stored in a structure variable
> which only makes function calls through function pointers. There is no
> other usage of these eeh_ops struct
BTW, don't we need the same aligments inside for_each_memblock() loop?
How about change kasan_map_populate() to accept regular VA start, end
address, and convert them internally after aligning to PAGE_SIZE?
Thank you,
Pavel
On Fri, Oct 13, 2017 at 11:54 AM, Pavel Tatashin
wrote:
>> Thanks for
> Thanks for sharing the .config and tree. It looks like the problem is that
> kimg_shadow_start and kimg_shadow_end are not page-aligned. Whilst I fix
> them up in kasan_map_populate, they remain unaligned when passed to
> kasan_populate_zero_shadow, which confuses the loop termination conditions
Hi Pavel,
On Fri, Oct 13, 2017 at 11:09:41AM -0400, Pavel Tatashin wrote:
> > It shouldn't be difficult to use section mappings with my patch, I just
> > don't really see the need to try to optimise TLB pressure when you're
> > running with KASAN enabled which already has something like a 3x slowd
Here is simplified qemu command:
qemu-system-aarch64 \
-display none \
-kernel ./arch/arm64/boot/Image \
-M virt -cpu cortex-a57 -s -S
In a separate terminal start arm64 cross debugger:
$ aarch64-unknown-linux-gnu-gdb ./vmlinux
...
Reading symbols from ./vmlinux...done.
(gdb)
> It shouldn't be difficult to use section mappings with my patch, I just
> don't really see the need to try to optimise TLB pressure when you're
> running with KASAN enabled which already has something like a 3x slowdown
> afaik. If it ends up being a big deal, we can always do that later, but
> m
> Do you know what your physical memory layout looks like?
[0.00] Memory: 34960K/131072K available (16316K kernel code,
6716K rwdata, 7996K rodata, 1472K init, 8837K bss, 79728K reserved,
16384K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] kasan : 0x0
Hi,
On Fri, Oct 13, 2017 at 03:43:19PM +0100, Will Deacon wrote:
> On Fri, Oct 13, 2017 at 10:10:09AM -0400, Pavel Tatashin wrote:
> > I am getting the following panic during boot:
> >
> > [0.012637] pid_max: default: 32768 minimum: 301
> > [0.016037] Security Framework initialized
> > [
Hi Pavel,
On Fri, Oct 13, 2017 at 10:10:09AM -0400, Pavel Tatashin wrote:
> I have a couple concerns about your patch:
>
> One of the reasons (and actually, the main reason) why I preferred to
> keep vmemmap_populate() instead of implementing kasan's own variant,
> which btw can be done in common
Hi Will,
I have a couple concerns about your patch:
One of the reasons (and actually, the main reason) why I preferred to
keep vmemmap_populate() instead of implementing kasan's own variant,
which btw can be done in common code similarly to
vmemmap_populate_basepages() is that vmemmap_populate()
On 10/13/2017 05:37 AM, Michael Ellerman wrote:
>
> I really dislike this.
>
> You're basically saying the kernel can't work out how to get a device
> working, so let's leave it up to the user.
Oh, it was never my intention to say such blasphemy :)
It meant to be just a debug option to help the
These structures are passed to the eeh_ops_register function during the
initialization phase. There they get stored in a structure variable
which only makes function calls through function pointers. There is no
other usage of these eeh_ops structures and their fields are never
modified after init p
This patch provides the MMIO load/store vector indexed
X-Form emulation.
Instructions implemented: lvx, stvx
Signed-off-by: Jose Ricardo Ziviani
---
arch/powerpc/include/asm/kvm_host.h | 2 +
arch/powerpc/include/asm/kvm_ppc.h| 4 +
arch/powerpc/include/asm/ppc-opcode.h | 6 ++
arch
Hello!
This patch implements MMIO emulation for two instructions: lvx and stvx.
Thank you!
Jose Ricardo Ziviani (1):
KVM: PPC: Book3S: Add MMIO emulation for VMX instructions
arch/powerpc/include/asm/kvm_host.h | 2 +
arch/powerpc/include/asm/kvm_ppc.h| 4 +
arch/powerpc/include/as
On Fri, 2017-10-13 at 05:59:41 UTC, Anju T Sudhakar wrote:
> Call trace observed with latest firmware, and upstream kernel.
>
> [ 14.499938] NIP [c00f318c] init_imc_pmu+0x8c/0xcf0
> [ 14.499973] LR [c00f33f8] init_imc_pmu+0x2f8/0xcf0
> [ 14.57] Call Trace:
> [ 14.500027
On Wed, 2017-10-11 at 12:57:39 UTC, Anju T Sudhakar wrote:
> Stack trace output during a stress test:
> [4.310049] Freeing initrd memory: 22592K
> [4.310646] rtas_flash: no firmware flash support
> [4.313341] cpuhp/64: page allocation failure: order:0,
> mode:0x14480c0(GFP_KERNEL|__GF
On Wed, 2017-10-04 at 06:50:52 UTC, Anju T Sudhakar wrote:
> Nest/core pmu units are enabled only when it is used. A reference count is
>
> maintained for the events which uses the nest/core pmu units. Currently in
>
> *_imc_counters_release function a WARN() is used for notification
Hi Linus,
Please pull a few more powerpc fixes for 4.14:
The following changes since commit 53ecde0b9126ff140abe3aefd7f0ec64d6fa36b0:
powerpc/powernv: Increase memory block size to 1GB on radix (2017-10-06
15:50:45 +1100)
are available in the git repository at:
git://git.kernel.org/pub/sc
On 2017-10-13 06:53, Steven Royer wrote:
On 2017-10-12 22:34, Bjorn Helgaas wrote:
[+cc Alex, Bodong, Eli, Saeed]
On Thu, Oct 12, 2017 at 02:59:23PM -0500, Bryant G. Ly wrote:
On 10/12/17 1:29 PM, Bjorn Helgaas wrote:
>On Thu, Oct 12, 2017 at 03:09:53PM +1100, Michael Ellerman wrote:
>>Bjorn H
On 2017-10-12 22:34, Bjorn Helgaas wrote:
[+cc Alex, Bodong, Eli, Saeed]
On Thu, Oct 12, 2017 at 02:59:23PM -0500, Bryant G. Ly wrote:
On 10/12/17 1:29 PM, Bjorn Helgaas wrote:
>On Thu, Oct 12, 2017 at 03:09:53PM +1100, Michael Ellerman wrote:
>>Bjorn Helgaas writes:
>>
>>>On Fri, Sep 22, 2017
"Guilherme G. Piccoli" writes:
> During a kdump kernel boot in PowerPC, we request a reset of the
> PHBs to the FW. It makes sense, since if we are booting a kdump
> kernel it means we had some trouble before and we cannot rely in
> the adapters' health; they could be in a bad state, hence the
>
Hi Balbir,sorry for not mentioning details.
below are the details1. What machine you tried this on? - I am using PowerPC
e500mc processor with and it's customised. Can't share much details
2. What MMU mode? -Not sure about this.
3. What kernel? -kernel version is 4.1.35
4. What gcc versio
On 12/10/17 13:05, Lothar Waßmann wrote:
Hi,
On Thu, 12 Oct 2017 12:24:10 +0100 Julien Thierry wrote:
Hi Bjorn,
On 06/10/17 23:24, Bjorn Helgaas wrote:
From: Bjorn Helgaas
Daniel Axtens reported that on the HiSilicon D05 board, the VGA device is
behind a bridge that doesn't support PCI_BR
Hi Bjorn,
On 06/10/17 23:24, Bjorn Helgaas wrote:
From: Bjorn Helgaas
Daniel Axtens reported that on the HiSilicon D05 board, the VGA device is
behind a bridge that doesn't support PCI_BRIDGE_CTL_VGA, so the VGA arbiter
never selects it as the default, which means Xorg auto-detection doesn't
w
Ping ?
On Mon, 02 Oct 2017 10:40:22 +0200
Greg Kurz wrote:
> Userland passes an array of 64 SLB descriptors to KVM_SET_SREGS,
> some of which are valid (ie, SLB_ESID_V is set) and the rest are
> likely all-zeroes (with QEMU at least).
>
> Each of them is then passed to kvmppc_mmu_book3s_64_slbm
54 matches
Mail list logo
