__SXXX/__PXXX macros is an unnecessary abstraction layer in creating the
generic protection_map[] array which is used for vm_get_page_prot(). This
abstraction layer can be avoided, if the platforms just define the array
protection_map[] for all possible vm_flags access permission combinations
and a
Build protect generic protection_map[] array with __P000, so that it can be
moved inside all the platforms one after the other. Otherwise there will be
build failures during this process. CONFIG_ARCH_HAS_VM_GET_PAGE_PROT cannot
be used for this purpose as only certain platforms enable this config n
This just converts the generic vm_get_page_prot() implementation into a new
macro i.e DECLARE_VM_GET_PAGE_PROT which later can be used across platforms
when enabling them with ARCH_HAS_VM_GET_PAGE_PROT. This does not create any
functional change.
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux
This moves protection_map[] inside the platform and while here, also enable
ARCH_HAS_VM_GET_PAGE_PROT on 32 bit and nohash 64 (aka book3e/64) platforms
via DECLARE_VM_GET_PAGE_PROT.
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vg
This moves protection_map[] inside the platform and while here, also enable
ARCH_HAS_VM_GET_PAGE_PROT on 32 bit platforms via DECLARE_VM_GET_PAGE_PROT.
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Reviewed-by: Sam Ravnborg
Signed-off-by: Anshuman Khandual
This moves protection_map[] inside the platform and makes it a static.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Reviewed-by: Catalin Marinas
Signed-off-by: Anshuman Khandual
---
arch/arm64/include/asm/pgtable-prot.h | 18 ---
This moves protection_map[] inside the platform and makes it a static. This
also defines a helper function add_encrypt_protection_map() that can update
the protection_map[] array with pgprot_encrypted().
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: x...@kernel.org
Cc: linux-ker...@vger.kernel.org
Rev
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Jonas Bon
Now that protection_map[] has been moved inside those platforms that enable
ARCH_HAS_VM_GET_PAGE_PROT. Hence generic protection_map[] array now can be
protected with CONFIG_ARCH_HAS_VM_GET_PAGE_PROT intead of __P000.
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Review
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Michal Si
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Huacai Ch
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Chris Zan
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Brian Cai
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: "James E.
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Richard H
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Dinh Nguy
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Paul Walm
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Thomas Bo
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Geert Uyt
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Thomas Bo
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Heiko Car
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Vineet Gu
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: linux-i..
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Russell K
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Jeff Dike
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dropped which are no longer needed.
Cc: Yoshinori
Now all the platforms enable ARCH_HAS_GET_PAGE_PROT. They define and export
own vm_get_page_prot() whether custom or standard DECLARE_VM_GET_PAGE_PROT.
Hence there is no need for default generic fallback for vm_get_page_prot().
Just drop this fallback and also ARCH_HAS_GET_PAGE_PROT mechanism.
Cc:
On 10/07/2022 22:32, Alexey Kardashevskiy wrote:
On 10/07/2022 16:29, Jason Gunthorpe wrote:
On Sat, Jul 09, 2022 at 12:58:00PM +1000, Alexey Kardashevskiy wrote:
driver->ops->attach_group on POWER attaches a group so VFIO claims
ownership
over a group, not devices. Underlying API
(pnv_io
Commit 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
enlarged the CPU selection logic to PPC32 by removing depend to
PPC64, and failed to restrict that depend to E5500_CPU and E6500_CPU.
Fortunately that got unnoticed because -mcpu=8540 will override the
-mcpu=e500mc64 or -mpcu=e6500
Since commit 4bf4f42a2feb ("powerpc/kbuild: Set default generic
machine type for 32-bit compile"), when building a 32 bits kernel
with a bi-arch version of GCC, or when building a book3s/32 kernel,
the option -mcpu=powerpc is passed to GCC at all time, relying on it
being eventually overriden by a
Building ppc40x_defconfig leads to following error
CC arch/powerpc/kernel/process.o
{standard input}: Assembler messages:
{standard input}:626: Error: unrecognized opcode: `wrteei'
Add -mcpu=405 by default.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/Kconfig.cputype | 7 +
Building ppc40x_defconfig leads to following error
CC arch/powerpc/kernel/idle.o
{standard input}: Assembler messages:
{standard input}:67: Error: unrecognized opcode: `wrteei'
{standard input}:78: Error: unrecognized opcode: `wrteei'
Add -mcpu=440 by default and alternatively 464 and 476.
With GCC 12, corenet64_smp_defconfig leads to the following build errors:
CC arch/powerpc/kernel/irq.o
{standard input}: Assembler messages:
{standard input}:3616: Error: unrecognized opcode: `wrteei'
{standard input}:5689: Error: unrecognized opcode: `wrteei'
CC arch/powerpc/kernel/
Le 10/07/2022 à 19:57, Pali Rohár a écrit :
> On Sunday 10 July 2022 17:38:33 Christophe Leroy wrote:
>> Le 09/07/2022 à 12:23, Pali Rohár a écrit :
>
> -ifdef CONFIG_PPC_BOOK3S_64
> ifdef CONFIG_CPU_LITTLE_ENDIAN
> -CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power8
> -CFL
On Mon, Jul 11, 2022 at 4:19 PM Christophe Leroy
wrote:
> @@ -183,6 +183,18 @@ config 405_CPU
> bool "40x family"
> depends on 40x
>
> +config 440_CPU
> + bool "440 (44x family)"
> + depends on 44x
> +
> +config 464_CPU
> + bool "464 (44x family)"
> + depend
Oops, I wanted to include Pali and Segher when I sent the series, I
prepared a script including them but used the wrong script at the end.
Le 11/07/2022 à 17:05, Arnd Bergmann a écrit :
> On Mon, Jul 11, 2022 at 4:19 PM Christophe Leroy
> wrote:
>> @@ -183,6 +183,18 @@ config 405_CPU
>>
On Sat, Jul 09, 2022 at 09:26:11AM +, Christophe Leroy wrote:
> If I select the GENERIC_CPU or e5500 (with altivec) I get:
>
>CC arch/powerpc/kernel/irq.o
> {standard input}: Assembler messages:
> {standard input}:3535: Error: unrecognized opcode: `wrteei'
> {standard input}:5608: Err
Hi!
On Mon, Jul 11, 2022 at 04:19:29PM +0200, Christophe Leroy wrote:
> Commit 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
> enlarged the CPU selection logic to PPC32 by removing depend to
> PPC64, and failed to restrict that depend to E5500_CPU and E6500_CPU.
> Fortunately that go
On Mon, Jul 11, 2022 at 04:19:30PM +0200, Christophe Leroy wrote:
> Since commit 4bf4f42a2feb ("powerpc/kbuild: Set default generic
> machine type for 32-bit compile"), when building a 32 bits kernel
> with a bi-arch version of GCC, or when building a book3s/32 kernel,
> the option -mcpu=powerpc is
On Mon, Jul 11, 2022 at 05:05:04PM +0200, Arnd Bergmann wrote:
> Is there any value in building for -mcpu=440 or -mcpu=464 when targeting a
> 476?
The original 440 had a very short pipeline. Later IBM 4xx have a longer
pipeline. Getting this right (with -mtune=, or just with -mcpu=) is
importan
Le 11/07/2022 à 18:14, Segher Boessenkool a écrit :
> On Sat, Jul 09, 2022 at 09:26:11AM +, Christophe Leroy wrote:
>> If I select the GENERIC_CPU or e5500 (with altivec) I get:
>>
>> CC arch/powerpc/kernel/irq.o
>> {standard input}: Assembler messages:
>> {standard input}:3535: Erro
Le 11/07/2022 à 18:39, Segher Boessenkool a écrit :
> Hi!
>
> On Mon, Jul 11, 2022 at 04:19:29PM +0200, Christophe Leroy wrote:
>> Commit 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
>> enlarged the CPU selection logic to PPC32 by removing depend to
>> PPC64, and failed to restric
https://bugzilla.kernel.org/show_bug.cgi?id=216238
Bug ID: 216238
Summary: Kernel 5.10.129 fails to boot on a Talos 2 with HASH
MMU (PPC_RADIX_MMU not set) with
CONFIG_PAGE_POISONING=y
Product: Platform Specific/Hardware
https://bugzilla.kernel.org/show_bug.cgi?id=216238
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 301394
--> https://bugzilla.kernel.org/attachment.cgi?id=301394&action=edit
kernel .config (kernel 5.10.129, with PAGE_POISONING, Talos II)
--
You may reply to this em
https://bugzilla.kernel.org/show_bug.cgi?id=216238
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Some data about the machine:
# inxi -bZ
System:
Host: T1000 Kernel: 5.10.129-gentoo-P9 ppc64 bits: 64 Console: pty pts/0
Distro: Gentoo Base System release 2.8
Machine:
Type: PPC S
https://bugzilla.kernel.org/show_bug.cgi?id=216183
--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 301395
--> https://bugzilla.kernel.org/attachment.cgi?id=301395&action=edit
kernel .config (kernel 5.10.129, Talos II)
Tried some LTS kernels and with 5.10.x I got a .c
https://bugzilla.kernel.org/show_bug.cgi?id=216183
--- Comment #7 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 301396
--> https://bugzilla.kernel.org/attachment.cgi?id=301396&action=edit
kernel dmesg (kernel 5.10.129, Talos II)
--
You may reply to this email to add a comment.
On Mon, Jul 11, 2022 at 11:24:32PM +1000, Alexey Kardashevskiy wrote:
> I really think that for 5.19 we should really move this blocked domain
> business to Type1 like this:
>
> https://github.com/aik/linux/commit/96f80c8db03b181398ad355f6f90e574c3ada4bf
This creates the same security bug for po
A bitmap_zalloc() must be balanced by a corresponding bitmap_free() in the
error handling path of afu_allocate_irqs().
Signed-off-by: Christophe JAILLET
---
The error handling path should be done in the reversed order but it should
work as-is.
---
drivers/misc/cxl/irq.c | 1 +
1 file changed, 1
On Mon, 11 Jul 2022 12:35:34 +0530 Anshuman Khandual
wrote:
> This series drops __SXXX/__PXXX macros from across platforms in the tree.
I've updated mm-unstable to this version, thanks. I skipped the added-to-mm
emails to avoid wearing out people's inboxes.
Reissuing a 26-patch series N times
On 7/11/22 02:05, Anshuman Khandual wrote:
This enables ARCH_HAS_VM_GET_PAGE_PROT on the platform and exports standard
vm_get_page_prot() implementation via DECLARE_VM_GET_PAGE_PROT, which looks
up a private and static protection_map[] array. Subsequently all __SXXX and
__PXXX macros can be dr
Use bitmap_zalloc()/bitmap_free() instead of hand-writing them.
It is less verbose and it improves the semantic.
Signed-off-by: Christophe JAILLET
---
drivers/misc/cxl/context.c | 2 +-
drivers/misc/cxl/guest.c | 2 +-
drivers/misc/cxl/irq.c | 3 +--
drivers/misc/cxl/of.c | 5 ++---
Hi!
On Mon, Jul 11, 2022 at 05:32:09PM +, Christophe Leroy wrote:
> Le 11/07/2022 à 18:14, Segher Boessenkool a écrit :
> >> CC arch/powerpc/kernel/irq.o
> >> {standard input}: Assembler messages:
> >> {standard input}:3535: Error: unrecognized opcode: `wrteei'
> >> {standard input}:5
Hi Stefan,
On Thu, 2022-07-07 at 13:20 -0400, Stefan Berger wrote:
> - /*
> -* For both vtpm/tpm, firmware has log addr and log size in big
> -* endian format. But in case of vtpm, there is a method called
> -* sml-handover which is run during kernel init even before
On Thu, 2022-07-07 at 13:20 -0400, Stefan Berger wrote:
> Refactor IMA buffer related functions to make them reusable for carrying
> TPM logs across kexec.
>
> Signed-off-by: Stefan Berger
> Cc: Rob Herring
> Cc: Frank Rowand
> Cc: Mimi Zohar
Reviewed-by: Mimi Zohar
For a long time, PCSs have been tightly coupled with their MACs. For
this reason, the MAC creates the "phy" or mdio device, and then passes
it to the PCS to initialize. This has a few disadvantages:
- Each MAC must re-implement the same steps to look up/create a PCS
- The PCS cannot use functions
This adds appropriate compatible strings for Lynx PCSs on PowerPC QorIQ
platforms. This also changes the node name to avoid warnings from
ethernet-phy.yaml.
Signed-off-by: Sean Anderson
---
arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/qoriq-f
On Wed, Jul 06, 2022 at 12:43:04PM +0200, Pali Rohár wrote:
> Function pci_device_from_OF_node() is used only in powermac code.
> So hide it from all other platforms as it is unsed.
s/unsed/unused/ (same typo in 3/5 patch)
These are for the powerpc folks, so I'm just kibbitzing here.
> Signed-of
Minor cleanup to remove unused function and declarations.
Murilo Opsfelder Araujo (2):
KVM: PPC: Book3S HV: Remove kvmhv_p9_[set,restore]_lpcr declarations
KVM: PPC: Book3s HV: Remove unused function kvmppc_bad_interrupt
arch/powerpc/include/asm/kvm_book3s.h | 3 ---
arch/powerpc/kvm/book3s
The commit b1b1697ae0cc ("KVM: PPC: Book3S HV: Remove support for
running HPT guest on RPT host without mixed mode support") removed the
last references to these functions.
Fixes: b1b1697ae0cc ("KVM: PPC: Book3S HV: Remove support for running HPT guest
on RPT host without mixed mode support")
Sig
The commit fae5c9f3664b ("KVM: PPC: Book3S HV: remove ISA v3.0 and v3.1
support from P7/8 path") removed the last reference to the function.
Fixes: fae5c9f3664b ("KVM: PPC: Book3S HV: remove ISA v3.0 and v3.1 support
from P7/8 path")
Signed-off-by: Murilo Opsfelder Araujo
---
arch/powerpc/inclu
On Tue, Jul 12, 2022 at 1:35 AM Kefeng Wang wrote:
>
> Hi Barry，
>
> On 2022/7/11 11:46, Barry Song wrote:
> > From: Barry Song
> >
> > Platforms like ARM64 have hareware TLB shootdown broadcast. They
> > don't maintain mm_cpumask but just send tlbi and related sync
> > instructions for TLB flush
On Mon, May 09, 2022 at 06:14:41PM +, Mohamed Khalfella wrote:
> PCI AER stats counters sysfs attributes need to iterate over
> stats counters instead of stats names. Also, added a build
> time check to make sure all counters have entries in strings
> array.
>
> Fixes: 0678e3109a3c ("PCI/AER:
These are two small cleanups for -next. This v5 rebases on the latest
git master, as some whitespace was added that made v4 no longer apply.
Jason A. Donenfeld (2):
powerpc/powernv: rename remaining rng powernv_ functions to pnv_
powerpc/kvm: don't crash on missing rng, and use darn
arch/pow
The preferred nomenclature is pnv_, not powernv_, but rng.c used
powernv_ for some reason, which isn't consistent with the rest. A recent
commit added a few pnv_ functions to rng.c, making the file a bit of a
mishmash. This commit just replaces the rest of them.
Cc: Michael Ellerman
Tested-by: Sa
On POWER8 systems that don't have ibm,power-rng available, a guest that
ignores the KVM_CAP_PPC_HWRNG flag and calls H_RANDOM anyway will
dereference a NULL pointer. And on machines with darn instead of
ibm,power-rng, H_RANDOM won't work at all.
This patch kills two birds with one stone, by routin
Excerpts from Laurent Dufour's message of June 27, 2022 11:53 pm:
> When a partition is transferred, once it arrives at the destination node,
> the partition is active but much of its memory must be transferred from the
> start node.
>
> It depends on the activity in the partition, but the more CP
Excerpts from Laurent Dufour's message of June 27, 2022 11:53 pm:
> In pseries_migration_partition(), loop until the memory transfer is
> complete. This way the calling drmgr process will not exit earlier,
> allowing callbacks to be run only once the migration is fully completed.
>
> If reading th
Excerpts from Laurent Dufour's message of June 27, 2022 11:53 pm:
> Introduce a factor which would apply to the NMI watchdog timeout.
>
> This factor is a percentage added to the watchdog_tresh value. The value is
> set under the watchdog_mutex protection and lockup_detector_reconfigure()
> is cal
Excerpts from Laurent Dufour's message of June 27, 2022 11:53 pm:
> During a LPM, while the memory transfer is in progress on the arrival side,
> some latencies is generated when accessing not yet transferred pages on the
> arrival side. Thus, the NMI watchdog may be triggered too frequently, which
On 7/12/22 04:46, Jason Gunthorpe wrote:
On Mon, Jul 11, 2022 at 11:24:32PM +1000, Alexey Kardashevskiy wrote:
I really think that for 5.19 we should really move this blocked domain
business to Type1 like this:
https://github.com/aik/linux/commit/96f80c8db03b181398ad355f6f90e574c3ada4bf
T
On 7/12/22 01:44, Andrew Morton wrote:
> On Mon, 11 Jul 2022 12:35:34 +0530 Anshuman Khandual
> wrote:
>
>> This series drops __SXXX/__PXXX macros from across platforms in the tree.
>
> I've updated mm-unstable to this version, thanks. I skipped the added-to-mm
> emails to avoid wearing out
Hi Kajol,
Thanks for the patch. Minor review comment below:
Kajol Jain writes:
> Commit 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
> added performance monitoring support for papr-scm nvdimm devices via
> perf interface. Commit also added an array in papr_scm_priv
> structure
On Tue, Jul 12, 2022 at 12:27:17PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 7/12/22 04:46, Jason Gunthorpe wrote:
> > On Mon, Jul 11, 2022 at 11:24:32PM +1000, Alexey Kardashevskiy wrote:
> >
> > > I really think that for 5.19 we should really move this blocked domain
> > > business to Type1
74 matches
Mail list logo
