* [Bug 204375] kernel 5.2.4 w. KASAN enabled fails to boot on a PowerMac G4 3,6 at very early stage
From: bugzilla-daemon @ 2019-08-09 12:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-204375-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=204375
Michael Ellerman (michael@ellerman.id.au) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
CC| |michael@ellerman.id.au
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [Bug 204371] BUG kmalloc-4k (Tainted: G W ): Object padding overwritten
From: Michael Ellerman @ 2019-08-09 12:31 UTC (permalink / raw)
To: bugzilla-daemon, linuxppc-dev, linux-btrfs
In-Reply-To: <bug-204371-206035-3TOBxXIdie@https.bugzilla.kernel.org/>
bugzilla-daemon@bugzilla.kernel.org writes:
> https://bugzilla.kernel.org/show_bug.cgi?id=204371
>
> --- Comment #10 from David Sterba (dsterba@suse.com) ---
> In my case it happened on 5.3-rc3, with a strestest. The same machine has been
> running fstests periodically, with slab debug on, but there are no slab reports
> like that.
>
> [ 8516.870046] BUG kmalloc-4k (Not tainted): Poison overwritten
> [ 8516.875873]
> -----------------------------------------------------------------------------
>
> [ 8516.885864] Disabling lock debugging due to kernel taint
> [ 8516.891312] INFO: 0x000000001c70c8c9-0x000000003cd1e164. First byte 0x16
> instead of 0x6b
> [ 8516.899717] INFO: Allocated in btrfs_read_tree_root+0x46/0x120 [btrfs]
> age=1769 cpu=7 pid=8717
> [ 8516.908544] __slab_alloc.isra.53+0x3e/0x70
> [ 8516.912861] kmem_cache_alloc_trace+0x1b0/0x330
> [ 8516.917581] btrfs_read_tree_root+0x46/0x120 [btrfs]
> [ 8516.922737] btrfs_read_fs_root+0xe/0x40 [btrfs]
> [ 8516.927552] create_reloc_root+0x17f/0x2a0 [btrfs]
> [ 8516.932536] btrfs_init_reloc_root+0x72/0xe0 [btrfs]
> [ 8516.937686] record_root_in_trans+0xbb/0xf0 [btrfs]
> [ 8516.942750] btrfs_record_root_in_trans+0x50/0x70 [btrfs]
> [ 8516.948340] start_transaction+0xa1/0x550 [btrfs]
> [ 8516.953237] __btrfs_prealloc_file_range+0xca/0x490 [btrfs]
> [ 8516.959003] btrfs_prealloc_file_range+0x10/0x20 [btrfs]
> [ 8516.964509] prealloc_file_extent_cluster+0x13e/0x2b0 [btrfs]
> [ 8516.970447] relocate_file_extent_cluster+0x8d/0x530 [btrfs]
> [ 8516.976305] relocate_data_extent+0x80/0x110 [btrfs]
> [ 8516.981469] relocate_block_group+0x473/0x720 [btrfs]
> [ 8516.986711] btrfs_relocate_block_group+0x15f/0x2c0 [btrfs]
So this is looking more like it could be a btrfs bug, given you've both
hit it using btrfs but on different platforms.
cheers
^ permalink raw reply
* [Bug 204371] BUG kmalloc-4k (Tainted: G W ): Object padding overwritten
From: bugzilla-daemon @ 2019-08-09 12:31 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-204371-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #11 from mpe@ellerman.id.au ---
bugzilla-daemon@bugzilla.kernel.org writes:
> https://bugzilla.kernel.org/show_bug.cgi?id=204371
>
> --- Comment #10 from David Sterba (dsterba@suse.com) ---
> In my case it happened on 5.3-rc3, with a strestest. The same machine has
> been
> running fstests periodically, with slab debug on, but there are no slab
> reports
> like that.
>
> [ 8516.870046] BUG kmalloc-4k (Not tainted): Poison overwritten
> [ 8516.875873]
> -----------------------------------------------------------------------------
>
> [ 8516.885864] Disabling lock debugging due to kernel taint
> [ 8516.891312] INFO: 0x000000001c70c8c9-0x000000003cd1e164. First byte 0x16
> instead of 0x6b
> [ 8516.899717] INFO: Allocated in btrfs_read_tree_root+0x46/0x120 [btrfs]
> age=1769 cpu=7 pid=8717
> [ 8516.908544] __slab_alloc.isra.53+0x3e/0x70
> [ 8516.912861] kmem_cache_alloc_trace+0x1b0/0x330
> [ 8516.917581] btrfs_read_tree_root+0x46/0x120 [btrfs]
> [ 8516.922737] btrfs_read_fs_root+0xe/0x40 [btrfs]
> [ 8516.927552] create_reloc_root+0x17f/0x2a0 [btrfs]
> [ 8516.932536] btrfs_init_reloc_root+0x72/0xe0 [btrfs]
> [ 8516.937686] record_root_in_trans+0xbb/0xf0 [btrfs]
> [ 8516.942750] btrfs_record_root_in_trans+0x50/0x70 [btrfs]
> [ 8516.948340] start_transaction+0xa1/0x550 [btrfs]
> [ 8516.953237] __btrfs_prealloc_file_range+0xca/0x490 [btrfs]
> [ 8516.959003] btrfs_prealloc_file_range+0x10/0x20 [btrfs]
> [ 8516.964509] prealloc_file_extent_cluster+0x13e/0x2b0 [btrfs]
> [ 8516.970447] relocate_file_extent_cluster+0x8d/0x530 [btrfs]
> [ 8516.976305] relocate_data_extent+0x80/0x110 [btrfs]
> [ 8516.981469] relocate_block_group+0x473/0x720 [btrfs]
> [ 8516.986711] btrfs_relocate_block_group+0x15f/0x2c0 [btrfs]
So this is looking more like it could be a btrfs bug, given you've both
hit it using btrfs but on different platforms.
cheers
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Use refcount_t for refcount
From: Michael Ellerman @ 2019-08-09 12:36 UTC (permalink / raw)
To: Chuhong Yuan; +Cc: Chuhong Yuan, Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <20190808071808.6531-1-hslester96@gmail.com>
Chuhong Yuan <hslester96@gmail.com> writes:
> Reference counters are preferred to use refcount_t instead of
> atomic_t.
> This is because the implementation of refcount_t can prevent
> overflows and detect possible use-after-free.
> So convert atomic_t ref counters to refcount_t.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Thanks.
We don't have a fast implementation of refcount_t, so I'm worried this
could cause a measurable performance regression.
Did you benchmark it at all?
cheers
> diff --git a/arch/powerpc/mm/book3s64/mmu_context.c b/arch/powerpc/mm/book3s64/mmu_context.c
> index 2d0cb5ba9a47..f836fd5a6abc 100644
> --- a/arch/powerpc/mm/book3s64/mmu_context.c
> +++ b/arch/powerpc/mm/book3s64/mmu_context.c
> @@ -231,7 +231,7 @@ static void pmd_frag_destroy(void *pmd_frag)
> /* drop all the pending references */
> count = ((unsigned long)pmd_frag & ~PAGE_MASK) >> PMD_FRAG_SIZE_SHIFT;
> /* We allow PTE_FRAG_NR fragments from a PTE page */
> - if (atomic_sub_and_test(PMD_FRAG_NR - count, &page->pt_frag_refcount)) {
> + if (refcount_sub_and_test(PMD_FRAG_NR - count, &page->pt_frag_refcount)) {
> pgtable_pmd_page_dtor(page);
> __free_page(page);
> }
> diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
> index 7d0e0d0d22c4..40056896ce4e 100644
> --- a/arch/powerpc/mm/book3s64/pgtable.c
> +++ b/arch/powerpc/mm/book3s64/pgtable.c
> @@ -277,7 +277,7 @@ static pmd_t *__alloc_for_pmdcache(struct mm_struct *mm)
> return NULL;
> }
>
> - atomic_set(&page->pt_frag_refcount, 1);
> + refcount_set(&page->pt_frag_refcount, 1);
>
> ret = page_address(page);
> /*
> @@ -294,7 +294,7 @@ static pmd_t *__alloc_for_pmdcache(struct mm_struct *mm)
> * count.
> */
> if (likely(!mm->context.pmd_frag)) {
> - atomic_set(&page->pt_frag_refcount, PMD_FRAG_NR);
> + refcount_set(&page->pt_frag_refcount, PMD_FRAG_NR);
> mm->context.pmd_frag = ret + PMD_FRAG_SIZE;
> }
> spin_unlock(&mm->page_table_lock);
> @@ -317,8 +317,7 @@ void pmd_fragment_free(unsigned long *pmd)
> {
> struct page *page = virt_to_page(pmd);
>
> - BUG_ON(atomic_read(&page->pt_frag_refcount) <= 0);
> - if (atomic_dec_and_test(&page->pt_frag_refcount)) {
> + if (refcount_dec_and_test(&page->pt_frag_refcount)) {
> pgtable_pmd_page_dtor(page);
> __free_page(page);
> }
> diff --git a/arch/powerpc/mm/pgtable-frag.c b/arch/powerpc/mm/pgtable-frag.c
> index a7b05214760c..4ef8231b677f 100644
> --- a/arch/powerpc/mm/pgtable-frag.c
> +++ b/arch/powerpc/mm/pgtable-frag.c
> @@ -24,7 +24,7 @@ void pte_frag_destroy(void *pte_frag)
> /* drop all the pending references */
> count = ((unsigned long)pte_frag & ~PAGE_MASK) >> PTE_FRAG_SIZE_SHIFT;
> /* We allow PTE_FRAG_NR fragments from a PTE page */
> - if (atomic_sub_and_test(PTE_FRAG_NR - count, &page->pt_frag_refcount)) {
> + if (refcount_sub_and_test(PTE_FRAG_NR - count, &page->pt_frag_refcount)) {
> pgtable_page_dtor(page);
> __free_page(page);
> }
> @@ -71,7 +71,7 @@ static pte_t *__alloc_for_ptecache(struct mm_struct *mm, int kernel)
> return NULL;
> }
>
> - atomic_set(&page->pt_frag_refcount, 1);
> + refcount_set(&page->pt_frag_refcount, 1);
>
> ret = page_address(page);
> /*
> @@ -87,7 +87,7 @@ static pte_t *__alloc_for_ptecache(struct mm_struct *mm, int kernel)
> * count.
> */
> if (likely(!pte_frag_get(&mm->context))) {
> - atomic_set(&page->pt_frag_refcount, PTE_FRAG_NR);
> + refcount_set(&page->pt_frag_refcount, PTE_FRAG_NR);
> pte_frag_set(&mm->context, ret + PTE_FRAG_SIZE);
> }
> spin_unlock(&mm->page_table_lock);
> @@ -110,8 +110,7 @@ void pte_fragment_free(unsigned long *table, int kernel)
> {
> struct page *page = virt_to_page(table);
>
> - BUG_ON(atomic_read(&page->pt_frag_refcount) <= 0);
> - if (atomic_dec_and_test(&page->pt_frag_refcount)) {
> + if (refcount_dec_and_test(&page->pt_frag_refcount)) {
> if (!kernel)
> pgtable_page_dtor(page);
> __free_page(page);
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 3a37a89eb7a7..7fe23a3faf95 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -14,6 +14,7 @@
> #include <linux/uprobes.h>
> #include <linux/page-flags-layout.h>
> #include <linux/workqueue.h>
> +#include <linux/refcount.h>
>
> #include <asm/mmu.h>
>
> @@ -147,7 +148,7 @@ struct page {
> unsigned long _pt_pad_2; /* mapping */
> union {
> struct mm_struct *pt_mm; /* x86 pgds only */
> - atomic_t pt_frag_refcount; /* powerpc */
> + refcount_t pt_frag_refcount; /* powerpc */
> };
> #if ALLOC_SPLIT_PTLOCKS
> spinlock_t *ptl;
> --
> 2.20.1
^ permalink raw reply
* Re: [PATCH v5 1/7] Documentation/powerpc: Ultravisor API
From: Michael Ellerman @ 2019-08-09 12:45 UTC (permalink / raw)
To: Claudio Carvalho, linuxppc-dev
Cc: Madhavan Srinivasan, Michael Anderson, Ram Pai, Claudio Carvalho,
kvm-ppc, Bharata B Rao, Ryan Grimm, Ram Pai, Sukadev Bhattiprolu,
Sukadev Bhattiprolu, Guerney Hunt, Thiago Bauermann
In-Reply-To: <20190808040555.2371-2-cclaudio@linux.ibm.com>
Claudio Carvalho <cclaudio@linux.ibm.com> writes:
> From: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
>
> POWER9 processor includes support for Protected Execution Facility (PEF).
Which POWER9? Please be more precise.
It's public knowledge that some versions of Power9 don't have PEF (or
have it broken / fused off).
People are going to try and test this on various chip revisions that are
out in the wild, we need to make it clear where it's expected to work
and where it's not.
> Attached documentation provides an overview of PEF and defines the API
> for various interfaces that must be implemented in the Ultravisor
> firmware as well as in the KVM Hypervisor.
>
> Based on input from Mike Anderson, Thiago Bauermann, Claudio Carvalho,
> Ben Herrenschmidt, Guerney Hunt, Paul Mackerras.
>
> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
> Signed-off-by: Ram Pai <linuxram@linux.ibm.com>
> Signed-off-by: Guerney Hunt <gdhh@linux.ibm.com>
> Reviewed-by: Claudio Carvalho <cclaudio@linux.ibm.com>
> Reviewed-by: Michael Anderson <andmike@linux.ibm.com>
> Reviewed-by: Thiago Bauermann <bauerman@linux.ibm.com>
> Signed-off-by: Claudio Carvalho <cclaudio@linux.ibm.com>
> ---
> Documentation/powerpc/ultravisor.rst | 1055 ++++++++++++++++++++++++++
> 1 file changed, 1055 insertions(+)
> create mode 100644 Documentation/powerpc/ultravisor.rst
>
> diff --git a/Documentation/powerpc/ultravisor.rst b/Documentation/powerpc/ultravisor.rst
> new file mode 100644
> index 000000000000..8d5246585b66
> --- /dev/null
> +++ b/Documentation/powerpc/ultravisor.rst
> @@ -0,0 +1,1055 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +.. _ultravisor:
> +
> +============================
> +Protected Execution Facility
> +============================
> +
> +.. contents::
> + :depth: 3
> +
> +.. sectnum::
> + :depth: 3
> +
> +Protected Execution Facility
> +############################
> +
> + Protected Execution Facility (PEF) is an architectural change for
> + POWER 9 that enables Secure Virtual Machines (SVMs). When enabled,
Ditto here.
Also you don't mention which ISA version PEF is (will be) documented in.
Do we know? Or can we at least reference the RFC number so folks can
find it.
Otherwise this looks really good. I'll try and find time to proof read
it thoroughly.
cheers
> + PEF adds a new higher privileged mode, called Ultravisor mode, to
> + POWER architecture. Along with the new mode there is new firmware
> + called the Protected Execution Ultravisor (or Ultravisor for short).
> + Ultravisor mode is the highest privileged mode in POWER architecture.
> +
> + +------------------+
> + | Privilege States |
> + +==================+
> + | Problem |
> + +------------------+
> + | Supervisor |
> + +------------------+
> + | Hypervisor |
> + +------------------+
> + | Ultravisor |
> + +------------------+
> +
> + PEF protects SVMs from the hypervisor, privileged users, and other
> + VMs in the system. SVMs are protected while at rest and can only be
> + executed by an authorized machine. All virtual machines utilize
> + hypervisor services. The Ultravisor filters calls between the SVMs
> + and the hypervisor to assure that information does not accidentally
> + leak. All hypercalls except H_RANDOM are reflected to the hypervisor.
> + H_RANDOM is not reflected to prevent the hypervisor from influencing
> + random values in the SVM.
> +
> + To support this there is a refactoring of the ownership of resources
> + in the CPU. Some of the resources which were previously hypervisor
> + privileged are now ultravisor privileged.
> +
> +Hardware
> +========
> +
> + The hardware changes include the following:
> +
> + * There is a new bit in the MSR that determines whether the current
> + process is running in secure mode, MSR(S) bit 41. MSR(S)=1, process
> + is in secure mode, MSR(s)=0 process is in normal mode.
> +
> + * The MSR(S) bit can only be set by the Ultravisor.
> +
> + * HRFID cannot be used to set the MSR(S) bit. If the hypervisor needs
> + to return to a SVM it must use an ultracall. It can determine if
> + the VM it is returning to is secure.
> +
> + * There is a new Ultravisor privileged register, SMFCTRL, which has an
> + enable/disable bit SMFCTRL(E).
> +
> + * The privilege of a process is now determined by three MSR bits,
> + MSR(S, HV, PR). In each of the tables below the modes are listed
> + from least privilege to highest privilege. The higher privilege
> + modes can access all the resources of the lower privilege modes.
> +
> + **Secure Mode MSR Settings**
> +
> + +---+---+---+---------------+
> + | S | HV| PR|Privilege |
> + +===+===+===+===============+
> + | 1 | 0 | 1 | Problem |
> + +---+---+---+---------------+
> + | 1 | 0 | 0 | Privileged(OS)|
> + +---+---+---+---------------+
> + | 1 | 1 | 0 | Ultravisor |
> + +---+---+---+---------------+
> + | 1 | 1 | 1 | Reserved |
> + +---+---+---+---------------+
> +
> + **Normal Mode MSR Settings**
> +
> + +---+---+---+---------------+
> + | S | HV| PR|Privilege |
> + +===+===+===+===============+
> + | 0 | 0 | 1 | Problem |
> + +---+---+---+---------------+
> + | 0 | 0 | 0 | Privileged(OS)|
> + +---+---+---+---------------+
> + | 0 | 1 | 0 | Hypervisor |
> + +---+---+---+---------------+
> + | 0 | 1 | 1 | Problem (HV) |
> + +---+---+---+---------------+
> +
> + * Memory is partitioned into secure and normal memory. Only processes
> + that are running in secure mode can access secure memory.
> +
> + * The hardware does not allow anything that is not running secure to
> + access secure memory. This means that the Hypervisor cannot access
> + the memory of the SVM without using an ultracall (asking the
> + Ultravisor). The Ultravisor will only allow the hypervisor to see
> + the SVM memory encrypted.
> +
> + * I/O systems are not allowed to directly address secure memory. This
> + limits the SVMs to virtual I/O only.
> +
> + * The architecture allows the SVM to share pages of memory with the
> + hypervisor that are not protected with encryption. However, this
> + sharing must be initiated by the SVM.
> +
> + * When a process is running in secure mode all hypercalls
> + (syscall lev=1) are reflected to the Ultravisor.
> +
> + * When a process is in secure mode all interrupts go to the
> + Ultravisor.
> +
> + * The following resources have become Ultravisor privileged and
> + require an Ultravisor interface to manipulate:
> +
> + * Processor configurations registers (SCOMs).
> +
> + * Stop state information.
> +
> + * The debug registers CIABR, DAWR, and DAWRX become Ultravisor
> + resources when SMFCTRL(D) is set. If SMFCTRL(D) is not set they do
> + not work in secure mode. When set, reading and writing requires
> + an Ultravisor call, otherwise that will cause a Hypervisor Emulation
> + Assistance interrupt.
> +
> + * PTCR and partition table entries (partition table is in secure
> + memory). An attempt to write to PTCR will cause a Hypervisor
> + Emulation Assitance interrupt.
> +
> + * LDBAR (LD Base Address Register) and IMC (In-Memory Collection)
> + non-architected registers. An attempt to write to them will cause a
> + Hypervisor Emulation Assistance interrupt.
> +
> + * Paging for an SVM, sharing of memory with Hypervisor for an SVM.
> + (Including Virtual Processor Area (VPA) and virtual I/O).
> +
> +
> +Software/Microcode
> +==================
> +
> + The software changes include:
> +
> + * SVMs are created from normal VM using (open source) tooling supplied
> + by IBM.
> +
> + * All SVMs start as normal VMs and utilize an ultracall, UV_ESM
> + (Enter Secure Mode), to make the transition.
> +
> + * When the UV_ESM ultracall is made the Ultravisor copies the VM into
> + secure memory, decrypts the verification information, and checks the
> + integrity of the SVM. If the integrity check passes the Ultravisor
> + passes control in secure mode.
> +
> + * For external interrupts the Ultravisor saves the state of the SVM,
> + and reflects the interrupt to the hypervisor for processing.
> + For hypercalls, the Ultravisor inserts neutral state into all
> + registers not needed for the hypercall then reflects the call to
> + the hypervisor for processing. The H_RANDOM hypercall is performed
> + by the Ultravisor and not reflected.
> +
> + * The verification information includes the pass phrase for the
> + encrypted disk associated with the SVM. This pass phrase is given
> + to the SVM when requested.
> +
> + * The Ultravisor is not involved in protecting the encrypted disk of
> + the SVM while at rest.
> +
> + * For virtual I/O to work bounce buffering must be done.
> +
> + * The Ultravisor uses AES (IAPM) for protection of SVM memory. IAPM
> + is a mode of AES that provides integrity and secrecy concurrently.
> +
> + * The movement of data between normal and secure pages is coordinated
> + with the Ultravisor by a new HMM plug-in in the Hypervisor.
> +
> + The Ultravisor offers new services to the hypervisor and SVMs. These
> + are accessed through ultracalls.
> +
> +Terminology
> +===========
> +
> + * Hypercalls: special system calls used to request services from
> + Hypervisor.
> +
> + * Normal memory: Memory that is accessible to Hypervisor.
> +
> + * Normal page: Page backed by normal memory and available to
> + Hypervisor.
> +
> + * Shared page: A page backed by normal memory and available to both
> + the Hypervisor/QEMU and the SVM (i.e page has mappings in SVM and
> + Hypervisor/QEMU).
> +
> + * Secure memory: Memory that is accessible only to Ultravisor and
> + SVMs.
> +
> + * Secure page: Page backed by secure memory and only available to
> + Ultravisor and SVM.
> +
> + * SVM: Secure Virtual Machine.
> +
> + * Ultracalls: special system calls used to request services from
> + Ultravisor.
> +
> +
> +Ultravisor calls API
> +####################
> +
> + This section describes Ultravisor calls (ultracalls) needed to
> + support Secure Virtual Machines (SVM)s and Paravirtalized KVM. The
> + ultracalls allow the SVMs and Hypervisor to request services from the
> + Ultravisor such as accessing a register or memory region that can only
> + be accessed when running in Ultravisor-privileged mode.
> +
> + The specific service needed from an ultracall is specified in register
> + R3 (the first parameter to the ultracall). Other parameters to the
> + ultracall, if any, are specified in registers R4 through R12.
> +
> + Return value of all ultracalls is in register R3. Other output values
> + from the ultracall, if any, are returned in registers R4 through R12.
> + The only exception to this register usage is the ``UV_RETURN``
> + ultracall described below.
> +
> + Each ultracall returns specific error codes, applicable in the context
> + of the ultracall. However, like with the PowerPC Architecture Platform
> + Reference (PAPR), if no specific error code is defined for a
> + particular situation, then the ultracall will fallback to an erroneous
> + parameter-position based code. i.e U_PARAMETER, U_P2, U_P3 etc
> + depending on the ultracall parameter that may have caused the error.
> +
> + Some ultracalls involve transferring a page of data between Ultravisor
> + and Hypervisor. Secure pages that are transferred from secure memory
> + to normal memory may be encrypted using dynamically generated keys.
> + When the secure pages are transferred back to secure memory, they may
> + be decrypted using the same dynamically generated keys. Generation and
> + management of these keys will be covered in a separate document.
> +
> + For now this only covers ultracalls currently implemented and being
> + used by Hypervisor and SVMs but others can be added here when it
> + makes sense.
> +
> + The full specification for all hypercalls/ultracalls will eventually
> + be made available in the public/OpenPower version of the PAPR
> + specification.
> +
> + **Note**
> +
> + If PEF is not enabled, the ultracalls will be redirected to the
> + Hypervisor which must handle/fail the calls.
> +
> +Ultracalls used by Hypervisor
> +=============================
> +
> + This section describes the virtual memory management ultracalls used
> + by the Hypervisor to manage SVMs.
> +
> +UV_PAGE_OUT
> +-----------
> +
> + Encrypt and move the contents of a page from secure memory to normal
> + memory.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t ultracall(const uint64_t UV_PAGE_OUT,
> + uint16_t lpid, /* LPAR ID */
> + uint64_t dest_ra, /* real address of destination page */
> + uint64_t src_gpa, /* source guest-physical-address */
> + uint8_t flags, /* flags */
> + uint64_t order) /* page size order */
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * U_SUCCESS on success.
> + * U_PARAMETER if ``lpid`` is invalid.
> + * U_P2 if ``dest_ra`` is invalid.
> + * U_P3 if the ``src_gpa`` address is invalid.
> + * U_P4 if any bit in the ``flags`` is unrecognized
> + * U_P5 if the ``order`` parameter is unsupported.
> + * U_FUNCTION if functionality is not supported.
> + * U_BUSY if page cannot be currently paged-out.
> +
> +Description
> +~~~~~~~~~~~
> +
> + Encrypt the contents of a secure-page and make it available to
> + Hypervisor in a normal page.
> +
> + By default, the source page is unmapped from the SVM's partition-
> + scoped page table. But the Hypervisor can provide a hint to the
> + Ultravisor to retain the page mapping by setting the ``UV_SNAPSHOT``
> + flag in ``flags`` parameter.
> +
> + If the source page is already a shared page the call returns
> + U_SUCCESS, without doing anything.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. QEMU attempts to access an address belonging to the SVM but the
> + page frame for that address is not mapped into QEMU's address
> + space. In this case, the Hypervisor will allocate a page frame,
> + map it into QEMU's address space and issue the ``UV_PAGE_OUT``
> + call to retrieve the encrypted contents of the page.
> +
> + #. When Ultravisor runs low on secure memory and it needs to page-out
> + an LRU page. In this case, Ultravisor will issue the
> + ``H_SVM_PAGE_OUT`` hypercall to the Hypervisor. The Hypervisor will
> + then allocate a normal page and issue the ``UV_PAGE_OUT`` ultracall
> + and the Ultravisor will encrypt and move the contents of the secure
> + page into the normal page.
> +
> +
> +UV_PAGE_IN
> +----------
> +
> + Move the contents of a page from normal memory to secure memory.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t ultracall(const uint64_t UV_PAGE_IN,
> + uint16_t lpid, /* the LPAR ID */
> + uint64_t src_ra, /* source real address of page */
> + uint64_t dest_gpa, /* destination guest physical address */
> + uint64_t flags, /* flags */
> + uint64_t order) /* page size order */
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * U_SUCCESS on success.
> + * U_BUSY if page cannot be currently paged-in.
> + * U_FUNCTION if functionality is not supported
> + * U_PARAMETER if ``lpid`` is invalid.
> + * U_P2 if ``src_ra`` is invalid.
> + * U_P3 if the ``dest_gpa`` address is invalid.
> + * U_P4 if any bit in the ``flags`` is unrecognized
> + * U_P5 if the ``order`` parameter is unsupported.
> +
> +Description
> +~~~~~~~~~~~
> +
> + Move the contents of the page identified by ``src_ra`` from normal
> + memory to secure memory and map it to the guest physical address
> + ``dest_gpa``.
> +
> + If `dest_gpa` refers to a shared address, map the page into the
> + partition-scoped page-table of the SVM. If `dest_gpa` is not shared,
> + copy the contents of the page into the corresponding secure page.
> + Depending on the context, decrypt the page before being copied.
> +
> + The caller provides the attributes of the page through the ``flags``
> + parameter. Valid values for ``flags`` are:
> +
> + * CACHE_INHIBITED
> + * CACHE_ENABLED
> + * WRITE_PROTECTION
> +
> + The Hypervisor must pin the page in memory before making
> + ``UV_PAGE_IN`` ultracall.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. When a normal VM switches to secure mode, all its pages residing
> + in normal memory, are moved into secure memory.
> +
> + #. When an SVM requests to share a page with Hypervisor the Hypervisor
> + allocates a page and informs the Ultravisor.
> +
> + #. When an SVM accesses a secure page that has been paged-out,
> + Ultravisor invokes the Hypervisor to locate the page. After
> + locating the page, the Hypervisor uses UV_PAGE_IN to make the
> + page available to Ultravisor.
> +
> + #. When Hypervisor accesses SVM data, the Hypervisor requests the
> + Ultravisor to transfer the corresponding page into a insecure page,
> + which the Hypervisor can access. The data in the normal page will
> + be encrypted though.
> +
> +UV_PAGE_INVAL
> +-------------
> +
> + Invalidate the Ultravisor mapping of a page.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t ultracall(const uint64_t UV_PAGE_INVAL,
> + uint16_t lpid, /* the LPAR ID */
> + uint64_t guest_pa, /* destination guest-physical-address */
> + uint64_t order) /* page size order */
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * U_SUCCESS on success.
> + * U_PARAMETER if ``lpid`` is invalid.
> + * U_P2 if ``guest_pa`` is invalid (or corresponds to a secure
> + page mapping).
> + * U_P3 if the ``order`` is invalid.
> + * U_FUNCTION if functionality is not supported.
> + * U_BUSY if page cannot be currently invalidated.
> +
> +Description
> +~~~~~~~~~~~
> +
> + This ultracall informs Ultravisor that the page mapping in Hypervisor
> + corresponding to the given guest physical address has been invalidated
> + and that the Ultravisor should not access the page. If the specified
> + ``guest_pa`` corresponds to a secure page, Ultravisor will ignore the
> + attempt to invalidate the page and return U_P2.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. When a shared page is unmapped from the QEMU's page table, possibly
> + because it is paged-out to disk, Ultravisor needs to know that the
> + page should not be accessed from its side too.
> +
> +
> +UV_WRITE_PATE
> +-------------
> +
> + Validate and write the partition table entry (PATE) for a given
> + partition.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t ultracall(const uint64_t UV_WRITE_PATE,
> + uint32_t lpid, /* the LPAR ID */
> + uint64_t dw0 /* the first double word to write */
> + uint64_t dw1) /* the second double word to write */
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * U_SUCCESS on success.
> + * U_BUSY if PATE cannot be currently written to.
> + * U_FUNCTION if functionality is not supported.
> + * U_PARAMETER if ``lpid`` is invalid.
> + * U_P2 if ``dw0`` is invalid.
> + * U_P3 if the ``dw1`` address is invalid.
> + * U_PERMISSION if the Hypervisor is attempting to change the PATE
> + of a secure virtual machine or if called from a
> + context other than Hypervisor.
> +
> +Description
> +~~~~~~~~~~~
> +
> + Validate and write a LPID and its partition-table-entry for the given
> + LPID. If the LPID is already allocated and initialized, this call
> + results in changing the partition table entry.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. The Partition table resides in Secure memory and its entries,
> + called PATE (Partition Table Entries), point to the partition-
> + scoped page tables for the Hypervisor as well as each of the
> + virtual machines (both secure and normal). The Hypervisor
> + operates in partition 0 and its partition-scoped page tables
> + reside in normal memory.
> +
> + #. This ultracall allows the Hypervisor to register the partition-
> + scoped and process-scoped page table entries for the Hypervisor
> + and other partitions (virtual machines) with the Ultravisor.
> +
> + #. If the value of the PATE for an existing partition (VM) changes,
> + the TLB cache for the partition is flushed.
> +
> + #. The Hypervisor is responsible for allocating LPID. The LPID and
> + its PATE entry are registered together. The Hypervisor manages
> + the PATE entries for a normal VM and can change the PATE entry
> + anytime. Ultravisor manages the PATE entries for an SVM and
> + Hypervisor is not allowed to modify them.
> +
> +UV_RETURN
> +---------
> +
> + Return control from the Hypervisor back to the Ultravisor after
> + processing an hypercall or interrupt that was forwarded (aka
> + *reflected*) to the Hypervisor.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t ultracall(const uint64_t UV_RETURN)
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + This call never returns to Hypervisor on success. It returns
> + U_INVALID if ultracall is not made from a Hypervisor context.
> +
> +Description
> +~~~~~~~~~~~
> +
> + When an SVM makes an hypercall or incurs some other exception, the
> + Ultravisor usually forwards (aka *reflects*) the exceptions to the
> + Hypervisor. After processing the exception, Hypervisor uses the
> + ``UV_RETURN`` ultracall to return control back to the SVM.
> +
> + The expected register state on entry to this ultracall is:
> +
> + * Non-volatile registers are restored to their original values.
> + * If returning from an hypercall, register R0 contains the return
> + value (**unlike other ultracalls**) and, registers R4 through R12
> + contain any output values of the hypercall.
> + * R3 contains the ultracall number, i.e UV_RETURN.
> + * If returning with a synthesized interrupt, R2 contains the
> + synthesized interrupt number.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. Ultravisor relies on the Hypervisor to provide several services to
> + the SVM such as processing hypercall and other exceptions. After
> + processing the exception, Hypervisor uses UV_RETURN to return
> + control back to the Ultravisor.
> +
> + #. Hypervisor has to use this ultracall to return control to the SVM.
> +
> +
> +UV_REGISTER_MEM_SLOT
> +--------------------
> +
> + Register an SVM address-range with specified properties.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t ultracall(const uint64_t UV_REGISTER_MEM_SLOT,
> + uint64_t lpid, /* LPAR ID of the SVM */
> + uint64_t start_gpa, /* start guest physical address */
> + uint64_t size, /* size of address range in bytes */
> + uint64_t flags /* reserved for future expansion */
> + uint16_t slotid) /* slot identifier */
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * U_SUCCESS on success.
> + * U_PARAMETER if ``lpid`` is invalid.
> + * U_P2 if ``start_gpa`` is invalid.
> + * U_P3 if ``size`` is invalid.
> + * U_P4 if any bit in the ``flags`` is unrecognized.
> + * U_P5 if the ``slotid`` parameter is unsupported.
> + * U_PERMISSION if called from context other than Hypervisor.
> + * U_FUNCTION if functionality is not supported.
> +
> +
> +Description
> +~~~~~~~~~~~
> +
> + Register a memory range for an SVM. The memory range starts at the
> + guest physical address ``start_gpa`` and is ``size`` bytes long.
> +
> +Use cases
> +~~~~~~~~~
> +
> +
> + #. When a virtual machine goes secure, all the memory slots managed by
> + the Hypervisor move into secure memory. The Hypervisor iterates
> + through each of memory slots, and registers the slot with
> + Ultravisor. Hypervisor may discard some slots such as those used
> + for firmware (SLOF).
> +
> + #. When new memory is hot-plugged, a new memory slot gets registered.
> +
> +
> +UV_UNREGISTER_MEM_SLOT
> +----------------------
> +
> + Unregister an SVM address-range that was previously registered using
> + UV_REGISTER_MEM_SLOT.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t ultracall(const uint64_t UV_UNREGISTER_MEM_SLOT,
> + uint64_t lpid, /* LPAR ID of the SVM */
> + uint64_t slotid) /* reservation slotid */
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * U_SUCCESS on success.
> + * U_FUNCTION if functionality is not supported.
> + * U_PARAMETER if ``lpid`` is invalid.
> + * U_P2 if ``slotid`` is invalid.
> + * U_PERMISSION if called from context other than Hypervisor.
> +
> +Description
> +~~~~~~~~~~~
> +
> + Release the memory slot identified by ``slotid`` and free any
> + resources allocated towards the reservation.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. Memory hot-remove.
> +
> +
> +UV_SVM_TERMINATE
> +----------------
> +
> + Terminate an SVM and release its resources.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t ultracall(const uint64_t UV_SVM_TERMINATE,
> + uint64_t lpid, /* LPAR ID of the SVM */)
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * U_SUCCESS on success.
> + * U_FUNCTION if functionality is not supported.
> + * U_PARAMETER if ``lpid`` is invalid.
> + * U_INVALID if VM is not secure.
> + * U_PERMISSION if not called from a Hypervisor context.
> +
> +Description
> +~~~~~~~~~~~
> +
> + Terminate an SVM and release all its resources.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. Called by Hypervisor when terminating an SVM.
> +
> +
> +Ultracalls used by SVM
> +======================
> +
> +UV_SHARE_PAGE
> +-------------
> +
> + Share a set of guest physical pages with the Hypervisor.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t ultracall(const uint64_t UV_SHARE_PAGE,
> + uint64_t gfn, /* guest page frame number */
> + uint64_t num) /* number of pages of size PAGE_SIZE */
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * U_SUCCESS on success.
> + * U_FUNCTION if functionality is not supported.
> + * U_INVALID if the VM is not secure.
> + * U_PARAMETER if ``gfn`` is invalid.
> + * U_P2 if ``num`` is invalid.
> +
> +Description
> +~~~~~~~~~~~
> +
> + Share the ``num`` pages starting at guest physical frame number ``gfn``
> + with the Hypervisor. Assume page size is PAGE_SIZE bytes. Zero the
> + pages before returning.
> +
> + If the address is already backed by a secure page, unmap the page and
> + back it with an insecure page, with the help of the Hypervisor. If it
> + is not backed by any page yet, mark the PTE as insecure and back it
> + with an insecure page when the address is accessed. If it is already
> + backed by an insecure page, zero the page and return.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. The Hypervisor cannot access the SVM pages since they are backed by
> + secure pages. Hence an SVM must explicitly request Ultravisor for
> + pages it can share with Hypervisor.
> +
> + #. Shared pages are needed to support virtio and Virtual Processor Area
> + (VPA) in SVMs.
> +
> +
> +UV_UNSHARE_PAGE
> +---------------
> +
> + Restore a shared SVM page to its initial state.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t ultracall(const uint64_t UV_UNSHARE_PAGE,
> + uint64_t gfn, /* guest page frame number */
> + uint73 num) /* number of pages of size PAGE_SIZE*/
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * U_SUCCESS on success.
> + * U_FUNCTION if functionality is not supported.
> + * U_INVALID if VM is not secure.
> + * U_PARAMETER if ``gfn`` is invalid.
> + * U_P2 if ``num`` is invalid.
> +
> +Description
> +~~~~~~~~~~~
> +
> + Stop sharing ``num`` pages starting at ``gfn`` with the Hypervisor.
> + Assume that the page size is PAGE_SIZE. Zero the pages before
> + returning.
> +
> + If the address is already backed by an insecure page, unmap the page
> + and back it with a secure page. Inform the Hypervisor to release
> + reference to its shared page. If the address is not backed by a page
> + yet, mark the PTE as secure and back it with a secure page when that
> + address is accessed. If it is already backed by an secure page zero
> + the page and return.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. The SVM may decide to unshare a page from the Hypervisor.
> +
> +
> +UV_UNSHARE_ALL_PAGES
> +--------------------
> +
> + Unshare all pages the SVM has shared with Hypervisor.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t ultracall(const uint64_t UV_UNSHARE_ALL_PAGES)
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * U_SUCCESS on success.
> + * U_FUNCTION if functionality is not supported.
> + * U_INVAL if VM is not secure.
> +
> +Description
> +~~~~~~~~~~~
> +
> + Unshare all shared pages from the Hypervisor. All unshared pages are
> + zeroed on return. Only pages explicitly shared by the SVM with the
> + Hypervisor (using UV_SHARE_PAGE ultracall) are unshared. Ultravisor
> + may internally share some pages with the Hypervisor without explicit
> + request from the SVM. These pages will not be unshared by this
> + ultracall.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. This call is needed when ``kexec`` is used to boot a different
> + kernel. It may also be needed during SVM reset.
> +
> +UV_ESM
> +------
> +
> + Secure the virtual machine (*enter secure mode*).
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t ultracall(const uint64_t UV_ESM,
> + uint64_t esm_blob_addr, /* location of the ESM blob */
> + unint64_t fdt) /* Flattened device tree */
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * U_SUCCESS on success (including if VM is already secure).
> + * U_FUNCTION if functionality is not supported.
> + * U_INVALID if VM is not secure.
> + * U_PARAMETER if ``esm_blob_addr`` is invalid.
> + * U_P2 if ``fdt`` is invalid.
> + * U_PERMISSION if any integrity checks fail.
> + * U_RETRY insufficient memory to create SVM.
> + * U_NO_KEY symmetric key unavailable.
> +
> +Description
> +~~~~~~~~~~~
> +
> + Secure the virtual machine. On successful completion, return
> + control to the virtual machine at the address specified in the
> + ESM blob.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. A normal virtual machine can choose to switch to a secure mode.
> +
> +Hypervisor Calls API
> +####################
> +
> + This document describes the Hypervisor calls (hypercalls) that are
> + needed to support the Ultravisor. Hypercalls are services provided by
> + the Hypervisor to virtual machines and Ultravisor.
> +
> + Register usage for these hypercalls is identical to that of the other
> + hypercalls defined in the Power Architecture Platform Reference (PAPR)
> + document. i.e on input, register R3 identifies the specific service
> + that is being requested and registers R4 through R11 contain
> + additional parameters to the hypercall, if any. On output, register
> + R3 contains the return value and registers R4 through R9 contain any
> + other output values from the hypercall.
> +
> + This document only covers hypercalls currently implemented/planned
> + for Ultravisor usage but others can be added here when it makes sense.
> +
> + The full specification for all hypercalls/ultracalls will eventually
> + be made available in the public/OpenPower version of the PAPR
> + specification.
> +
> +Hypervisor calls to support Ultravisor
> +======================================
> +
> + Following are the set of hypercalls needed to support Ultravisor.
> +
> +H_SVM_INIT_START
> +----------------
> +
> + Begin the process of converting a normal virtual machine into an SVM.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t hypercall(const uint64_t H_SVM_INIT_START)
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * H_SUCCESS on success.
> +
> +Description
> +~~~~~~~~~~~
> +
> + Initiate the process of securing a virtual machine. This involves
> + coordinating with the Ultravisor, using ultracalls, to allocate
> + resources in the Ultravisor for the new SVM, transferring the VM's
> + pages from normal to secure memory etc. When the process is
> + completed, Ultravisor issues the H_SVM_INIT_DONE hypercall.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. Ultravisor uses this hypercall to inform Hypervisor that a VM
> + has initiated the process of switching to secure mode.
> +
> +
> +H_SVM_INIT_DONE
> +---------------
> +
> + Complete the process of securing an SVM.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t hypercall(const uint64_t H_SVM_INIT_DONE)
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * H_SUCCESS on success.
> + * H_UNSUPPORTED if called from the wrong context (e.g.
> + from an SVM or before an H_SVM_INIT_START
> + hypercall).
> +
> +Description
> +~~~~~~~~~~~
> +
> + Complete the process of securing a virtual machine. This call must
> + be made after a prior call to ``H_SVM_INIT_START`` hypercall.
> +
> +Use cases
> +~~~~~~~~~
> +
> + On successfully securing a virtual machine, the Ultravisor informs
> + Hypervisor about it. Hypervisor can use this call to finish setting
> + up its internal state for this virtual machine.
> +
> +
> +H_SVM_PAGE_IN
> +-------------
> +
> + Move the contents of a page from normal memory to secure memory.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t hypercall(const uint64_t H_SVM_PAGE_IN,
> + uint64_t guest_pa, /* guest-physical-address */
> + uint64_t flags, /* flags */
> + uint64_t order) /* page size order */
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * H_SUCCESS on success.
> + * H_PARAMETER if ``guest_pa`` is invalid.
> + * H_P2 if ``flags`` is invalid.
> + * H_P3 if ``order`` of page is invalid.
> +
> +Description
> +~~~~~~~~~~~
> +
> + Retrieve the content of the page, belonging to the VM at the specified
> + guest physical address.
> +
> + Only valid value(s) in ``flags`` are:
> +
> + * H_PAGE_IN_SHARED which indicates that the page is to be shared
> + with the Ultravisor.
> +
> + * H_PAGE_IN_NONSHARED indicates that the UV is not anymore
> + interested in the page. Applicable if the page is a shared page.
> +
> + The ``order`` parameter must correspond to the configured page size.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. When a normal VM becomes a secure VM (using the UV_ESM ultracall),
> + the Ultravisor uses this hypercall to move contents of each page of
> + the VM from normal memory to secure memory.
> +
> + #. Ultravisor uses this hypercall to ask Hypervisor to provide a page
> + in normal memory that can be shared between the SVM and Hypervisor.
> +
> + #. Ultravisor uses this hypercall to page-in a paged-out page. This
> + can happen when the SVM touches a paged-out page.
> +
> + #. If SVM wants to disable sharing of pages with Hypervisor, it can
> + inform Ultravisor to do so. Ultravisor will then use this hypercall
> + and inform Hypervisor that it has released access to the normal
> + page.
> +
> +H_SVM_PAGE_OUT
> +---------------
> +
> + Move the contents of the page to normal memory.
> +
> +Syntax
> +~~~~~~
> +
> +.. code-block:: c
> +
> + uint64_t hypercall(const uint64_t H_SVM_PAGE_OUT,
> + uint64_t guest_pa, /* guest-physical-address */
> + uint64_t flags, /* flags (currently none) */
> + uint64_t order) /* page size order */
> +
> +Return values
> +~~~~~~~~~~~~~
> +
> + One of the following values:
> +
> + * H_SUCCESS on success.
> + * H_PARAMETER if ``guest_pa`` is invalid.
> + * H_P2 if ``flags`` is invalid.
> + * H_P3 if ``order`` is invalid.
> +
> +Description
> +~~~~~~~~~~~
> +
> + Move the contents of the page identified by ``guest_pa`` to normal
> + memory.
> +
> + Currently ``flags`` is unused and must be set to 0. The ``order``
> + parameter must correspond to the configured page size.
> +
> +Use cases
> +~~~~~~~~~
> +
> + #. If Ultravisor is running low on secure pages, it can move the
> + contents of some secure pages, into normal pages using this
> + hypercall. The content will be encrypted.
> +
> +References
> +##########
> +
> +.. [1] `Supporting Protected Computing on IBM Power Architecture <https://developer.ibm.com/articles/l-support-protected-computing/>`_
> --
> 2.20.1
^ permalink raw reply
* Re: [PATCH v4 0/6] Remove x86-specific code from generic headers
From: mpe @ 2019-08-09 12:51 UTC (permalink / raw)
To: Thiago Jung Bauermann, x86
Cc: linux-s390, Lianbo Jiang, Konrad Rzeszutek Wilk, Robin Murphy,
Mike Anderson, Ram Pai, linux-kernel, Alexey Dobriyan,
Halil Pasic, iommu, Ingo Molnar, Borislav Petkov, Thomas Lendacky,
H. Peter Anvin, linux-fsdevel, Thomas Gleixner, linuxppc-dev,
Christoph Hellwig, Thiago Jung Bauermann, Marek Szyprowski
In-Reply-To: <20190806044919.10622-1-bauerman@linux.ibm.com>
Thiago Jung Bauermann <bauerman@linux.ibm.com> writes:
> Hello,
>
> This version has only a small change in the last patch as requested by
> Christoph and Halil, and collects Reviewed-by's.
>
> These patches are applied on top of v5.3-rc2.
>
> I don't have a way to test SME, SEV, nor s390's PEF so the patches have only
> been build tested.
I need to take this series via the powerpc tree because there is another
fairly large powerpc specific series dependent on it.
I think this series already has pretty much all the acks it needs, which
almost never happens, amazing work!
I'll put the series in a topic branch, just in case there's any bad
conflicts and other folks want to merge it later on. I'll then merge the
topic branch into my next, and so this series will be tested in
linux-next that way.
cheers
> Changelog
>
> Since v3:
>
> - Patch "s390/mm: Remove sev_active() function"
> - Preserve comment from sev_active() in force_dma_unencrypted().
> Suggested by Christoph Hellwig.
>
> Since v2:
>
> - Patch "x86,s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig"
> - Added "select ARCH_HAS_MEM_ENCRYPT" to config S390. Suggested by Janani.
>
> - Patch "DMA mapping: Move SME handling to x86-specific files"
> - Split up into 3 new patches. Suggested by Christoph Hellwig.
>
> - Patch "swiotlb: Remove call to sme_active()"
> - New patch.
>
> - Patch "dma-mapping: Remove dma_check_mask()"
> - New patch.
>
> - Patch "x86,s390/mm: Move sme_active() and sme_me_mask to x86-specific header"
> - New patch.
> - Removed export of sme_active symbol. Suggested by Christoph Hellwig.
>
> - Patch "fs/core/vmcore: Move sev_active() reference to x86 arch code"
> - Removed export of sev_active symbol. Suggested by Christoph Hellwig.
>
> - Patch "s390/mm: Remove sev_active() function"
> - New patch.
>
> Since v1:
>
> - Patch "x86,s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig"
> - Remove definition of ARCH_HAS_MEM_ENCRYPT from s390/Kconfig as well.
> - Reworded patch title and message a little bit.
>
> - Patch "DMA mapping: Move SME handling to x86-specific files"
> - Adapt s390's <asm/mem_encrypt.h> as well.
> - Remove dma_check_mask() from kernel/dma/mapping.c. Suggested by
> Christoph Hellwig.
>
> Thiago Jung Bauermann (6):
> x86,s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig
> swiotlb: Remove call to sme_active()
> dma-mapping: Remove dma_check_mask()
> x86,s390/mm: Move sme_active() and sme_me_mask to x86-specific header
> fs/core/vmcore: Move sev_active() reference to x86 arch code
> s390/mm: Remove sev_active() function
>
> arch/Kconfig | 3 +++
> arch/s390/Kconfig | 4 +---
> arch/s390/include/asm/mem_encrypt.h | 5 +----
> arch/s390/mm/init.c | 7 +------
> arch/x86/Kconfig | 4 +---
> arch/x86/include/asm/mem_encrypt.h | 10 ++++++++++
> arch/x86/kernel/crash_dump_64.c | 5 +++++
> arch/x86/mm/mem_encrypt.c | 2 --
> fs/proc/vmcore.c | 8 ++++----
> include/linux/crash_dump.h | 14 ++++++++++++++
> include/linux/mem_encrypt.h | 15 +--------------
> kernel/dma/mapping.c | 8 --------
> kernel/dma/swiotlb.c | 3 +--
> 13 files changed, 42 insertions(+), 46 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/mm: Warn if W+X pages found on boot
From: Christophe Leroy @ 2019-08-09 13:11 UTC (permalink / raw)
To: Russell Currey, linuxppc-dev, mpe; +Cc: Julia.Lawall, rashmica.g
In-Reply-To: <6f3c93698669da36cb6bb354394a1f63c93a58cc.camel@russell.cc>
Le 02/05/2019 à 07:51, Russell Currey a écrit :
>>>>> + if (radix_enabled())
>>>>> + st.start_address = PAGE_OFFSET;
>>>>> + else
>>>> + st.start_address = KERN_VIRT_START;
>>>>
>>>> KERN_VIRT_START doesn't exist on PPC32.
>>>>
>>>> Christophe
>>>>
>>> Thanks a lot for the review! Applied all your suggestions. What
>>> should I use on PPC32 instead?
>>
>> Indeed it looks like KERN_VIRT_START is defined as 0 for PPC32 at
>> the
>> top of ptdump.c, which look strange to me.
>>
>> I guess PAGE_OFFSET should be the good value for KERN_VIRT_START on
>> PPC32.
>>
>> Christophe
>
> git blame says you put it there :) I'll set it to PAGE_OFFSET instead
> of zero. Cheers
>
Finally it seems that I was right at first place. KERN_VIRT_START should
be 0 because in walk_pagetables(), it starts with:
pgd_t *pgd = pgd_offset_k(0UL);
Now that KERN_VIRT_START has changed to 0xc0000000, I get a shift of
0xc0000000 in the display, ie the kernel pages are displayed starting at
0x80000000 instead of 0xc0000000 (0x80000000 = 0xc0000000 + 0xc0000000)
Since we only want to display kernel pages, I guess we should use
pgd_t *pgd = pgd_offset_k(KERN_VIRT_START); but then we can't use the
for () loop as it is.
Does it work properly on PPC64 ? If so, that's surprising.
Christophe
^ permalink raw reply
* Re: [RFC V2 0/1] mm/debug: Add tests for architecture exported page table helpers
From: Matthew Wilcox @ 2019-08-09 13:52 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Tetsuo Handa, Heiko Carstens, Michal Hocko, linux-mm, Dave Hansen,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390, x86,
Russell King - ARM Linux, Steven Price, Jason Gunthorpe,
linux-arm-kernel, linux-snps-arc, Kees Cook, Masahiro Yamada,
Mark Brown, Dan Williams, Vlastimil Babka, Sri Krishna chowdary,
Ard Biesheuvel, Greg Kroah-Hartman, linux-mips, Ralf Baechle,
linux-kernel, Paul Burton, Mike Rapoport, Vineet Gupta,
Martin Schwidefsky, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <a5aab7ff-f7fd-9cc1-6e37-e4185eee65ac@arm.com>
On Fri, Aug 09, 2019 at 04:05:07PM +0530, Anshuman Khandual wrote:
> On 08/09/2019 03:46 PM, Matthew Wilcox wrote:
> > On Fri, Aug 09, 2019 at 01:03:17PM +0530, Anshuman Khandual wrote:
> >> Should alloc_gigantic_page() be made available as an interface for general
> >> use in the kernel. The test module here uses very similar implementation from
> >> HugeTLB to allocate a PUD aligned memory block. Similar for mm_alloc() which
> >> needs to be exported through a header.
> >
> > Why are you allocating memory at all instead of just using some
> > known-to-exist PFNs like I suggested?
>
> We needed PFN to be PUD aligned for pfn_pud() and PMD aligned for mk_pmd().
> Now walking the kernel page table for a known symbol like kernel_init()
I didn't say to walk the kernel page table. I said to call virt_to_pfn()
for a known symbol like kernel_init().
> as you had suggested earlier we might encounter page table page entries at PMD
> and PUD which might not be PMD or PUD aligned respectively. It seemed to me
> that alignment requirement is applicable only for mk_pmd() and pfn_pud()
> which create large mappings at those levels but that requirement does not
> exist for page table pages pointing to next level. Is not that correct ? Or
> I am missing something here ?
Just clear the bottom bits off the PFN until you get a PMD or PUD aligned
PFN. It's really not hard.
^ permalink raw reply
* [Bug 204479] KASAN hit at modprobe zram
From: bugzilla-daemon @ 2019-08-09 14:08 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-204479-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=204479
--- Comment #11 from Christophe Leroy (christophe.leroy@c-s.fr) ---
Thanks. Then it is not about SMP allthough there's anyway a theoritical problem
with SMP that's I'll address in another patch.
I think I finally spotted the issue. Let's take the first occurence of the
first log:
Aug 08 23:39:58 T600 kernel: ###### module_alloc(4718) = f1065000
[fe20ca00-fe20d2e3]
[...]
Aug 08 23:39:59 T600 kernel: BUG: Unable to handle kernel data access at
0xfe20d040
In kasan_init_region(), the loop starts with k_cur = 0xfe20ca00 to set the pte
for the first shadow page at 0xfe20c000. Then k_cur is increased by PAGE_SIZE
so now k_cur = 0xfe20da00.
As this is over 0xfe20d2e3, it doesn't set the pte for the second page at
0xfe20d000.
It should be fixed by changing the init value of k_cur in the for() loop of
kasan_init_region() by:
for (k_cur = k_start & PAGE_MASK; ....)
Can you test it ?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* [PATCH] powerpc/ptdump: fix addresses display on PPC32
From: Christophe Leroy @ 2019-08-09 14:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
Commit 453d87f6a8ae ("powerpc/mm: Warn if W+X pages found on boot")
wrongly changed KERN_VIRT_START from 0 to PAGE_OFFSET, leading to a
shift in the displayed addresses.
Lets revert that change to resync walk_pagetables()'s addr val and
pgd_t pointer for PPC32.
Fixes: 453d87f6a8ae ("powerpc/mm: Warn if W+X pages found on boot")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/mm/ptdump/ptdump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
index 6a88a9f585d4..3ad64fc11419 100644
--- a/arch/powerpc/mm/ptdump/ptdump.c
+++ b/arch/powerpc/mm/ptdump/ptdump.c
@@ -27,7 +27,7 @@
#include "ptdump.h"
#ifdef CONFIG_PPC32
-#define KERN_VIRT_START PAGE_OFFSET
+#define KERN_VIRT_START 0
#endif
/*
--
2.13.3
^ permalink raw reply related
* [PATCH] powerpc/kasan: fix shadow area set up for modules.
From: Christophe Leroy @ 2019-08-09 14:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Erhard F.
Cc: linuxppc-dev, linux-kernel
When loading modules, from time to time an Oops is encountered
during the init of shadow area for globals. This is due to the
last page not always being mapped depending on the exact distance
between the start and the end of the shadow area and the alignment
with the page addresses.
Fix this by aligning the starting address with the page address.
Reported-by: Erhard F. <erhard_f@mailbox.org>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=204479
Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/mm/kasan/kasan_init_32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/kasan/kasan_init_32.c b/arch/powerpc/mm/kasan/kasan_init_32.c
index 74f4555a62ba..99eac3fab83c 100644
--- a/arch/powerpc/mm/kasan/kasan_init_32.c
+++ b/arch/powerpc/mm/kasan/kasan_init_32.c
@@ -74,7 +74,7 @@ static int __ref kasan_init_region(void *start, size_t size)
if (!slab_is_available())
block = memblock_alloc(k_end - k_start, PAGE_SIZE);
- for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE) {
+ for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) {
pmd_t *pmd = pmd_offset(pud_offset(pgd_offset_k(k_cur), k_cur), k_cur);
void *va = block ? block + k_cur - k_start : kasan_get_one_page();
pte_t pte = pfn_pte(PHYS_PFN(__pa(va)), PAGE_KERNEL);
--
2.13.3
^ permalink raw reply related
* [PATCH] powerpc/kasan: fix parallele loading of modules.
From: Christophe Leroy @ 2019-08-09 14:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Erhard F.
Cc: linuxppc-dev, linux-kernel
Parallele loading of modules may lead to bad setup of shadow
page table entries.
First, lets align modules so that two modules never share the same
shadow page.
Second, ensure that two modules cannot allocate two page tables for
the same PMD entry at the same time. This is done by using
init_mm.page_table_lock in the same way as __pte_alloc_kernel()
Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/mm/kasan/kasan_init_32.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/kasan/kasan_init_32.c b/arch/powerpc/mm/kasan/kasan_init_32.c
index 99eac3fab83c..802387b231ad 100644
--- a/arch/powerpc/mm/kasan/kasan_init_32.c
+++ b/arch/powerpc/mm/kasan/kasan_init_32.c
@@ -5,6 +5,7 @@
#include <linux/kasan.h>
#include <linux/printk.h>
#include <linux/memblock.h>
+#include <linux/moduleloader.h>
#include <linux/sched/task.h>
#include <linux/vmalloc.h>
#include <asm/pgalloc.h>
@@ -46,7 +47,19 @@ static int __ref kasan_init_shadow_page_tables(unsigned long k_start, unsigned l
kasan_populate_pte(new, PAGE_READONLY);
else
kasan_populate_pte(new, PAGE_KERNEL_RO);
- pmd_populate_kernel(&init_mm, pmd, new);
+
+ smp_wmb(); /* See comment in __pte_alloc */
+
+ spin_lock(&init_mm.page_table_lock);
+ /* Has another populated it ? */
+ if (likely((void *)pmd_page_vaddr(*pmd) == kasan_early_shadow_pte)) {
+ pmd_populate_kernel(&init_mm, pmd, new);
+ new = NULL;
+ }
+ spin_unlock(&init_mm.page_table_lock);
+
+ if (new && slab_is_available())
+ pte_free_kernel(&init_mm, new);
}
return 0;
}
@@ -137,7 +150,11 @@ void __init kasan_init(void)
#ifdef CONFIG_MODULES
void *module_alloc(unsigned long size)
{
- void *base = vmalloc_exec(size);
+ void *base;
+
+ base = __vmalloc_node_range(size, MODULE_ALIGN, VMALLOC_START, VMALLOC_END,
+ GFP_KERNEL, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
+ NUMA_NO_NODE, __builtin_return_address(0));
if (!base)
return NULL;
--
2.13.3
^ permalink raw reply related
* [Bug 204479] KASAN hit at modprobe zram
From: bugzilla-daemon @ 2019-08-09 15:10 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-204479-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=204479
--- Comment #12 from Christophe Leroy (christophe.leroy@c-s.fr) ---
Patch at https://patchwork.ozlabs.org/patch/1144756/
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Book3S 64-bit "heavyweight" KASAN support
From: Christophe Leroy @ 2019-08-09 15:35 UTC (permalink / raw)
To: Daniel Axtens; +Cc: aneesh.kumar, linuxppc-dev, kasan-dev
In-Reply-To: <372df444-27e7-12a7-0bdb-048f29983cf4@c-s.fr>
Hi Daniel,
Le 07/08/2019 à 18:34, Christophe Leroy a écrit :
>
>
> Le 07/08/2019 à 01:38, Daniel Axtens a écrit :
>> KASAN support on powerpc64 is interesting:
>>
>> - We want to be able to support inline instrumentation so as to be
>> able to catch global and stack issues.
>>
>> - We run a lot of code at boot in real mode. This includes stuff like
>> printk(), so it's not feasible to just disable instrumentation
>> around it.
>
> Have you definitely given up the idea of doing a standard implementation
> of KASAN like other 64 bits arches have done ?
>
> Isn't it possible to setup an early 1:1 mapping and go in virtual mode
> earlier ? What is so different between book3s64 and book3e64 ?
> On book3e64, we've been able to setup KASAN before printing anything
> (except when using EARLY_DEBUG). Isn't it feasible on book3s64 too ?
>
I looked at it once more, and cannot find that "We run a lot of code at
boot in real mode. This includes stuff like printk()".
Can you provide exemples ?
AFAICS, there are two things which are run in real mode at boot:
1/ prom_init() in kernel/prom_init.c
2/ early_setup() in kernel/setup_64.c
1/ KASAN is already inhibited for prom_init(), and prom_init() only uses
prom_printf() to display stuff.
2/ early_setup() only call a subset of simple functions. By regrouping
things in a new file called early_64.c as done for PPC32 with
early_32.c, we can easily inhibit kasan for those few stuff. printk() is
not used there either, there is even a comment at the startup of
early_setup() telling /* -------- printk is _NOT_ safe to use here !
------- */. The only things that perform display is the function
udbg_printf(), which is called only when DEBUG is set and which is
linked to CONFIG_PPC_EARLY_DEBUG. We already discussed that and agreed
that CONFIG_PPC_EARLY_DEBUG could be made exclusive of CONFIG_KASAN.
Once early_setup() has run, BOOK3S64 goes in virtual mode, just like
BOOK3E does.
What am I missing ?
Thanks
Christophe
^ permalink raw reply
* Re: [PATCH v4 0/6] Remove x86-specific code from generic headers
From: Thiago Jung Bauermann @ 2019-08-09 16:02 UTC (permalink / raw)
To: mpe
Cc: linux-s390, Mike Anderson, Lianbo Jiang, Konrad Rzeszutek Wilk,
Robin Murphy, x86, Ram Pai, linux-kernel, Alexey Dobriyan,
Halil Pasic, iommu, Ingo Molnar, Borislav Petkov, Thomas Lendacky,
H. Peter Anvin, linux-fsdevel, Thomas Gleixner, linuxppc-dev,
Christoph Hellwig, Marek Szyprowski
In-Reply-To: <87sgqasdr6.fsf@concordia.ellerman.id.au>
mpe@ellerman.id.au writes:
> Thiago Jung Bauermann <bauerman@linux.ibm.com> writes:
>> Hello,
>>
>> This version has only a small change in the last patch as requested by
>> Christoph and Halil, and collects Reviewed-by's.
>>
>> These patches are applied on top of v5.3-rc2.
>>
>> I don't have a way to test SME, SEV, nor s390's PEF so the patches have only
>> been build tested.
>
> I need to take this series via the powerpc tree because there is another
> fairly large powerpc specific series dependent on it.
>
> I think this series already has pretty much all the acks it needs, which
> almost never happens, amazing work!
Yes, thank you very much to everyone who reviewed the patches!
> I'll put the series in a topic branch, just in case there's any bad
> conflicts and other folks want to merge it later on. I'll then merge the
> topic branch into my next, and so this series will be tested in
> linux-next that way.
That's awesome. Thank you very much!
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* [Bug 204479] KASAN hit at modprobe zram
From: bugzilla-daemon @ 2019-08-09 17:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-204479-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=204479
--- Comment #13 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 284301
--> https://bugzilla.kernel.org/attachment.cgi?id=284301&action=edit
dmesg (kernel 5.3-rc3 + patch + 2nd patch, without CONFIG_SMP, PowerMac G4 DP)
Definitely an improvement with the latest patch. b43legacy and nfs load now
reliably without Oops.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* [Bug 204479] KASAN hit at modprobe zram
From: bugzilla-daemon @ 2019-08-09 17:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-204479-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=204479
--- Comment #14 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 284303
--> https://bugzilla.kernel.org/attachment.cgi?id=284303&action=edit
dmesg (kernel 5.3-rc3 + patch + 2nd patch, without CONFIG_SMP, v2, PowerMac G4
DP)
However the radeon module und btrfs (if built as module) still freeze the
machine until the 2min reboot timer kicks in. Also some EHCI driver modules
oopses, but not always.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* [PATCH] powerpc: fix inline asm constraints for dcbz
From: Nick Desaulniers @ 2019-08-09 18:21 UTC (permalink / raw)
To: mpe
Cc: arnd, Nick Desaulniers, linux-kernel, clang-built-linux,
Paul Mackerras, Nathan Chancellor, linuxppc-dev,
kbuild test robot
In-Reply-To: <87h873zs88.fsf@concordia.ellerman.id.au>
The input parameter is modified, so it should be an output parameter
with "=" to make it so that a copy of the input is not made by Clang.
Link: https://bugs.llvm.org/show_bug.cgi?id=42762
Link: https://gcc.gnu.org/onlinedocs/gcc/Modifiers.html#Modifiers
Link: https://github.com/ClangBuiltLinux/linux/issues/593
Link: https://godbolt.org/z/QwhZXi
Link: https://lore.kernel.org/lkml/20190721075846.GA97701@archlinux-threadripper/
Fixes: 6c5875843b87 ("powerpc: slightly improve cache helpers")
Debugged-by: Nathan Chancellor <natechancellor@gmail.com>
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Reported-by: kbuild test robot <lkp@intel.com>
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
Green CI run:
https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/122521976
https://github.com/ClangBuiltLinux/continuous-integration/pull/197/files#diff-40bd16e3188587e4d648c30e0c2d6d37
arch/powerpc/include/asm/cache.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index b3388d95f451..5a0df6a1b9dc 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -107,22 +107,22 @@ extern void _set_L3CR(unsigned long);
static inline void dcbz(void *addr)
{
- __asm__ __volatile__ ("dcbz %y0" : : "Z"(*(u8 *)addr) : "memory");
+ __asm__ __volatile__ ("dcbz %y0" : "=Z"(*(u8 *)addr) :: "memory");
}
static inline void dcbi(void *addr)
{
- __asm__ __volatile__ ("dcbi %y0" : : "Z"(*(u8 *)addr) : "memory");
+ __asm__ __volatile__ ("dcbi %y0" : "=Z"(*(u8 *)addr) :: "memory");
}
static inline void dcbf(void *addr)
{
- __asm__ __volatile__ ("dcbf %y0" : : "Z"(*(u8 *)addr) : "memory");
+ __asm__ __volatile__ ("dcbf %y0" : "=Z"(*(u8 *)addr) :: "memory");
}
static inline void dcbst(void *addr)
{
- __asm__ __volatile__ ("dcbst %y0" : : "Z"(*(u8 *)addr) : "memory");
+ __asm__ __volatile__ ("dcbst %y0" : "=Z"(*(u8 *)addr) :: "memory");
}
#endif /* !__ASSEMBLY__ */
#endif /* __KERNEL__ */
--
2.23.0.rc1.153.gdeed80330f-goog
^ permalink raw reply related
* Re: [PATCH] powerpc: fix inline asm constraints for dcbz
From: Arnd Bergmann @ 2019-08-09 18:28 UTC (permalink / raw)
To: Nick Desaulniers
Cc: kbuild test robot, Linux Kernel Mailing List, clang-built-linux,
Paul Mackerras, Nathan Chancellor, linuxppc-dev
In-Reply-To: <20190809182106.62130-1-ndesaulniers@google.com>
On Fri, Aug 9, 2019 at 8:21 PM 'Nick Desaulniers' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
> static inline void dcbz(void *addr)
> {
> - __asm__ __volatile__ ("dcbz %y0" : : "Z"(*(u8 *)addr) : "memory");
> + __asm__ __volatile__ ("dcbz %y0" : "=Z"(*(u8 *)addr) :: "memory");
> }
>
> static inline void dcbi(void *addr)
> {
> - __asm__ __volatile__ ("dcbi %y0" : : "Z"(*(u8 *)addr) : "memory");
> + __asm__ __volatile__ ("dcbi %y0" : "=Z"(*(u8 *)addr) :: "memory");
> }
I think the result of the discussion was that an output argument only kind-of
makes sense for dcbz, but for the others it's really an input, and clang is
wrong in the way it handles the "Z" constraint by making a copy, which it
doesn't do for "m".
I'm not sure whether it's correct to use "m" instead of "Z" here, which
would be a better workaround if that works. More importantly though,
clang really needs to be fixed to handle "Z" correctly.
Arnd
^ permalink raw reply
* Re: [PATCH v8 1/7] powerpc/mce: Schedule work from irq_work
From: Mahesh Jagannath Salgaonkar @ 2019-08-09 18:55 UTC (permalink / raw)
To: Santosh Sivaraj, linuxppc-dev, Linux Kernel
Cc: Aneesh Kumar K.V, Mahesh Salgaonkar, Nicholas Piggin,
Chandan Rajendra, Reza Arbab
In-Reply-To: <20190807145700.25599-2-santosh@fossix.org>
On 8/7/19 8:26 PM, Santosh Sivaraj wrote:
> schedule_work() cannot be called from MCE exception context as MCE can
> interrupt even in interrupt disabled context.
>
> fixes: 733e4a4c ("powerpc/mce: hookup memory_failure for UE errors")
> Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
> ---
> arch/powerpc/kernel/mce.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
> index b18df633eae9..0ab6fa7cbbbb 100644
> --- a/arch/powerpc/kernel/mce.c
> +++ b/arch/powerpc/kernel/mce.c
> @@ -144,7 +144,6 @@ void save_mce_event(struct pt_regs *regs, long handled,
> if (phys_addr != ULONG_MAX) {
> mce->u.ue_error.physical_address_provided = true;
> mce->u.ue_error.physical_address = phys_addr;
> - machine_check_ue_event(mce);
> }
> }
> return;
> @@ -275,8 +274,7 @@ static void machine_process_ue_event(struct work_struct *work)
> }
> }
> /*
> - * process pending MCE event from the mce event queue. This function will be
> - * called during syscall exit.
> + * process pending MCE event from the mce event queue.
> */
> static void machine_check_process_queued_event(struct irq_work *work)
> {
> @@ -292,6 +290,10 @@ static void machine_check_process_queued_event(struct irq_work *work)
> while (__this_cpu_read(mce_queue_count) > 0) {
> index = __this_cpu_read(mce_queue_count) - 1;
> evt = this_cpu_ptr(&mce_event_queue[index]);
> +
> + if (evt->error_type == MCE_ERROR_TYPE_UE)
> + machine_check_ue_event(evt);
This will work only for the event that are queued by mce handler, others
will get ignored. I think you should introduce a separate irq work queue
for schedule_work().
Thanks,
-Mahesh.
^ permalink raw reply
* Re: [PATCH v8 3/7] powerpc/mce: Fix MCE handling for huge pages
From: Mahesh Jagannath Salgaonkar @ 2019-08-09 19:06 UTC (permalink / raw)
To: Santosh Sivaraj, linuxppc-dev, Linux Kernel
Cc: Aneesh Kumar K.V, Mahesh Salgaonkar, Nicholas Piggin,
Chandan Rajendra, Reza Arbab
In-Reply-To: <20190807145700.25599-4-santosh@fossix.org>
On 8/7/19 8:26 PM, Santosh Sivaraj wrote:
> From: Balbir Singh <bsingharora@gmail.com>
>
> The current code would fail on huge pages addresses, since the shift would
> be incorrect. Use the correct page shift value returned by
> __find_linux_pte() to get the correct physical address. The code is more
> generic and can handle both regular and compound pages.
>
> Fixes: ba41e1e1ccb9 ("powerpc/mce: Hookup derror (load/store) UE errors")
> Signed-off-by: Balbir Singh <bsingharora@gmail.com>
> [arbab@linux.ibm.com: Fixup pseries_do_memory_failure()]
> Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
> Co-developed-by: Santosh Sivaraj <santosh@fossix.org>
> Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
> ---
> arch/powerpc/include/asm/mce.h | 2 +-
> arch/powerpc/kernel/mce_power.c | 50 ++++++++++++++--------------
> arch/powerpc/platforms/pseries/ras.c | 9 ++---
> 3 files changed, 29 insertions(+), 32 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
> index a4c6a74ad2fb..f3a6036b6bc0 100644
> --- a/arch/powerpc/include/asm/mce.h
> +++ b/arch/powerpc/include/asm/mce.h
> @@ -209,7 +209,7 @@ extern void release_mce_event(void);
> extern void machine_check_queue_event(void);
> extern void machine_check_print_event_info(struct machine_check_event *evt,
> bool user_mode, bool in_guest);
> -unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr);
> +unsigned long addr_to_phys(struct pt_regs *regs, unsigned long addr);
> #ifdef CONFIG_PPC_BOOK3S_64
> void flush_and_reload_slb(void);
> #endif /* CONFIG_PPC_BOOK3S_64 */
> diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
> index a814d2dfb5b0..bed38a8e2e50 100644
> --- a/arch/powerpc/kernel/mce_power.c
> +++ b/arch/powerpc/kernel/mce_power.c
> @@ -20,13 +20,14 @@
> #include <asm/exception-64s.h>
>
> /*
> - * Convert an address related to an mm to a PFN. NOTE: we are in real
> - * mode, we could potentially race with page table updates.
> + * Convert an address related to an mm to a physical address.
> + * NOTE: we are in real mode, we could potentially race with page table updates.
> */
> -unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr)
> +unsigned long addr_to_phys(struct pt_regs *regs, unsigned long addr)
> {
> - pte_t *ptep;
> - unsigned long flags;
> + pte_t *ptep, pte;
> + unsigned int shift;
> + unsigned long flags, phys_addr;
> struct mm_struct *mm;
>
> if (user_mode(regs))
> @@ -35,14 +36,21 @@ unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr)
> mm = &init_mm;
>
> local_irq_save(flags);
> - if (mm == current->mm)
> - ptep = find_current_mm_pte(mm->pgd, addr, NULL, NULL);
> - else
> - ptep = find_init_mm_pte(addr, NULL);
> + ptep = __find_linux_pte(mm->pgd, addr, NULL, &shift);
> local_irq_restore(flags);
> +
> if (!ptep || pte_special(*ptep))
> return ULONG_MAX;
> - return pte_pfn(*ptep);
> +
> + pte = *ptep;
> + if (shift > PAGE_SHIFT) {
> + unsigned long rpnmask = (1ul << shift) - PAGE_SIZE;
> +
> + pte = __pte(pte_val(pte) | (addr & rpnmask));
> + }
> + phys_addr = pte_pfn(pte) << PAGE_SHIFT;
> +
> + return phys_addr;
> }
>
> /* flush SLBs and reload */
> @@ -354,18 +362,16 @@ static int mce_find_instr_ea_and_pfn(struct pt_regs *regs, uint64_t *addr,
Now that we have addr_to_phys() can we change this function name as well
to mce_find_instr_ea_and_phys() ?
Tested-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
This should go to stable tree. Can you move this patch to 2nd position ?
Thanks,
-Mahesh.
^ permalink raw reply
* Re: [PATCH net-next v2] ibmveth: Allow users to update reported speed and duplex
From: David Miller @ 2019-08-09 19:47 UTC (permalink / raw)
To: jakub.kicinski; +Cc: tlfalcon, linuxppc-dev, netdev
In-Reply-To: <20190806151524.69d75f8d@cakuba.netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Tue, 6 Aug 2019 15:15:24 -0700
> On Tue, 6 Aug 2019 11:23:08 -0500, Thomas Falcon wrote:
>> Reported ethtool link settings for the ibmveth driver are currently
>> hardcoded and no longer reflect the actual capabilities of supported
>> hardware. There is no interface designed for retrieving this information
>> from device firmware nor is there any way to update current settings
>> to reflect observed or expected link speeds.
>>
>> To avoid breaking existing configurations, retain current values as
>> default settings but let users update them to match the expected
>> capabilities of underlying hardware if needed. This update would
>> allow the use of configurations that rely on certain link speed
>> settings, such as LACP. This patch is based on the implementation
>> in virtio_net.
>>
>> Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
>
> Looks like this is the third copy of the same code virtio and
> netvsc have :( Is there a chance we could factor this out into
> helpers in the core?
Yeah, let's stop the duplication of code while we can.
Thomas please perform the consolidation and respin.
Thank you.
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: fsl_esai: Add new compatible string for imx6ull
From: Nicolin Chen @ 2019-08-09 19:58 UTC (permalink / raw)
To: Shengjiu Wang
Cc: mark.rutland, devicetree, alsa-devel, timur, Xiubo.Lee,
linuxppc-dev, broonie, linux-kernel, robh+dt, festevam
In-Reply-To: <1565346467-5769-2-git-send-email-shengjiu.wang@nxp.com>
On Fri, Aug 09, 2019 at 06:27:47PM +0800, Shengjiu Wang wrote:
> Add new compatible string "fsl,imx6ull-esai" in the binding document.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
> ---
> Documentation/devicetree/bindings/sound/fsl,esai.txt | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt
> index 5b9914367610..0e6e2166f76c 100644
> --- a/Documentation/devicetree/bindings/sound/fsl,esai.txt
> +++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt
> @@ -7,8 +7,11 @@ other DSPs. It has up to six transmitters and four receivers.
>
> Required properties:
>
> - - compatible : Compatible list, must contain "fsl,imx35-esai" or
> - "fsl,vf610-esai"
> + - compatible : Compatible list, should contain one of the following
> + compatibles:
> + "fsl,imx35-esai",
> + "fsl,vf610-esai",
> + "fsl,imx6ull-esai",
>
> - reg : Offset and length of the register set for the device.
>
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: fsl_esai: Add compatible string for imx6ull
From: Nicolin Chen @ 2019-08-09 19:58 UTC (permalink / raw)
To: Shengjiu Wang
Cc: mark.rutland, devicetree, alsa-devel, timur, Xiubo.Lee,
linuxppc-dev, broonie, linux-kernel, robh+dt, festevam
In-Reply-To: <1565346467-5769-1-git-send-email-shengjiu.wang@nxp.com>
On Fri, Aug 09, 2019 at 06:27:46PM +0800, Shengjiu Wang wrote:
> Add compatible string for imx6ull, from imx6ull platform,
> the issue of channel swap after xrun is fixed in hardware.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
> ---
> sound/soc/fsl/fsl_esai.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
> index 10d2210c91ef..4b4a8e831e9e 100644
> --- a/sound/soc/fsl/fsl_esai.c
> +++ b/sound/soc/fsl/fsl_esai.c
> @@ -920,6 +920,7 @@ static int fsl_esai_remove(struct platform_device *pdev)
> static const struct of_device_id fsl_esai_dt_ids[] = {
> { .compatible = "fsl,imx35-esai", },
> { .compatible = "fsl,vf610-esai", },
> + { .compatible = "fsl,imx6ull-esai", },
> {}
> };
> MODULE_DEVICE_TABLE(of, fsl_esai_dt_ids);
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH] powerpc: fix inline asm constraints for dcbz
From: Christophe Leroy @ 2019-08-09 20:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kbuild test robot, Nick Desaulniers, Linux Kernel Mailing List,
clang-built-linux, Paul Mackerras, Nathan Chancellor,
linuxppc-dev
In-Reply-To: <CAK8P3a3LynWTbpV8=VPm2TqgNM2MnoEyCPJd0PL2D+tcZqJgHg@mail.gmail.com>
Arnd Bergmann <arnd@arndb.de> a écrit :
> On Fri, Aug 9, 2019 at 8:21 PM 'Nick Desaulniers' via Clang Built
> Linux <clang-built-linux@googlegroups.com> wrote:
>
>> static inline void dcbz(void *addr)
>> {
>> - __asm__ __volatile__ ("dcbz %y0" : : "Z"(*(u8 *)addr) : "memory");
>> + __asm__ __volatile__ ("dcbz %y0" : "=Z"(*(u8 *)addr) :: "memory");
>> }
>>
>> static inline void dcbi(void *addr)
>> {
>> - __asm__ __volatile__ ("dcbi %y0" : : "Z"(*(u8 *)addr) : "memory");
>> + __asm__ __volatile__ ("dcbi %y0" : "=Z"(*(u8 *)addr) :: "memory");
>> }
>
> I think the result of the discussion was that an output argument only kind-of
> makes sense for dcbz, but for the others it's really an input, and clang is
> wrong in the way it handles the "Z" constraint by making a copy, which it
> doesn't do for "m".
>
> I'm not sure whether it's correct to use "m" instead of "Z" here, which
> would be a better workaround if that works. More importantly though,
> clang really needs to be fixed to handle "Z" correctly.
As the benefit is null, I think the best is probably to reverse my
original commit until at least CLang is fixed, as initialy suggested
by mpe
Christophe
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox