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
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 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
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
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,
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
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
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
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
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:
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
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:
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
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
---
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")
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 ---
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.
>
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 ++-
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
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
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
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
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 ++---
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
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
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, 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
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=edit
kernel dmesg (kernel 5.10.129, Talos II)
--
You may reply to this email to add a comment.
You
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=edit
kernel .config (kernel 5.10.129, Talos II)
Tried some LTS kernels and with 5.10.x I got a .config
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
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=edit
kernel .config (kernel 5.10.129, with PAGE_POISONING, Talos II)
--
You may reply to this email to
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
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
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:
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
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
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
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:
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 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)"
> +
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
>
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
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
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
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
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
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
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.
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:
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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:
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:
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
__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
74 matches
Mail list logo
