* Applied "ASoC: fsl_esai: Add new compatible string for imx6ull" to the asoc tree
From: Mark Brown @ 2019-08-12 13:09 UTC (permalink / raw)
To: Shengjiu Wang
Cc: mark.rutland, devicetree, alsa-devel, timur, Xiubo.Lee,
linuxppc-dev, linux-kernel, robh+dt, Nicolin Chen, Mark Brown,
festevam
In-Reply-To: <1565346467-5769-2-git-send-email-shengjiu.wang@nxp.com>
The patch
ASoC: fsl_esai: Add new compatible string for imx6ull
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 9ea08f2a6d27b6a26d33dae5c58e4099672d6bb3 Mon Sep 17 00:00:00 2001
From: Shengjiu Wang <shengjiu.wang@nxp.com>
Date: Fri, 9 Aug 2019 18:27:47 +0800
Subject: [PATCH] ASoC: fsl_esai: Add new compatible string for imx6ull
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>
Link: https://lore.kernel.org/r/1565346467-5769-2-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
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.20.1
^ permalink raw reply related
* Re: [PATCH] powerpc/64e: drop stale call to smp_processor_id() which hangs SMP startup
From: Michael Ellerman @ 2019-08-12 13:15 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Chris Packham
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <bef479514f4c08329fa649f67735df8918bc0976.1565268248.git.christophe.leroy@c-s.fr>
On Thu, 2019-08-08 at 12:48:26 UTC, Christophe Leroy wrote:
> Santa commit ebb9d30a6a74 ("powerpc/mm: any thread in one core can be
> the first to setup TLB1") removed the need to know the cpu_id in
> early_init_this_mmu(), but the call to smp_processor_id() which was
> marked __maybe_used remained.
>
> Since commit ed1cd6deb013 ("powerpc: Activate
> CONFIG_THREAD_INFO_IN_TASK") thread_info cannot be reached before mmu
> is properly set up.
>
> Drop this stale call to smp_processor_id() which make SMP hang
> when CONFIG_PREEMPT is set.
>
> Reported-by: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
> Fixes: ebb9d30a6a74 ("powerpc/mm: any thread in one core can be the first to setup TLB1")
> Link: https://github.com/linuxppc/issues/issues/264
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: stable@vger.kernel.org
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/b9ee5e04fd77898208c51b1395fa0b5e8536f9b6
cheers
^ permalink raw reply
* Re: [PATCH v9 2/7] powerpc/mce: Fix MCE handling for huge pages
From: Sasha Levin @ 2019-08-12 13:55 UTC (permalink / raw)
To: Sasha Levin, Santosh Sivaraj, Balbir Singh, linuxppc-dev
Cc: Aneesh Kumar K.V, stable
In-Reply-To: <20190812092236.16648-3-santosh@fossix.org>
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: ba41e1e1ccb9 powerpc/mce: Hookup derror (load/store) UE errors.
The bot has tested the following trees: v5.2.8, v4.19.66.
v5.2.8: Build OK!
v4.19.66: Failed to apply! Possible dependencies:
360cae313702 ("KVM: PPC: Book3S HV: Nested guest entry via hypercall")
41f4e631daf8 ("KVM: PPC: Book3S HV: Extract PMU save/restore operations as C-callable functions")
884dfb722db8 ("KVM: PPC: Book3S HV: Simplify machine check handling")
89329c0be8bd ("KVM: PPC: Book3S HV: Clear partition table entry on vm teardown")
8e3f5fc1045d ("KVM: PPC: Book3S HV: Framework and hcall stubs for nested virtualization")
95a6432ce903 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests")
a43c1590426c ("powerpc/pseries: Flush SLB contents on SLB MCE errors.")
c05772018491 ("powerpc/64s: Better printing of machine check info for guest MCEs")
d24ea8a7336a ("KVM: PPC: Book3S: Simplify external interrupt handling")
df709a296ef7 ("KVM: PPC: Book3S HV: Simplify real-mode interrupt handling")
f7035ce9f1df ("KVM: PPC: Book3S HV: Move interrupt delivery on guest entry to C code")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v5 1/7] Documentation/powerpc: Ultravisor API
From: Fabiano Rosas @ 2019-08-12 15:58 UTC (permalink / raw)
To: Claudio Carvalho, linuxppc-dev
Cc: Madhavan Srinivasan, Sukadev Bhattiprolu, Michael Anderson,
Ram Pai, Claudio Carvalho, kvm-ppc, Bharata B Rao, Ryan Grimm,
Ram Pai, Sukadev Bhattiprolu, Guerney Hunt, Thiago Bauermann
In-Reply-To: <20190808040555.2371-2-cclaudio@linux.ibm.com>
Claudio Carvalho <cclaudio@linux.ibm.com> writes:
Some small suggestions below:
> +
> + * 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) |
> + +---+---+---+---------------+
I find the use of '(HV)' in this last line a bit ambiguous. Since we are
already using 'HV' to refer to MSR(HV). I'd suggest using '(Host)' or
simply leaving it out.
> +
> + * 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.
Here 'reflected' refers to the Ultravisor. Later on, it is used as
meaning the Ultravisor reflects hypercalls/interrupts to the
Hypervisor. I suggest we use this term to mean the latter only.
> +
> + * 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
It looks like you could go without "become Ultravisor resources" since
it is already mentioned in the parent item above (The following...).
> + 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.
This is the second mention of 'verification information'. Could we
perhaps move this up after "SMVs are created..." and rephrase it in a way
that introduces the concept? What/where/in what state is the
verification information?
> +
> + * 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
Paravirtualized
> + 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.
This looks like it should be under UV_PAGE_OUT instead.
^ permalink raw reply
* [Bug 204479] KASAN hit at modprobe zram
From: bugzilla-daemon @ 2019-08-12 16:01 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 #17 from Christophe Leroy (christophe.leroy@c-s.fr) ---
Created attachment 284343
--> https://bugzilla.kernel.org/attachment.cgi?id=284343&action=edit
Disassembly of lib/raid6/altivec8.o
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* Re: [PATCH v4 06/25] pseries/fadump: define register/un-register callback functions
From: Mahesh J Salgaonkar @ 2019-08-12 16:01 UTC (permalink / raw)
To: Hari Bathini
Cc: Ananth N Mavinakayanahalli, Mahesh J Salgaonkar, Nicholas Piggin,
linuxppc-dev, Oliver, Vasant Hegde, Stewart Smith, Daniel Axtens
In-Reply-To: <156327675811.27462.1334913873575448846.stgit@hbathini.in.ibm.com>
On 2019-07-16 17:02:38 Tue, Hari Bathini wrote:
> Make RTAS calls to register and un-register for FADump. Also, update
> how fadump_region contents are diplayed to provide more information.
>
> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
> ---
> arch/powerpc/kernel/fadump-common.h | 2
> arch/powerpc/kernel/fadump.c | 164 ++------------------------
> arch/powerpc/platforms/pseries/rtas-fadump.c | 163 +++++++++++++++++++++++++-
> 3 files changed, 176 insertions(+), 153 deletions(-)
>
[...]
> static int rtas_fadump_register_fadump(struct fw_dump *fadump_conf)
> {
> - return -EIO;
> + int rc, err = -EIO;
> + unsigned int wait_time;
> +
> + /* TODO: Add upper time limit for the delay */
> + do {
> + rc = rtas_call(fadump_conf->ibm_configure_kernel_dump, 3, 1,
> + NULL, FADUMP_REGISTER, &fdm,
> + sizeof(struct rtas_fadump_mem_struct));
> +
> + wait_time = rtas_busy_delay_time(rc);
> + if (wait_time)
> + mdelay(wait_time);
> +
> + } while (wait_time);
> +
> + switch (rc) {
> + case 0:
> + pr_info("Registration is successful!\n");
> + fadump_conf->dump_registered = 1;
> + err = 0;
> + break;
> + case -1:
> + pr_err("Failed to register. Hardware Error(%d).\n", rc);
> + break;
> + case -3:
> + if (!is_fadump_boot_mem_contiguous(fadump_conf))
> + pr_err("Can't hot-remove boot memory area.\n");
> + else if (!is_fadump_reserved_mem_contiguous(fadump_conf))
> + pr_err("Can't hot-remove reserved memory area.\n");
Any reason why we changed the error messages here ? it gives an impression as
if fadump reservation tried to hot remove memory and failed.
Rest looks fine to me..
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Thanks,
-Mahesh.
^ permalink raw reply
* [Bug 204479] KASAN hit at modprobe zram
From: bugzilla-daemon @ 2019-08-12 16:06 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 #18 from Christophe Leroy (christophe.leroy@c-s.fr) ---
The Oops occurs at 0x3c8:
3b0: 81 21 00 88 lwz r9,136(r1)
3b4: 13 67 dc c4 vxor v27,v7,v27
3b8: 7d 11 a8 ce lvx v8,r17,r21
3bc: 11 5f 5b 06 vcmpgtsb v10,v31,v11
3c0: 11 6b 58 00 vaddubm v11,v11,v11
3c4: 81 41 00 8c lwz r10,140(r1)
>3c8: 7c 00 48 ce lvx v0,0,r9
This is because the value in r9 is most likely wrong.
r9 is loaded from the stack at 0x3b0
r9 was calculated and stored in the stack by the below code.
70: 3d 20 00 00 lis r9,0
72: R_PPC_ADDR16_HA .rodata.cst16
74: 3b b3 00 10 addi r29,r19,16
78: 39 29 00 00 addi r9,r9,0
7a: R_PPC_ADDR16_LO .rodata.cst16
7c: 91 21 00 88 stw r9,136(r1)
The value comes from .rodata.cst16
Two possibilities, either the value in .rodata.cst16 is wrong or the stack gets
corrupted.
Maybe you could try disabling KASAN in lib/raid6/Makefile for altivec8.o ? Or
maybe for the entire lib/raid6/ directory, just to see what happens ?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* Re: [PATCH v2 1/3] powerpc/rtas: use device model APIs and serialization during LPM
From: Nathan Lynch @ 2019-08-12 16:55 UTC (permalink / raw)
To: Tyrel Datwyler; +Cc: ego, linuxppc-dev
In-Reply-To: <5e98c3c9-eab0-b08a-50ee-b8bb9b9ad2dd@linux.ibm.com>
Tyrel Datwyler <tyreld@linux.ibm.com> writes:
> On 8/2/19 12:29 PM, Nathan Lynch wrote:
>> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
>> index 5faf0a64c92b..05824eb4323b 100644
>> --- a/arch/powerpc/kernel/rtas.c
>> +++ b/arch/powerpc/kernel/rtas.c
>> @@ -871,15 +871,17 @@ static int rtas_cpu_state_change_mask(enum rtas_cpu_state state,
>> return 0;
>>
>> for_each_cpu(cpu, cpus) {
>> + struct device *dev = get_cpu_device(cpu);
>> +
>> switch (state) {
>> case DOWN:
>> - cpuret = cpu_down(cpu);
>> + cpuret = device_offline(dev);
>> break;
>> case UP:
>> - cpuret = cpu_up(cpu);
>> + cpuret = device_online(dev);
>
> Not that I have a problem with using the core device api, but as an FYI we had
> discussed in the past introducing one shot functions in kernel/cpu.c for doing
> our take down, bring up where cpu_update_maps() can be held for the whole
> process. The thought was maybe it would be useful generically being able to
> online/offline a bulk subset.
Thanks, I've discussed something along those lines with Gautham and it
may be more desirable in the longer term than having the arch code
perform the locking.
However, I think it would be even better to avoid bringing up all the
offline CPUs only to shut them down again on the destination. Ideally we
could nudge offline threads into H_JOIN without doing all the work
associated with cpuhp callbacks and generating hotplug event noise. I'm
concerned about the overhead incurred by the current design on large
LPAR configurations.
Regardless, I'd expect that this fix shouldn't have to wait for the
implementation of either of those ideas.
>> break;
>> }
>> - if (cpuret) {
>> + if (cpuret < 0) {
>> pr_debug("%s: cpu_%s for cpu#%d returned %d.\n",
>> __func__,
>> ((state == UP) ? "up" : "down"),
>> @@ -968,6 +970,8 @@ int rtas_ibm_suspend_me(u64 handle)
>> data.token = rtas_token("ibm,suspend-me");
>> data.complete = &done;
>>
>> + lock_device_hotplug();
>> +
>
> Does taking the device hotplug lock suffice to prevent races with sysfs attempts
> to hotplug (on/off) cpus?
Yes.
> And if so we can strip out the code that checks the mask to see if we
> raced, correct?
I hope so, but I'm not sure, and it's harmless to leave in for
now. There could be other code which (like LPM) initiates cpu
online/offline outside of sysfs.
^ permalink raw reply
* Re: [PATCH] powerpc: Avoid clang warnings around setjmp and longjmp
From: Nathan Chancellor @ 2019-08-12 16:55 UTC (permalink / raw)
To: Christophe Leroy
Cc: Nick Desaulniers, linux-kernel, stable, clang-built-linux,
Paul Mackerras, linuxppc-dev
In-Reply-To: <5da5478f-9320-43bd-0f5e-430db2ee9195@c-s.fr>
On Mon, Aug 12, 2019 at 07:37:51AM +0200, Christophe Leroy wrote:
>
>
> Le 12/08/2019 à 04:32, Nathan Chancellor a écrit :
> > Commit aea447141c7e ("powerpc: Disable -Wbuiltin-requires-header when
> > setjmp is used") disabled -Wbuiltin-requires-header because of a warning
> > about the setjmp and longjmp declarations.
> >
> > r367387 in clang added another diagnostic around this, complaining that
> > there is no jmp_buf declaration.
> >
> [...]
>
> >
> > Cc: stable@vger.kernel.org # 4.19+
> > Link: https://github.com/ClangBuiltLinux/linux/issues/625
> > Link: https://github.com/llvm/llvm-project/commit/3be25e79477db2d31ac46493d97eca8c20592b07
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> >
> [...]
>
> >
> > arch/powerpc/kernel/Makefile | 5 +++--
> > arch/powerpc/xmon/Makefile | 5 +++--
>
> What about scripts/recordmcount.c and scripts/sortextable.c which contains
> calls to setjmp() and longjmp() ?
>
> And arch/um/ ?
>
> Christophe
Hi Christophe,
It looks like all of those will be using the system's setjmp header,
which won't cause these warnings.
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH] powerpc: Avoid clang warnings around setjmp and longjmp
From: Nick Desaulniers @ 2019-08-12 17:35 UTC (permalink / raw)
To: Nathan Chancellor
Cc: LKML, # 3.4.x, clang-built-linux, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190812023214.107817-1-natechancellor@gmail.com>
On Sun, Aug 11, 2019 at 7:42 PM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> Commit aea447141c7e ("powerpc: Disable -Wbuiltin-requires-header when
> setjmp is used") disabled -Wbuiltin-requires-header because of a warning
> about the setjmp and longjmp declarations.
>
> r367387 in clang added another diagnostic around this, complaining that
> there is no jmp_buf declaration.
>
> In file included from ../arch/powerpc/xmon/xmon.c:47:
> ../arch/powerpc/include/asm/setjmp.h:10:13: error: declaration of
> built-in function 'setjmp' requires the declaration of the 'jmp_buf'
> type, commonly provided in the header <setjmp.h>.
> [-Werror,-Wincomplete-setjmp-declaration]
> extern long setjmp(long *);
> ^
> ../arch/powerpc/include/asm/setjmp.h:11:13: error: declaration of
> built-in function 'longjmp' requires the declaration of the 'jmp_buf'
> type, commonly provided in the header <setjmp.h>.
> [-Werror,-Wincomplete-setjmp-declaration]
> extern void longjmp(long *, long);
> ^
> 2 errors generated.
>
> Take the same approach as the above commit by disabling the warning for
> the same reason, we provide our own longjmp/setjmp function.
>
> Cc: stable@vger.kernel.org # 4.19+
> Link: https://github.com/ClangBuiltLinux/linux/issues/625
> Link: https://github.com/llvm/llvm-project/commit/3be25e79477db2d31ac46493d97eca8c20592b07
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Thanks for the patch, Nathan.
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
>
> It may be worth using -fno-builtin-setjmp and -fno-builtin-longjmp
> instead as it makes it clear to clang that we are not using the builtin
> longjmp and setjmp functions, which I think is why these warnings are
> appearing (at least according to the commit that introduced this waring).
>
> Sample patch:
> https://github.com/ClangBuiltLinux/linux/issues/625#issuecomment-519251372
>
> However, this is the most conservative approach, as I have already had
> someone notice this error when building LLVM with PGO on tip of tree
> LLVM.
>
> arch/powerpc/kernel/Makefile | 5 +++--
> arch/powerpc/xmon/Makefile | 5 +++--
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index ea0c69236789..44e340ed4722 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -5,8 +5,9 @@
>
> CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"'
>
> -# Disable clang warning for using setjmp without setjmp.h header
> -CFLAGS_crash.o += $(call cc-disable-warning, builtin-requires-header)
> +# Avoid clang warnings about longjmp and setjmp built-ins (inclusion of setjmp.h and declaration of jmp_buf type)
> +CFLAGS_crash.o += $(call cc-disable-warning, builtin-requires-header) \
> + $(call cc-disable-warning, incomplete-setjmp-declaration)
>
> ifdef CONFIG_PPC64
> CFLAGS_prom_init.o += $(NO_MINIMAL_TOC)
> diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile
> index f142570ad860..53f341391210 100644
> --- a/arch/powerpc/xmon/Makefile
> +++ b/arch/powerpc/xmon/Makefile
> @@ -1,8 +1,9 @@
> # SPDX-License-Identifier: GPL-2.0
> # Makefile for xmon
>
> -# Disable clang warning for using setjmp without setjmp.h header
> -subdir-ccflags-y := $(call cc-disable-warning, builtin-requires-header)
> +# Avoid clang warnings about longjmp and setjmp built-ins (inclusion of setjmp.h and declaration of jmp_buf type)
> +subdir-ccflags-y := $(call cc-disable-warning, builtin-requires-header) \
> + $(call cc-disable-warning, incomplete-setjmp-declaration)
>
> GCOV_PROFILE := n
> KCOV_INSTRUMENT := n
> --
> 2.23.0.rc2
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* RE: [PATCH] dmaengine: fsldma: Mark expected switch fall-through
From: Leo Li @ 2019-08-12 19:40 UTC (permalink / raw)
To: Gustavo A. R. Silva, Zhang Wei, Vinod Koul, Dan Williams
Cc: dmaengine@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190812002159.GA26899@embeddedor>
> -----Original Message-----
> From: Gustavo A. R. Silva <gustavo@embeddedor.com>
> Sent: Sunday, August 11, 2019 7:22 PM
> To: Leo Li <leoyang.li@nxp.com>; Zhang Wei <zw@zh-kernel.org>; Vinod
> Koul <vkoul@kernel.org>; Dan Williams <dan.j.williams@intel.com>
> Cc: linuxppc-dev@lists.ozlabs.org; dmaengine@vger.kernel.org; linux-
> kernel@vger.kernel.org; Gustavo A. R. Silva <gustavo@embeddedor.com>
> Subject: [PATCH] dmaengine: fsldma: Mark expected switch fall-through
>
> Mark switch cases where we are expecting to fall through.
>
> Fix the following warning (Building: powerpc-ppa8548_defconfig powerpc):
>
> drivers/dma/fsldma.c: In function ‘fsl_dma_chan_probe’:
> drivers/dma/fsldma.c:1165:26: warning: this statement may fall through [-
> Wimplicit-fallthrough=]
> chan->toggle_ext_pause = fsl_chan_toggle_ext_pause;
> ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/dma/fsldma.c:1166:2: note: here
> case FSL_DMA_IP_83XX:
> ^~~~
>
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Li Yang <leoyang.li@nxp.com>
> ---
> drivers/dma/fsldma.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index
> 23e0a356f167..ad72b3f42ffa 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -1163,6 +1163,7 @@ static int fsl_dma_chan_probe(struct
> fsldma_device *fdev,
> switch (chan->feature & FSL_DMA_IP_MASK) {
> case FSL_DMA_IP_85XX:
> chan->toggle_ext_pause = fsl_chan_toggle_ext_pause;
> + /* Fall through */
> case FSL_DMA_IP_83XX:
> chan->toggle_ext_start = fsl_chan_toggle_ext_start;
> chan->set_src_loop_size = fsl_chan_set_src_loop_size;
> --
> 2.22.0
^ permalink raw reply
* Re: [PATCH v3 08/16] powerpc/pseries/svm: Use shared memory for LPPACA structures
From: Thiago Jung Bauermann @ 2019-08-12 21:43 UTC (permalink / raw)
To: Michael Ellerman
Cc: Anshuman Khandual, Alexey Kardashevskiy, Mike Anderson, Ram Pai,
linux-kernel, Claudio Carvalho, Paul Mackerras, linuxppc-dev,
Christoph Hellwig, Anshuman Khandual
In-Reply-To: <875zn2sgqs.fsf@concordia.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Thiago Jung Bauermann <bauerman@linux.ibm.com> writes:
>> From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>>
>> LPPACA structures need to be shared with the host. Hence they need to be in
>> shared memory. Instead of allocating individual chunks of memory for a
>> given structure from memblock, a contiguous chunk of memory is allocated
>> and then converted into shared memory. Subsequent allocation requests will
>> come from the contiguous chunk which will be always shared memory for all
>> structures.
>>
>> While we are able to use a kmem_cache constructor for the Debug Trace Log,
>> LPPACAs are allocated very early in the boot process (before SLUB is
>> available) so we need to use a simpler scheme here.
>>
>> Introduce helper is_svm_platform() which uses the S bit of the MSR to tell
>> whether we're running as a secure guest.
>>
>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
>> ---
>> arch/powerpc/include/asm/svm.h | 26 ++++++++++++++++++++
>> arch/powerpc/kernel/paca.c | 43 +++++++++++++++++++++++++++++++++-
>> 2 files changed, 68 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/include/asm/svm.h b/arch/powerpc/include/asm/svm.h
>> new file mode 100644
>> index 000000000000..fef3740f46a6
>> --- /dev/null
>> +++ b/arch/powerpc/include/asm/svm.h
>> @@ -0,0 +1,26 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +/*
>> + * SVM helper functions
>> + *
>> + * Copyright 2019 Anshuman Khandual, IBM Corporation.
>
> Are we sure this copyright date is correct?
I may be confused about which year the copyright refers to. I thought it
was the year when the patch was committed. If it is the first time the
patch was published then this one should be 2018.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* [PATCH 10/16] powerpc: prefer __section and __printf from compiler_attributes.h
From: Nick Desaulniers @ 2019-08-12 21:50 UTC (permalink / raw)
To: akpm
Cc: Song Liu, Alexei Starovoitov, Paul Mackerras, Rob Herring,
Daniel Borkmann, clang-built-linux, yhs, jpoimboe, sedat.dilek,
Thomas Gleixner, Allison Randal, Geoff Levand, Greg Kroah-Hartman,
Nick Desaulniers, linux-kernel, miguel.ojeda.sandonis, netdev,
bpf, linuxppc-dev, Martin KaFai Lau
In-Reply-To: <20190812215052.71840-1-ndesaulniers@google.com>
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
arch/powerpc/boot/main.c | 3 +--
arch/powerpc/boot/ps3.c | 6 ++----
arch/powerpc/include/asm/cache.h | 2 +-
arch/powerpc/kernel/btext.c | 2 +-
4 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
index 102cc546444d..3ccc84e06fc4 100644
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -150,8 +150,7 @@ static struct addr_range prep_initrd(struct addr_range vmlinux, void *chosen,
* edit the command line passed to vmlinux (by setting /chosen/bootargs).
* The buffer is put in it's own section so that tools may locate it easier.
*/
-static char cmdline[BOOT_COMMAND_LINE_SIZE]
- __attribute__((__section__("__builtin_cmdline")));
+static char cmdline[BOOT_COMMAND_LINE_SIZE] __section(__builtin_cmdline);
static void prep_cmdline(void *chosen)
{
diff --git a/arch/powerpc/boot/ps3.c b/arch/powerpc/boot/ps3.c
index c52552a681c5..70b2ed82d2de 100644
--- a/arch/powerpc/boot/ps3.c
+++ b/arch/powerpc/boot/ps3.c
@@ -24,8 +24,7 @@ extern int lv1_get_repository_node_value(u64 in_1, u64 in_2, u64 in_3,
#ifdef DEBUG
#define DBG(fmt...) printf(fmt)
#else
-static inline int __attribute__ ((format (printf, 1, 2))) DBG(
- const char *fmt, ...) {return 0;}
+static inline int __printf(1, 2) DBG(const char *fmt, ...) { return 0; }
#endif
BSS_STACK(4096);
@@ -35,8 +34,7 @@ BSS_STACK(4096);
* The buffer is put in it's own section so that tools may locate it easier.
*/
-static char cmdline[BOOT_COMMAND_LINE_SIZE]
- __attribute__((__section__("__builtin_cmdline")));
+static char cmdline[BOOT_COMMAND_LINE_SIZE] __section(__builtin_cmdline);
static void prep_cmdline(void *chosen)
{
diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index 45e3137ccd71..9114495855eb 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -91,7 +91,7 @@ static inline u32 l1_cache_bytes(void)
isync
#else
-#define __read_mostly __attribute__((__section__(".data..read_mostly")))
+#define __read_mostly __section(.data..read_mostly)
#ifdef CONFIG_PPC_BOOK3S_32
extern long _get_L2CR(void);
diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c
index 6dfceaa820e4..f57712a55815 100644
--- a/arch/powerpc/kernel/btext.c
+++ b/arch/powerpc/kernel/btext.c
@@ -26,7 +26,7 @@
static void scrollscreen(void);
#endif
-#define __force_data __attribute__((__section__(".data")))
+#define __force_data __section(.data)
static int g_loc_X __force_data;
static int g_loc_Y __force_data;
--
2.23.0.rc1.153.gdeed80330f-goog
^ permalink raw reply related
* Re: [PATCH v3 11/16] powerpc/pseries/svm: Export guest SVM status to user space via sysfs
From: Thiago Jung Bauermann @ 2019-08-12 23:21 UTC (permalink / raw)
To: Michael Ellerman
Cc: Anshuman Khandual, Alexey Kardashevskiy, Mike Anderson, Ram Pai,
linux-kernel, Claudio Carvalho, Ryan Grimm, Paul Mackerras,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <8736i6sfhn.fsf@concordia.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Thiago Jung Bauermann <bauerman@linux.ibm.com> writes:
>> From: Ryan Grimm <grimm@linux.vnet.ibm.com>
>>
>> User space might want to know it's running in a secure VM. It can't do
>> a mfmsr because mfmsr is a privileged instruction.
>>
>> The solution here is to create a cpu attribute:
>>
>> /sys/devices/system/cpu/svm
>>
>> which will read 0 or 1 based on the S bit of the guest's CPU 0.
>
> Why CPU 0?
>
> If we have different CPUs running with different MSR_S then something
> has gone badly wrong, no?
Yes, that would be very bad.
> So can't we just read the MSR on whatever CPU the sysfs code happens to
> run on.
Good point. I made the change in the patch below.
--
Thiago Jung Bauermann
IBM Linux Technology Center
From 2d951305e118bf286f8e83cbf396448085186357 Mon Sep 17 00:00:00 2001
From: Ryan Grimm <grimm@linux.vnet.ibm.com>
Date: Tue, 15 Jan 2019 11:56:29 -0600
Subject: [PATCH] powerpc/pseries/svm: Export guest SVM status to user space
via sysfs
User space might want to know it's running in a secure VM. It can't do
a mfmsr because mfmsr is a privileged instruction.
The solution here is to create a cpu attribute:
/sys/devices/system/cpu/svm
which will read 0 or 1 based on the S bit of the current CPU.
Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
---
arch/powerpc/kernel/sysfs.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index e2147d7c9e72..80a676da11cb 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -19,6 +19,7 @@
#include <asm/smp.h>
#include <asm/pmc.h>
#include <asm/firmware.h>
+#include <asm/svm.h>
#include "cacheinfo.h"
#include "setup.h"
@@ -715,6 +716,23 @@ static struct device_attribute pa6t_attrs[] = {
#endif /* HAS_PPC_PMC_PA6T */
#endif /* HAS_PPC_PMC_CLASSIC */
+#ifdef CONFIG_PPC_SVM
+static ssize_t show_svm(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%u\n", is_secure_guest());
+}
+static DEVICE_ATTR(svm, 0444, show_svm, NULL);
+
+static void create_svm_file(void)
+{
+ device_create_file(cpu_subsys.dev_root, &dev_attr_svm);
+}
+#else
+static void create_svm_file(void)
+{
+}
+#endif /* CONFIG_PPC_SVM */
+
static int register_cpu_online(unsigned int cpu)
{
struct cpu *c = &per_cpu(cpu_devices, cpu);
@@ -1058,6 +1076,8 @@ static int __init topology_init(void)
sysfs_create_dscr_default();
#endif /* CONFIG_PPC64 */
+ create_svm_file();
+
return 0;
}
subsys_initcall(topology_init);
^ permalink raw reply related
* Re: [PATCH v9 2/7] powerpc/mce: Fix MCE handling for huge pages
From: Santosh Sivaraj @ 2019-08-13 0:40 UTC (permalink / raw)
To: Sasha Levin, Sasha Levin, Balbir Singh, linuxppc-dev
Cc: Aneesh Kumar K.V, stable
In-Reply-To: <20190812135532.66AC120684@mail.kernel.org>
Sasha Levin <sashal@kernel.org> writes:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: ba41e1e1ccb9 powerpc/mce: Hookup derror (load/store) UE errors.
>
> The bot has tested the following trees: v5.2.8, v4.19.66.
>
> v5.2.8: Build OK!
> v4.19.66: Failed to apply! Possible dependencies:
> 360cae313702 ("KVM: PPC: Book3S HV: Nested guest entry via hypercall")
> 41f4e631daf8 ("KVM: PPC: Book3S HV: Extract PMU save/restore operations as C-callable functions")
> 884dfb722db8 ("KVM: PPC: Book3S HV: Simplify machine check handling")
> 89329c0be8bd ("KVM: PPC: Book3S HV: Clear partition table entry on vm teardown")
> 8e3f5fc1045d ("KVM: PPC: Book3S HV: Framework and hcall stubs for nested virtualization")
> 95a6432ce903 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests")
> a43c1590426c ("powerpc/pseries: Flush SLB contents on SLB MCE errors.")
> c05772018491 ("powerpc/64s: Better printing of machine check info for guest MCEs")
> d24ea8a7336a ("KVM: PPC: Book3S: Simplify external interrupt handling")
> df709a296ef7 ("KVM: PPC: Book3S HV: Simplify real-mode interrupt handling")
> f7035ce9f1df ("KVM: PPC: Book3S HV: Move interrupt delivery on guest entry to C code")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
I will send a backport once this has been merged upstream.
Thanks,
Santosh
>
> --
> Thanks,
> Sasha
^ permalink raw reply
* RE: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Xiaowei Bao @ 2019-08-13 2:10 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: mark.rutland@arm.com, Roy Zang, arnd@arndb.de,
devicetree@vger.kernel.org, gregkh@linuxfoundation.org,
kstewart@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
M.h. Lian, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, pombredanne@nexb.com,
bhelgaas@google.com, kishon@ti.com, shawnguo@kernel.org,
shawn.lin@rock-chips.com, Mingkai Hu
In-Reply-To: <20190812113543.GA25040@e121166-lin.cambridge.arm.com>
> -----Original Message-----
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Sent: 2019年8月12日 19:36
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: kishon@ti.com; bhelgaas@google.com; robh+dt@kernel.org;
> mark.rutland@arm.com; shawnguo@kernel.org; Leo Li
> <leoyang.li@nxp.com>; arnd@arndb.de; gregkh@linuxfoundation.org; M.h.
> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> Zang <roy.zang@nxp.com>; kstewart@linuxfoundation.org;
> pombredanne@nexb.com; shawn.lin@rock-chips.com;
> linux-pci@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linuxppc-dev@lists.ozlabs.org
> Subject: Re: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit
> property in EP driver.
>
> Caution: EXT Email
>
> On Mon, Aug 12, 2019 at 10:39:00AM +0000, Xiaowei Bao wrote:
> >
> >
> > > -----Original Message-----
> > > From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Sent: 2019年8月12日 18:12
> > > To: Xiaowei Bao <xiaowei.bao@nxp.com>; kishon@ti.com
> > > Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; arnd@arndb.de;
> > > gregkh@linuxfoundation.org; M.h. Lian <minghuan.lian@nxp.com>;
> > > Mingkai Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>;
> > > kstewart@linuxfoundation.org; pombredanne@nexb.com;
> > > shawn.lin@rock-chips.com; linux-pci@vger.kernel.org;
> > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > > Subject: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the
> > > bar_fixed_64bit property in EP driver.
> > >
> > > Caution: EXT Email
> > >
> > > First off:
> > >
> > > Trim the CC list, you CC'ed maintainers (and mailing lists) for no
> > > reasons whatsover.
> > [Xiaowei Bao]Hi Lorenzo, I am not clear why the mail list is the CC, I use the
> command "git send-email --to", I will try to send the patch again, do I need to
> modify the version is v4 when I send this patch again?
>
> Yes you do.
>
> Wrap lines to max 80 characters. There is no need to add [Xiaowei Bao].
OK, thanks a lot.
>
> 1) Read, email etiquette
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkernel
> newbies.org%2FPatchCulture&data=02%7C01%7Cxiaowei.bao%40nxp.c
> om%7C73a3b6160aad401b72d208d71f193ae1%7C686ea1d3bc2b4c6fa92cd
> 99c5c301635%7C0%7C0%7C637012065548351226&sdata=y6xa5nMkB
> qkWz7SBFdc%2F0lcQvzI%2F9HjEyC5%2Bk0RxczI%3D&reserved=0
>
> 2) get_maintainer.pl -f drivers/pci/controller/dwc/pci-layerscape.c
>
> Compare the output to the people in CC, trim it accordingly.
>
> 3) The NXP maintainers in the MAINTAINERS file have not given a single
> comment for this patchset. Either they show up or I will remove them
> from the MAINTAINERS list.
>
> 4) Before submitting patches, talk to someone at NXP who can help you
> format them in preparation for posting, I do not have time to write
> guidelines for everyone posting on linux-pci, sorry, the information
> is out there if you care to read it.
>
> Thanks,
> Lorenzo
>
> > >
> > > Then, read this:
> > >
> > > https://lore.ke
> > >
> rnel.org%2Flinux-pci%2F20171026223701.GA25649%40bhelgaas-glaptop.roa
> > >
> m.corp.google.com%2F&data=02%7C01%7Cxiaowei.bao%40nxp.com%7
> > >
> C1c586178e23c423a0e8808d71f0d8f6f%7C686ea1d3bc2b4c6fa92cd99c5c30
> > >
> 1635%7C0%7C0%7C637012015426788575&sdata=3bx1bDFIzik8FnD0wl
> > > duAUv7wtLdD1J3hQ3xNH2xmFY%3D&reserved=0
> > >
> > > and make your patches compliant please.
> > >
> > > On Fri, Jun 28, 2019 at 09:38:25AM +0800, Xiaowei Bao wrote:
> > > > The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1
> > > > is 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware,
> > > > so set the bar_fixed_64bit with 0x14.
> > > >
> > > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > > ---
> > > > v2:
> > > > - Replace value 0x14 with a macro.
> > > > v3:
> > > > - No change.
> > > >
> > > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
> > > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > index be61d96..227c33b 100644
> > > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > @@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie
> *pci)
> > > > .linkup_notifier = false,
> > > > .msi_capable = true,
> > > > .msix_capable = false,
> > > > + .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> > >
> > > I would appreciate Kishon's ACK on this.
> > >
> > > Lorenzo
> > >
> > > > };
> > > >
> > > > static const struct pci_epc_features*
> > > > --
> > > > 1.7.1
> > > >
^ permalink raw reply
* [PATCHv4 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Xiaowei Bao @ 2019-08-13 2:53 UTC (permalink / raw)
To: lorenzo.pieralisi, bhelgaas, minghuan.Lian, mingkai.hu, roy.zang,
l.stach, kishon, tpiepho, leonard.crestez, andrew.smirnov,
yue.wang, hayashi.kunihiko, dwmw, jonnyc, linux-pci, linux-kernel,
linuxppc-dev, linux-arm-kernel
Cc: Xiaowei Bao
The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1
is 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware,
so set the bar_fixed_64bit with 0x14.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
---
v2:
- Replace value 0x14 with a macro.
v3:
- No change.
v4:
- send the patch again with '--to'.
drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index be61d96..227c33b 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie *pci)
.linkup_notifier = false,
.msi_capable = true,
.msix_capable = false,
+ .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
};
static const struct pci_epc_features*
--
1.7.1
^ permalink raw reply related
* [PATCHv4 2/2] PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately
From: Xiaowei Bao @ 2019-08-13 2:53 UTC (permalink / raw)
To: lorenzo.pieralisi, bhelgaas, minghuan.Lian, mingkai.hu, roy.zang,
l.stach, kishon, tpiepho, leonard.crestez, andrew.smirnov,
yue.wang, hayashi.kunihiko, dwmw, jonnyc, linux-pci, linux-kernel,
linuxppc-dev, linux-arm-kernel
Cc: Xiaowei Bao
In-Reply-To: <20190813025317.48290-1-xiaowei.bao@nxp.com>
Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
---
v2:
- No change.
v3:
- modify the commit message.
v4:
- send the patch again with '--to'.
drivers/pci/controller/dwc/Kconfig | 20 ++++++++++++++++++--
drivers/pci/controller/dwc/Makefile | 3 ++-
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
index a6ce1ee..a41ccf5 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -131,13 +131,29 @@ config PCI_KEYSTONE_EP
DesignWare core functions to implement the driver.
config PCI_LAYERSCAPE
- bool "Freescale Layerscape PCIe controller"
+ bool "Freescale Layerscape PCIe controller - Host mode"
depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
depends on PCI_MSI_IRQ_DOMAIN
select MFD_SYSCON
select PCIE_DW_HOST
help
- Say Y here if you want PCIe controller support on Layerscape SoCs.
+ Say Y here if you want to enable PCIe controller support on Layerscape
+ SoCs to work in Host mode.
+ This controller can work either as EP or RC. The RCW[HOST_AGT_PEX]
+ determines which PCIe controller works in EP mode and which PCIe
+ controller works in RC mode.
+
+config PCI_LAYERSCAPE_EP
+ bool "Freescale Layerscape PCIe controller - Endpoint mode"
+ depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
+ depends on PCI_ENDPOINT
+ select PCIE_DW_EP
+ help
+ Say Y here if you want to enable PCIe controller support on Layerscape
+ SoCs to work in Endpoint mode.
+ This controller can work either as EP or RC. The RCW[HOST_AGT_PEX]
+ determines which PCIe controller works in EP mode and which PCIe
+ controller works in RC mode.
config PCI_HISI
depends on OF && (ARM64 || COMPILE_TEST)
diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
index b085dfd..824fde7 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -8,7 +8,8 @@ obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone.o
-obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o pci-layerscape-ep.o
+obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
+obj-$(CONFIG_PCI_LAYERSCAPE_EP) += pci-layerscape-ep.o
obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
--
1.7.1
^ permalink raw reply related
* [PATCH v4 0/3] Fix oops in shared-processor spinlocks
From: Christopher M. Riedl @ 2019-08-13 3:13 UTC (permalink / raw)
To: linuxppc-dev
Fixes an oops when calling the shared-processor spinlock implementation
from a non-SP LPAR. Also take this opportunity to refactor
SHARED_PROCESSOR a bit.
Reference: https://github.com/linuxppc/issues/issues/229
Changes since v3:
- Replace CONFIG_BOOK3S #ifdef with CONFIG_PPC_PSERIES in
is_shared_processor() to fix compile error reported by 0day-ci
Changes since v2:
- Directly call splpar_*_yield() to avoid duplicate call to
is_shared_processor() in some cases
Changes since v1:
- Improve comment wording to make it clear why the BOOK3S #ifdef is
required in is_shared_processor() in spinlock.h
- Replace empty #define of splpar_*_yield() with actual functions with
empty bodies
Christopher M. Riedl (3):
powerpc/spinlocks: Refactor SHARED_PROCESSOR
powerpc/spinlocks: Rename SPLPAR-only spinlocks
powerpc/spinlocks: Fix oops in shared-processor spinlocks
arch/powerpc/include/asm/spinlock.h | 62 +++++++++++++++++++++--------
arch/powerpc/lib/locks.c | 6 +--
2 files changed, 48 insertions(+), 20 deletions(-)
--
2.22.0
^ permalink raw reply
* [PATCH v4 1/3] powerpc/spinlocks: Refactor SHARED_PROCESSOR
From: Christopher M. Riedl @ 2019-08-13 3:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Andrew Donnellan
In-Reply-To: <20190813031314.1828-1-cmr@informatik.wtf>
Determining if a processor is in shared processor mode is not a constant
so don't hide it behind a #define.
Signed-off-by: Christopher M. Riedl <cmr@informatik.wtf>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
---
arch/powerpc/include/asm/spinlock.h | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/spinlock.h b/arch/powerpc/include/asm/spinlock.h
index a47f827bc5f1..e9c60fbcc8fe 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -101,15 +101,27 @@ static inline int arch_spin_trylock(arch_spinlock_t *lock)
#if defined(CONFIG_PPC_SPLPAR)
/* We only yield to the hypervisor if we are in shared processor mode */
-#define SHARED_PROCESSOR (lppaca_shared_proc(local_paca->lppaca_ptr))
extern void __spin_yield(arch_spinlock_t *lock);
extern void __rw_yield(arch_rwlock_t *lock);
#else /* SPLPAR */
#define __spin_yield(x) barrier()
#define __rw_yield(x) barrier()
-#define SHARED_PROCESSOR 0
#endif
+static inline bool is_shared_processor(void)
+{
+/*
+ * LPPACA is only available on Pseries so guard anything LPPACA related to
+ * allow other platforms (which include this common header) to compile.
+ */
+#ifdef CONFIG_PPC_PSERIES
+ return (IS_ENABLED(CONFIG_PPC_SPLPAR) &&
+ lppaca_shared_proc(local_paca->lppaca_ptr));
+#else
+ return false;
+#endif
+}
+
static inline void arch_spin_lock(arch_spinlock_t *lock)
{
while (1) {
@@ -117,7 +129,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
break;
do {
HMT_low();
- if (SHARED_PROCESSOR)
+ if (is_shared_processor())
__spin_yield(lock);
} while (unlikely(lock->slock != 0));
HMT_medium();
@@ -136,7 +148,7 @@ void arch_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags)
local_irq_restore(flags);
do {
HMT_low();
- if (SHARED_PROCESSOR)
+ if (is_shared_processor())
__spin_yield(lock);
} while (unlikely(lock->slock != 0));
HMT_medium();
@@ -226,7 +238,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
break;
do {
HMT_low();
- if (SHARED_PROCESSOR)
+ if (is_shared_processor())
__rw_yield(rw);
} while (unlikely(rw->lock < 0));
HMT_medium();
@@ -240,7 +252,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
break;
do {
HMT_low();
- if (SHARED_PROCESSOR)
+ if (is_shared_processor())
__rw_yield(rw);
} while (unlikely(rw->lock != 0));
HMT_medium();
--
2.22.0
^ permalink raw reply related
* [PATCH v4 3/3] powerpc/spinlocks: Fix oops in shared-processor spinlocks
From: Christopher M. Riedl @ 2019-08-13 3:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20190813031314.1828-1-cmr@informatik.wtf>
Booting w/ ppc64le_defconfig + CONFIG_PREEMPT results in the attached
kernel trace due to calling shared-processor spinlocks while not running
in an SPLPAR. Previously, the out-of-line spinlocks implementations were
selected based on CONFIG_PPC_SPLPAR at compile time without a runtime
shared-processor LPAR check.
To fix, call the actual spinlock implementations from a set of common
functions, spin_yield() and rw_yield(), which check for shared-processor
LPAR during runtime and select the appropriate lock implementation.
[ 0.430878] BUG: Kernel NULL pointer dereference at 0x00000100
[ 0.431991] Faulting instruction address: 0xc000000000097f88
[ 0.432934] Oops: Kernel access of bad area, sig: 7 [#1]
[ 0.433448] LE PAGE_SIZE=64K MMU=Radix MMU=Hash PREEMPT SMP NR_CPUS=2048 NUMA PowerNV
[ 0.434479] Modules linked in:
[ 0.435055] CPU: 0 PID: 2 Comm: kthreadd Not tainted 5.2.0-rc6-00491-g249155c20f9b #28
[ 0.435730] NIP: c000000000097f88 LR: c000000000c07a88 CTR: c00000000015ca10
[ 0.436383] REGS: c0000000727079f0 TRAP: 0300 Not tainted (5.2.0-rc6-00491-g249155c20f9b)
[ 0.437004] MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 84000424 XER: 20040000
[ 0.437874] CFAR: c000000000c07a84 DAR: 0000000000000100 DSISR: 00080000 IRQMASK: 1
[ 0.437874] GPR00: c000000000c07a88 c000000072707c80 c000000001546300 c00000007be38a80
[ 0.437874] GPR04: c0000000726f0c00 0000000000000002 c00000007279c980 0000000000000100
[ 0.437874] GPR08: c000000001581b78 0000000080000001 0000000000000008 c00000007279c9b0
[ 0.437874] GPR12: 0000000000000000 c000000001730000 c000000000142558 0000000000000000
[ 0.437874] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.437874] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.437874] GPR24: c00000007be38a80 c000000000c002f4 0000000000000000 0000000000000000
[ 0.437874] GPR28: c000000072221a00 c0000000726c2600 c00000007be38a80 c00000007be38a80
[ 0.443992] NIP [c000000000097f88] __spin_yield+0x48/0xa0
[ 0.444523] LR [c000000000c07a88] __raw_spin_lock+0xb8/0xc0
[ 0.445080] Call Trace:
[ 0.445670] [c000000072707c80] [c000000072221a00] 0xc000000072221a00 (unreliable)
[ 0.446425] [c000000072707cb0] [c000000000bffb0c] __schedule+0xbc/0x850
[ 0.447078] [c000000072707d70] [c000000000c002f4] schedule+0x54/0x130
[ 0.447694] [c000000072707da0] [c0000000001427dc] kthreadd+0x28c/0x2b0
[ 0.448389] [c000000072707e20] [c00000000000c1cc] ret_from_kernel_thread+0x5c/0x70
[ 0.449143] Instruction dump:
[ 0.449821] 4d9e0020 552a043e 210a07ff 79080fe0 0b080000 3d020004 3908b878 794a1f24
[ 0.450587] e8e80000 7ce7502a e8e70000 38e70100 <7ca03c2c> 70a70001 78a50020 4d820020
[ 0.452808] ---[ end trace 474d6b2b8fc5cb7e ]---
Signed-off-by: Christopher M. Riedl <cmr@informatik.wtf>
---
arch/powerpc/include/asm/spinlock.h | 36 ++++++++++++++++++++---------
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/spinlock.h b/arch/powerpc/include/asm/spinlock.h
index 0d04d468f660..e9a960e28f3c 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -103,11 +103,9 @@ static inline int arch_spin_trylock(arch_spinlock_t *lock)
/* We only yield to the hypervisor if we are in shared processor mode */
void splpar_spin_yield(arch_spinlock_t *lock);
void splpar_rw_yield(arch_rwlock_t *lock);
-#define __spin_yield(x) splpar_spin_yield(x)
-#define __rw_yield(x) splpar_rw_yield(x)
#else /* SPLPAR */
-#define __spin_yield(x) barrier()
-#define __rw_yield(x) barrier()
+static inline void splpar_spin_yield(arch_spinlock_t *lock) {};
+static inline void splpar_rw_yield(arch_rwlock_t *lock) {};
#endif
static inline bool is_shared_processor(void)
@@ -124,6 +122,22 @@ static inline bool is_shared_processor(void)
#endif
}
+static inline void spin_yield(arch_spinlock_t *lock)
+{
+ if (is_shared_processor())
+ splpar_spin_yield(lock);
+ else
+ barrier();
+}
+
+static inline void rw_yield(arch_rwlock_t *lock)
+{
+ if (is_shared_processor())
+ splpar_rw_yield(lock);
+ else
+ barrier();
+}
+
static inline void arch_spin_lock(arch_spinlock_t *lock)
{
while (1) {
@@ -132,7 +146,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
do {
HMT_low();
if (is_shared_processor())
- __spin_yield(lock);
+ splpar_spin_yield(lock);
} while (unlikely(lock->slock != 0));
HMT_medium();
}
@@ -151,7 +165,7 @@ void arch_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags)
do {
HMT_low();
if (is_shared_processor())
- __spin_yield(lock);
+ splpar_spin_yield(lock);
} while (unlikely(lock->slock != 0));
HMT_medium();
local_irq_restore(flags_dis);
@@ -241,7 +255,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
do {
HMT_low();
if (is_shared_processor())
- __rw_yield(rw);
+ splpar_rw_yield(rw);
} while (unlikely(rw->lock < 0));
HMT_medium();
}
@@ -255,7 +269,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
do {
HMT_low();
if (is_shared_processor())
- __rw_yield(rw);
+ splpar_rw_yield(rw);
} while (unlikely(rw->lock != 0));
HMT_medium();
}
@@ -295,9 +309,9 @@ static inline void arch_write_unlock(arch_rwlock_t *rw)
rw->lock = 0;
}
-#define arch_spin_relax(lock) __spin_yield(lock)
-#define arch_read_relax(lock) __rw_yield(lock)
-#define arch_write_relax(lock) __rw_yield(lock)
+#define arch_spin_relax(lock) spin_yield(lock)
+#define arch_read_relax(lock) rw_yield(lock)
+#define arch_write_relax(lock) rw_yield(lock)
/* See include/linux/spinlock.h */
#define smp_mb__after_spinlock() smp_mb()
--
2.22.0
^ permalink raw reply related
* [PATCH v4 2/3] powerpc/spinlocks: Rename SPLPAR-only spinlocks
From: Christopher M. Riedl @ 2019-08-13 3:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Andrew Donnellan
In-Reply-To: <20190813031314.1828-1-cmr@informatik.wtf>
The __rw_yield and __spin_yield locks only pertain to SPLPAR mode.
Rename them to make this relationship obvious.
Signed-off-by: Christopher M. Riedl <cmr@informatik.wtf>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
---
arch/powerpc/include/asm/spinlock.h | 6 ++++--
arch/powerpc/lib/locks.c | 6 +++---
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/spinlock.h b/arch/powerpc/include/asm/spinlock.h
index e9c60fbcc8fe..0d04d468f660 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -101,8 +101,10 @@ static inline int arch_spin_trylock(arch_spinlock_t *lock)
#if defined(CONFIG_PPC_SPLPAR)
/* We only yield to the hypervisor if we are in shared processor mode */
-extern void __spin_yield(arch_spinlock_t *lock);
-extern void __rw_yield(arch_rwlock_t *lock);
+void splpar_spin_yield(arch_spinlock_t *lock);
+void splpar_rw_yield(arch_rwlock_t *lock);
+#define __spin_yield(x) splpar_spin_yield(x)
+#define __rw_yield(x) splpar_rw_yield(x)
#else /* SPLPAR */
#define __spin_yield(x) barrier()
#define __rw_yield(x) barrier()
diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c
index 6550b9e5ce5f..6440d5943c00 100644
--- a/arch/powerpc/lib/locks.c
+++ b/arch/powerpc/lib/locks.c
@@ -18,7 +18,7 @@
#include <asm/hvcall.h>
#include <asm/smp.h>
-void __spin_yield(arch_spinlock_t *lock)
+void splpar_spin_yield(arch_spinlock_t *lock)
{
unsigned int lock_value, holder_cpu, yield_count;
@@ -36,14 +36,14 @@ void __spin_yield(arch_spinlock_t *lock)
plpar_hcall_norets(H_CONFER,
get_hard_smp_processor_id(holder_cpu), yield_count);
}
-EXPORT_SYMBOL_GPL(__spin_yield);
+EXPORT_SYMBOL_GPL(splpar_spin_yield);
/*
* Waiting for a read lock or a write lock on a rwlock...
* This turns out to be the same for read and write locks, since
* we only know the holder if it is write-locked.
*/
-void __rw_yield(arch_rwlock_t *rw)
+void splpar_rw_yield(arch_rwlock_t *rw)
{
int lock_value;
unsigned int holder_cpu, yield_count;
--
2.22.0
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race
From: Lijun Pan @ 2019-08-13 3:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, kvm-ppc, kvm, David Gibson
In-Reply-To: <20190812050743.aczgcqwmtqpkbx2l@oak.ozlabs.ibm.com>
> On Aug 12, 2019, at 12:07 AM, Paul Mackerras <paulus@ozlabs.org> wrote:
>
> ---
> arch/powerpc/include/asm/xive.h | 8 ++++
> arch/powerpc/kvm/book3s_xive.c | 31 ++++++++++++++
> arch/powerpc/sysdev/xive/common.c | 87 ++++++++++++++++++++++++++++-----------
> 3 files changed, 103 insertions(+), 23 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
> index e4016985764e..efb0e597b272 100644
> --- a/arch/powerpc/include/asm/xive.h
> +++ b/arch/powerpc/include/asm/xive.h
> @@ -46,7 +46,15 @@ struct xive_irq_data {
>
> /* Setup/used by frontend */
> int target;
> + /*
> + * saved_p means that there is a queue entry for this interrupt
> + * in some CPU's queue (not including guest vcpu queues), even
> + * if P is not set in the source ESB.
> + * stale_p means that there is no queue entry for this interrupt
> + * in some CPU's queue, even if P is set in the source ESB.
> + */
> bool saved_p;
> + bool stale_p;
> };
> #define XIVE_IRQ_FLAG_STORE_EOI 0x01
> #define XIVE_IRQ_FLAG_LSI 0x02
> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> index 09f838aa3138..74eea009c095 100644
> --- a/arch/powerpc/kvm/book3s_xive.c
> +++ b/arch/powerpc/kvm/book3s_xive.c
> @@ -160,6 +160,9 @@ static irqreturn_t xive_esc_irq(int irq, void *data)
> */
> vcpu->arch.xive_esc_on = false;
>
> + /* This orders xive_esc_on = false vs. subsequent stale_p = true */
> + smp_wmb(); /* goes with smp_mb() in cleanup_single_escalation */
> +
> return IRQ_HANDLED;
> }
>
> @@ -1113,6 +1116,31 @@ void kvmppc_xive_disable_vcpu_interrupts(struct kvm_vcpu *vcpu)
> vcpu->arch.xive_esc_raddr = 0;
> }
>
> +/*
> + * In single escalation mode, the escalation interrupt is marked so
> + * that EOI doesn't re-enable it, but just sets the stale_p flag to
> + * indicate that the P bit has already been dealt with. However, the
> + * assembly code that enters the guest sets PQ to 00 without clearing
> + * stale_p (because it has no easy way to address it). Hence we have
> + * to adjust stale_p before shutting down the interrupt.
> + */
> +static void cleanup_single_escalation(struct kvm_vcpu *vcpu,
> + struct kvmppc_xive_vcpu *xc, int irq)
> +{
> + struct irq_data *d = irq_get_irq_data(irq);
> + struct xive_irq_data *xd = irq_data_get_irq_handler_data(d);
> +
> + /*
> + * This slightly odd sequence gives the right result
> + * (i.e. stale_p set if xive_esc_on is false) even if
> + * we race with xive_esc_irq() and xive_irq_eoi().
> + */
Hi Paul,
I don’t quite understand the logic here.
Are you saying the code sequence is
vcpu->arch.xive_esc_on = false; (xive_esc_irq)
then
xd->stale_p = true; (cleanup_single_escaltion)
> + xd->stale_p = false;
> + smp_mb(); /* paired with smb_wmb in xive_esc_irq */
> + if (!vcpu->arch.xive_esc_on)
> + xd->stale_p = true;
> +}
> +
> void kvmppc_xive_cleanup_vcpu(struct kvm_vcpu *vcpu)
> {
> struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
> @@ -1137,6 +1165,9 @@ void kvmppc_xive_cleanup_vcpu(struct kvm_vcpu *vcpu)
> /* Free escalations */
> for (i = 0; i < KVMPPC_XIVE_Q_COUNT; i++) {
> if (xc->esc_virq[i]) {
> + if (xc->xive->single_escalation)
> + cleanup_single_escalation(vcpu, xc,
> + xc->esc_virq[i]);
> free_irq(xc->esc_virq[i], vcpu);
> irq_dispose_mapping(xc->esc_virq[i]);
> kfree(xc->esc_virq_names[i]);
> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> index 1cdb39575eae..be86fce1a84e 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -135,7 +135,7 @@ static u32 xive_read_eq(struct xive_q *q, bool just_peek)
> static u32 xive_scan_interrupts(struct xive_cpu *xc, bool just_peek)
> {
> u32 irq = 0;
> - u8 prio;
> + u8 prio = 0;
>
> /* Find highest pending priority */
> while (xc->pending_prio != 0) {
> @@ -148,8 +148,19 @@ static u32 xive_scan_interrupts(struct xive_cpu *xc, bool just_peek)
> irq = xive_read_eq(&xc->queue[prio], just_peek);
>
> /* Found something ? That's it */
> - if (irq)
> - break;
> + if (irq) {
> + if (just_peek || irq_to_desc(irq))
> + break;
> + /*
> + * We should never get here; if we do then we must
> + * have failed to synchronize the interrupt properly
> + * when shutting it down.
> + */
> + pr_crit("xive: got interrupt %d without descriptor, dropping\n",
> + irq);
> + WARN_ON(1);
> + continue;
> + }
>
> /* Clear pending bits */
> xc->pending_prio &= ~(1 << prio);
> @@ -307,6 +318,7 @@ static void xive_do_queue_eoi(struct xive_cpu *xc)
> */
> static void xive_do_source_eoi(u32 hw_irq, struct xive_irq_data *xd)
> {
> + xd->stale_p = false;
> /* If the XIVE supports the new "store EOI facility, use it */
> if (xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
> xive_esb_write(xd, XIVE_ESB_STORE_EOI, 0);
> @@ -350,7 +362,7 @@ static void xive_do_source_eoi(u32 hw_irq, struct xive_irq_data *xd)
> }
> }
>
> -/* irq_chip eoi callback */
> +/* irq_chip eoi callback, called with irq descriptor lock held */
> static void xive_irq_eoi(struct irq_data *d)
> {
> struct xive_irq_data *xd = irq_data_get_irq_handler_data(d);
> @@ -366,6 +378,8 @@ static void xive_irq_eoi(struct irq_data *d)
> if (!irqd_irq_disabled(d) && !irqd_is_forwarded_to_vcpu(d) &&
> !(xd->flags & XIVE_IRQ_NO_EOI))
> xive_do_source_eoi(irqd_to_hwirq(d), xd);
> + else
> + xd->stale_p = true;
>
> /*
> * Clear saved_p to indicate that it's no longer occupying
> @@ -397,11 +411,16 @@ static void xive_do_source_set_mask(struct xive_irq_data *xd,
> */
> if (mask) {
> val = xive_esb_read(xd, XIVE_ESB_SET_PQ_01);
> - xd->saved_p = !!(val & XIVE_ESB_VAL_P);
> - } else if (xd->saved_p)
> + if (!xd->stale_p && !!(val & XIVE_ESB_VAL_P))
> + xd->saved_p = true;
> + xd->stale_p = false;
> + } else if (xd->saved_p) {
> xive_esb_read(xd, XIVE_ESB_SET_PQ_10);
> - else
> + xd->saved_p = false;
Should we also explicitly set xd->stale_p = true; here?
> + } else {
> xive_esb_read(xd, XIVE_ESB_SET_PQ_00);
> + xd->stale_p = false;
Should we also explicitly set xd->saved_p = true; here?
Thanks,
Lijun
^ permalink raw reply
* Re: [PATCH] dmaengine: fsldma: Mark expected switch fall-through
From: Vinod Koul @ 2019-08-13 4:38 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: linux-kernel, Li Yang, Zhang Wei, dmaengine, Dan Williams,
linuxppc-dev
In-Reply-To: <20190812002159.GA26899@embeddedor>
On 11-08-19, 19:22, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> Fix the following warning (Building: powerpc-ppa8548_defconfig powerpc):
>
> drivers/dma/fsldma.c: In function ‘fsl_dma_chan_probe’:
> drivers/dma/fsldma.c:1165:26: warning: this statement may fall through [-Wimplicit-fallthrough=]
> chan->toggle_ext_pause = fsl_chan_toggle_ext_pause;
> ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/dma/fsldma.c:1166:2: note: here
> case FSL_DMA_IP_83XX:
> ^~~~
Applied, thanks
--
~Vinod
^ permalink raw reply
* Re: Freeze on ppc32 MPC8248 board with 5.2 kernel
From: Christophe Leroy @ 2019-08-13 4:41 UTC (permalink / raw)
To: Doug Crawford, linuxppc-dev
In-Reply-To: <CAESxVDiyXu+=6+YmLej3K=i55h3=Z9JLA8JgrDn3fEQGUuSq7Q@mail.gmail.com>
Hi Doug,
Le 26/07/2019 à 00:30, Doug Crawford a écrit :
> We have a ppc32 MPC8248 board that is working perfectly with the 4.19
> kernel.
> We have noticed two issues with the 5.2 kernel:
Have you tried 5.0 and 5.1 ?
>
> 1) If the new CONFIG_PPC_KUAP (kernel userspace access protection) is
> enabled the kernel freezes right after initializing all the drivers and
> just before starting /sbin/init.
Can you provide your .config ?
Can you also provide the output of the boot console ?
>
> 2) If CONFIG_PPC_KUAP is disabled the system starts up, but any user
> space program will hang indefinitely after calling the GCC atomic
> "__sync_bool_compare_and_swap". This happens when nginx starts. The
> same nginx binary works fine on a 4.19 kernel.
Can you provide 'dmesg' ?
What version of GCC do you use ?
Have you tried a simple program doing nothing else than
__sync_bool_compare_and_swap() ?
Can you provide a disassembly of the function that uses
__sync_bool_compare_and_swap() ?
Thanks
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