Hi Michael,
Le 16/03/2019 à 12:28, Michael Ellerman a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Linus,
Please pull a few small powerpc updates for 5.1:
The following changes since commit 9580b71b5a7863c24a9bd18bcd2ad759b86b1eff:
powerpc/32: Clear on-stack exception marker u
On Sat, Mar 16, 2019 at 10:17:11AM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 16.03.19 04:26, Greg KH wrote:
>
> > No, it's just that those systems do not allow those devices to be
> > removed because they are probably not on a removable bus.
>
> Ok, devices (hw) might not be removable
On 15/03/2019 13:37, Mark Cave-Ayland wrote:
> Hi all,
>
> I've just done a git pull and rebuilt master on my Mac Mini G4 in order to
> test
> Michael's merge of my KVM PR fix, and unfortunately my kernel now hangs on
> boot :(
>
> My last working git checkout was somewhere around the 5.0-rc s
This patch series map all the kernel regions (vmalloc, IO and vmemmap) using
0xc top nibble address. This brings hash translation kernel mapping in sync
with radix.
Each of these regions can now map 512TB. We use one context to map these
regions and hence the 512TB limit. We also update radix to u
This makes it easy to update the region mapping in the later patch
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash.h| 3 ++-
arch/powerpc/include/asm/book3s/64/pgtable.h | 8 +---
arch/powerpc/include/asm/book3s/64/radix.h | 1 +
arch/powerpc/mm/hash_utils_6
This patch maps vmap, IO and vmemap regions in the 0xc address range
instead of the current 0xd and 0xf range. This brings the mapping closer
to radix translation mode.
With hash 64K page size each of this region is 512TB whereas with 4K config
we are limited by the max page table range of 64TB an
This adds an explicit check in various functions.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/hash_utils_64.c | 18 +++---
arch/powerpc/mm/pgtable-hash64.c | 13 ++---
arch/powerpc/mm/pgtable-radix.c | 16
arch/powerpc/mm/pgtable_64.c | 5 +
All the regions are now mapped with top nibble 0xc. Hence the region id
check is not needed for virt_addr_valid()
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/page.h | 12
1 file changed, 12 deletions(-)
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/in
This reduces multiple comparisons in get_region_id to a bit shift operation.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash-4k.h | 4 ++-
arch/powerpc/include/asm/book3s/64/hash-64k.h | 1 +
arch/powerpc/include/asm/book3s/64/hash.h | 31 +--
a
Le 17/03/2019 à 15:15, Mark Cave-Ayland a écrit :
On 15/03/2019 13:37, Mark Cave-Ayland wrote:
Hi all,
I've just done a git pull and rebuilt master on my Mac Mini G4 in order to test
Michael's merge of my KVM PR fix, and unfortunately my kernel now hangs on boot
:(
My last working git che
his series fixes sh and sparc that did not advertise their gigantic page
support and then were not able to allocate and free those pages at runtime.
It renames MEMORY_ISOLATION && COMPACTION || CMA condition into the more
accurate CONTIG_ALLOC, since it allows the definition of alloc_contig_range
f
sh actually supports gigantic pages and selecting
ARCH_HAS_GIGANTIC_PAGE allows it to allocate and free
gigantic pages at runtime.
At least sdk7786_defconfig exposes such a configuration with
huge pages of 64MB, pages of 4KB and MAX_ORDER = 11:
HPAGE_SHIFT (26) - PAGE_SHIFT (12) = 14 >= MAX_ORDER
sparc actually supports gigantic pages and selecting
ARCH_HAS_GIGANTIC_PAGE allows it to allocate and free
gigantic pages at runtime.
sparc allows configuration such as huge pages of 16GB,
pages of 8KB and MAX_ORDER = 13 (default):
HPAGE_SHIFT (34) - PAGE_SHIFT (13) = 21 >= MAX_ORDER (13)
Signed-
This condition allows to define alloc_contig_range, so simplify
it into a more accurate naming.
Suggested-by: Vlastimil Babka
Signed-off-by: Alexandre Ghiti
Acked-by: Vlastimil Babka
---
arch/arm64/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
arch/s390/Kco
On systems without CONTIG_ALLOC activated but that support gigantic pages,
boottime reserved gigantic pages can not be freed at all. This patch
simply enables the possibility to hand back those pages to memory
allocator.
Signed-off-by: Alexandre Ghiti
Acked-by: David S. Miller [sparc]
---
arch/
On 17/03/2019 16:25, christophe leroy wrote:
>> This was a weird one: bisecting directly from git master gave a nonsense
>> result,
>> however by manually rebasing Michael's PR onto my last known good commit
>> from master
>> I was able to finally pin it down to this commit:
>>
>>
>> 7a0d6955f3f
Le 17/03/2019 à 17:28, Alexandre Ghiti a écrit :
On systems without CONTIG_ALLOC activated but that support gigantic pages,
boottime reserved gigantic pages can not be freed at all. This patch
simply enables the possibility to hand back those pages to memory
allocator.
Signed-off-by: Alexandr
pte_unmap() compiles away on some powerpc platforms, so silence the
warnings below by making it a static inline function.
mm/memory.c: In function 'copy_pte_range':
mm/memory.c:820:24: warning: variable 'orig_dst_pte' set but not used
[-Wunused-but-set-variable]
mm/memory.c:820:9: warning: variabl
This argument is required to extend the generic ptrace API with
PTRACE_GET_SYSCALL_INFO request: syscall_get_arch() is going
to be called from ptrace_request() along with syscall_get_nr(),
syscall_get_arguments(), syscall_get_error(), and
syscall_get_return_value() functions with a tracee as their
On Fri, Mar 15, 2019 at 01:05:54PM +0100, Cédric Le Goater wrote:
> This is the basic framework for the new KVM device supporting the XIVE
> native exploitation mode. The user interface exposes a new KVM device
> to be created by QEMU, only available when running on a L0 hypervisor
> only. Support
On 13/3/19 3:06 pm, Alastair D'Silva wrote:
From: Alastair D'Silva
The term 'link' is ambiguous (especially when the struct is used for a
list), so rename it for clarity.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
Acked-by: Andrew Donnellan
(In future please include a changel
On Fri, Mar 15, 2019 at 01:05:55PM +0100, Cédric Le Goater wrote:
> The user interface exposes a new capability KVM_CAP_PPC_IRQ_XIVE to
> let QEMU connect the vCPU presenters to the XIVE KVM device if
> required. The capability is not advertised for now as the full support
> for the XIVE native exp
On Fri, Mar 15, 2019 at 01:05:56PM +0100, Cédric Le Goater wrote:
> The XIVE KVM device maintains a list of interrupt sources for the VM
> which are allocated in the pool of generic interrupts (IPIs) of the
> main XIVE IC controller. These are used for the CPU IPIs as well as
> for virtual device i
From: Ira Weiny
Resending after rebasing to the latest mm tree.
HFI1, qib, and mthca, use get_user_pages_fast() due to it performance
advantages. These pages can be held for a significant time. But
get_user_pages_fast() does not protect against mapping FS DAX pages.
Introduce FOLL_LONGTERM an
From: Ira Weiny
Rather than have a separate get_user_pages_longterm() call,
introduce FOLL_LONGTERM and change the longterm callers to use
it.
This patch does not change any functionality.
FOLL_LONGTERM can only be supported with get_user_pages() as it
requires vmas to determine if DAX is in us
From: Ira Weiny
In order to support more options in the GUP fast walk, change
the write parameter to flags throughout the call stack.
This patch does not change functionality and passes FOLL_WRITE
where write was previously used.
Signed-off-by: Ira Weiny
---
mm/gup.c | 52
From: Ira Weiny
To facilitate additional options to get_user_pages_fast() change the
singular write parameter to be gup_flags.
This patch does not change any functionality. New functionality will
follow in subsequent patches.
Some of the get_user_pages_fast() call sites were unchanged because
From: Ira Weiny
DAX pages were previously unprotected from longterm pins when users
called get_user_pages_fast().
Use the new FOLL_LONGTERM flag to check for DEVMAP pages and fall
back to regular GUP processing if a DEVMAP page is encountered.
Signed-off-by: Ira Weiny
---
mm/gup.c | 29 ++
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/hfi1/user_pages.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/user_pages.
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/qib/qib_user_sdma.c
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/mthca/mthca_memfree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_memf
On Fri, Mar 15, 2019 at 01:05:59PM +0100, Cédric Le Goater wrote:
> This control is to be used by the H_INT_RESET hcall from QEMU. Its
> purpose is to clear all configuration of the sources and EQs. This is
> necessary in case of a kexec (for a kdump kernel for instance) to make
> sure that no rema
On Fri, Mar 15, 2019 at 01:06:03PM +0100, Cédric Le Goater wrote:
> Some KVM devices will want to handle special mappings related to the
> underlying HW. For instance, the XIVE interrupt controller of the
> POWER9 processor has MMIO pages for thread interrupt management and
> for interrupt source c
On Fri, Mar 15, 2019 at 01:06:01PM +0100, Cédric Le Goater wrote:
> When migration of a VM is initiated, a first copy of the RAM is
> transferred to the destination before the VM is stopped, but there is
> no guarantee that the EQ pages in which the event notifications are
> queued have not been mo
On Fri, Mar 15, 2019 at 01:05:58PM +0100, Cédric Le Goater wrote:
> These controls will be used by the H_INT_SET_QUEUE_CONFIG and
> H_INT_GET_QUEUE_CONFIG hcalls from QEMU to configure the underlying
> Event Queue in the XIVE IC. They will also be used to restore the
> configuration of the XIVE EQs
On Fri, Mar 15, 2019 at 01:06:00PM +0100, Cédric Le Goater wrote:
> This control will be used by the H_INT_SYNC hcall from QEMU to flush
> event notifications on the XIVE IC owning the source.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: David Gibson
> ---
>
> Changes since v2 :
>
> -
Daniel Axtens writes:
> The original assembly imported from OpenSSL has two copy-paste
> errors in handling CTR mode. When dealing with a 2 or 3 block tail,
> the code branches to the CBC decryption exit path, rather than to
> the CTR exit path.
>
> This leads to corruption of the IV, which leads
On Fri, Mar 15, 2019 at 01:06:07PM +0100, Cédric Le Goater wrote:
> Full support for the XIVE native exploitation mode is now available,
> advertise the capability KVM_CAP_PPC_IRQ_XIVE for guests running on
> PowerNV KVM Hypervisors only. Support for nested guests (pseries KVM
> Hypervisor) is not
On Fri, Mar 15, 2019 at 01:06:08PM +0100, Cédric Le Goater wrote:
> The 'destroy' method is currently used to destroy all devices when the
> VM is destroyed after the vCPUs have been freed.
>
> This new KVM ioctl exposes the same KVM device method. It acts as a
> software reset of the VM to 'destr
39 matches
Mail list logo
