Re: [PATCH v3 0/9] RISC-V SBI debug console extension support

[patchwork-bot+linux-riscv]

Hello:

This series was applied to riscv/linux.git (fixes)
by Anup Patel :

On Fri, 20 Oct 2023 12:51:31 +0530 you wrote:
> The SBI v2.0 specification is now frozen. The SBI v2.0 specification defines
> SBI debug console (DBCN) extension which replaces the legacy SBI v0.1
> functions sbi_console_putchar() and sbi_console_getchar().
> (Refer v2.0-rc5 at https://github.com/riscv-non-isa/riscv-sbi-doc/releases)
> 
> This series adds support for SBI debug console (DBCN) extension in KVM RISC-V
> and Linux RISC-V.
> 
> [...]

Here is the summary with links:
  - [v3,1/9] RISC-V: Add defines for SBI debug console extension
https://git.kernel.org/riscv/c/dadf7886993c
  - [v3,2/9] RISC-V: KVM: Change the SBI specification version to v2.0
https://git.kernel.org/riscv/c/b88e87a0a1ec
  - [v3,3/9] RISC-V: KVM: Allow some SBI extensions to be disabled by default
https://git.kernel.org/riscv/c/56d8a385b605
  - [v3,4/9] RISC-V: KVM: Forward SBI DBCN extension to user-space
https://git.kernel.org/riscv/c/c667ad229d13
  - [v3,5/9] KVM: riscv: selftests: Add SBI DBCN extension to get-reg-list test
https://git.kernel.org/riscv/c/d9c00f44e5de
  - [v3,6/9] RISC-V: Add stubs for sbi_console_putchar/getchar()
(no matching commit)
  - [v3,7/9] tty/serial: Add RISC-V SBI debug console based earlycon
(no matching commit)
  - [v3,8/9] tty: Add SBI debug console support to HVC SBI driver
(no matching commit)
  - [v3,9/9] RISC-V: Enable SBI based earlycon support
(no matching commit)

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH v3 0/9] RISC-V SBI debug console extension support

[Anup Patel]

On Fri, Oct 20, 2023 at 12:51 PM Anup Patel  wrote:
>
> The SBI v2.0 specification is now frozen. The SBI v2.0 specification defines
> SBI debug console (DBCN) extension which replaces the legacy SBI v0.1
> functions sbi_console_putchar() and sbi_console_getchar().
> (Refer v2.0-rc5 at https://github.com/riscv-non-isa/riscv-sbi-doc/releases)
>
> This series adds support for SBI debug console (DBCN) extension in KVM RISC-V
> and Linux RISC-V.
>
> To try these patches with KVM RISC-V, use KVMTOOL from riscv_sbi_dbcn_v1
> branch at: https://github.com/avpatel/kvmtool.git
>
> These patches can also be found in the riscv_sbi_dbcn_v3 branch at:
> https://github.com/avpatel/linux.git
>
> Changes since v2:
>  - Rebased on Linux-6.6-rc5
>  - Handled page-crossing in PATCH7 of v2 series
>  - Addressed Drew's comment in PATCH3 of v2 series
>  - Added new PATCH5 to make get-reg-list test aware of SBI DBCN extension
>
> Changes since v1:
>  - Remove use of #ifdef from PATCH4 and PATCH5 of the v1 series
>  - Improved commit description of PATCH3 in v1 series
>  - Introduced new PATCH3 in this series to allow some SBI extensions
>(such as SBI DBCN) do to disabled by default so that older KVM user space
>work fine and newer KVM user space have to explicitly opt-in for emulating
>SBI DBCN.
>  - Introduced new PATCH5 in this series which adds inline version of
>sbi_console_getchar() and sbi_console_putchar() for the case where
>CONFIG_RISCV_SBI_V01 is disabled.
>
> Anup Patel (8):
>   RISC-V: Add defines for SBI debug console extension
>   RISC-V: KVM: Change the SBI specification version to v2.0
>   RISC-V: KVM: Allow some SBI extensions to be disabled by default
>   RISC-V: KVM: Forward SBI DBCN extension to user-space
>   KVM: riscv: selftests: Add SBI DBCN extension to get-reg-list test
>   RISC-V: Add stubs for sbi_console_putchar/getchar()
>   tty/serial: Add RISC-V SBI debug console based earlycon
>   RISC-V: Enable SBI based earlycon support
>
> Atish Patra (1):
>   tty: Add SBI debug console support to HVC SBI driver

Queued PATCH1 to PATCH5 for Linux-6.7

Remaining PATCH6 to PATCH9 are still under review.

Thanks,
Anup

>
>  arch/riscv/configs/defconfig  |  1 +
>  arch/riscv/configs/rv32_defconfig |  1 +
>  arch/riscv/include/asm/kvm_vcpu_sbi.h |  7 +-
>  arch/riscv/include/asm/sbi.h  | 12 +++
>  arch/riscv/include/uapi/asm/kvm.h |  1 +
>  arch/riscv/kvm/vcpu.c |  6 ++
>  arch/riscv/kvm/vcpu_sbi.c | 61 +++---
>  arch/riscv/kvm/vcpu_sbi_replace.c | 32 
>  drivers/tty/hvc/Kconfig   |  2 +-
>  drivers/tty/hvc/hvc_riscv_sbi.c   | 82 +--
>  drivers/tty/serial/Kconfig|  2 +-
>  drivers/tty/serial/earlycon-riscv-sbi.c   | 32 +++-
>  .../selftests/kvm/riscv/get-reg-list.c|  2 +
>  13 files changed, 198 insertions(+), 43 deletions(-)
>
> --
> 2.34.1
>
>
> --
> kvm-riscv mailing list
> kvm-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kvm-riscv

[PATCH v3 0/9] RISC-V SBI debug console extension support

[Anup Patel]

The SBI v2.0 specification is now frozen. The SBI v2.0 specification defines
SBI debug console (DBCN) extension which replaces the legacy SBI v0.1
functions sbi_console_putchar() and sbi_console_getchar().
(Refer v2.0-rc5 at https://github.com/riscv-non-isa/riscv-sbi-doc/releases)

This series adds support for SBI debug console (DBCN) extension in KVM RISC-V
and Linux RISC-V.

To try these patches with KVM RISC-V, use KVMTOOL from riscv_sbi_dbcn_v1
branch at: https://github.com/avpatel/kvmtool.git

These patches can also be found in the riscv_sbi_dbcn_v3 branch at:
https://github.com/avpatel/linux.git

Changes since v2:
 - Rebased on Linux-6.6-rc5
 - Handled page-crossing in PATCH7 of v2 series
 - Addressed Drew's comment in PATCH3 of v2 series
 - Added new PATCH5 to make get-reg-list test aware of SBI DBCN extension

Changes since v1:
 - Remove use of #ifdef from PATCH4 and PATCH5 of the v1 series
 - Improved commit description of PATCH3 in v1 series
 - Introduced new PATCH3 in this series to allow some SBI extensions
   (such as SBI DBCN) do to disabled by default so that older KVM user space
   work fine and newer KVM user space have to explicitly opt-in for emulating
   SBI DBCN.
 - Introduced new PATCH5 in this series which adds inline version of
   sbi_console_getchar() and sbi_console_putchar() for the case where
   CONFIG_RISCV_SBI_V01 is disabled.

Anup Patel (8):
  RISC-V: Add defines for SBI debug console extension
  RISC-V: KVM: Change the SBI specification version to v2.0
  RISC-V: KVM: Allow some SBI extensions to be disabled by default
  RISC-V: KVM: Forward SBI DBCN extension to user-space
  KVM: riscv: selftests: Add SBI DBCN extension to get-reg-list test
  RISC-V: Add stubs for sbi_console_putchar/getchar()
  tty/serial: Add RISC-V SBI debug console based earlycon
  RISC-V: Enable SBI based earlycon support

Atish Patra (1):
  tty: Add SBI debug console support to HVC SBI driver

 arch/riscv/configs/defconfig  |  1 +
 arch/riscv/configs/rv32_defconfig |  1 +
 arch/riscv/include/asm/kvm_vcpu_sbi.h |  7 +-
 arch/riscv/include/asm/sbi.h  | 12 +++
 arch/riscv/include/uapi/asm/kvm.h |  1 +
 arch/riscv/kvm/vcpu.c |  6 ++
 arch/riscv/kvm/vcpu_sbi.c | 61 +++---
 arch/riscv/kvm/vcpu_sbi_replace.c | 32 
 drivers/tty/hvc/Kconfig   |  2 +-
 drivers/tty/hvc/hvc_riscv_sbi.c   | 82 +--
 drivers/tty/serial/Kconfig|  2 +-
 drivers/tty/serial/earlycon-riscv-sbi.c   | 32 +++-
 .../selftests/kvm/riscv/get-reg-list.c|  2 +
 13 files changed, 198 insertions(+), 43 deletions(-)

-- 
2.34.1

Re: [PATCH v3 0/9] video: screen_info cleanups

[Greg Kroah-Hartman]

On Tue, Oct 10, 2023 at 01:48:07PM +0200, Daniel Vetter wrote:
> On Mon, Oct 09, 2023 at 11:18:36PM +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann 
> > 
> > v3 changelog
> > 
> > No real changes, just rebased for context changes, and picked up the Acks.
> > 
> > This now conflicts with the ia64 removal and introduces one new dependency
> > on IA64, but that is harmless and trivial to deal with later.
> > 
> > Link: https://lore.kernel.org/lkml/20230719123944.3438363-1-a...@kernel.org/
> > ---
> > v2 changelog
> > 
> > I refreshed the first four patches that I sent before with very minor
> > updates, and then added some more to further disaggregate the use
> > of screen_info:
> > 
> >  - I found that powerpc wasn't using vga16fb any more
> > 
> >  - vgacon can be almost entirely separated from the global
> >screen_info, except on x86
> > 
> >  - similarly, the EFI framebuffer initialization can be
> >kept separate, except on x86.
> > 
> > I did extensive build testing on arm/arm64/x86 and the normal built bot
> > testing for the other architectures.
> > 
> > Which tree should this get merged through?
> 
> I guess if no one else volunteers (Greg maybe?) I can stuff this into
> drm-misc ...

Oh, hey, console code is for me, I keep forgetting.

I can take it, looks like we have enough acks now, thanks for reminding
me!

greg k-h

Re: [PATCH v3 0/9] video: screen_info cleanups

[Daniel Vetter]

On Mon, Oct 09, 2023 at 11:18:36PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> v3 changelog
> 
> No real changes, just rebased for context changes, and picked up the Acks.
> 
> This now conflicts with the ia64 removal and introduces one new dependency
> on IA64, but that is harmless and trivial to deal with later.
> 
> Link: https://lore.kernel.org/lkml/20230719123944.3438363-1-a...@kernel.org/
> ---
> v2 changelog
> 
> I refreshed the first four patches that I sent before with very minor
> updates, and then added some more to further disaggregate the use
> of screen_info:
> 
>  - I found that powerpc wasn't using vga16fb any more
> 
>  - vgacon can be almost entirely separated from the global
>screen_info, except on x86
> 
>  - similarly, the EFI framebuffer initialization can be
>kept separate, except on x86.
> 
> I did extensive build testing on arm/arm64/x86 and the normal built bot
> testing for the other architectures.
> 
> Which tree should this get merged through?

I guess if no one else volunteers (Greg maybe?) I can stuff this into
drm-misc ...
-Sima

> 
> Link: https://lore.kernel.org/lkml/20230707095415.1449376-1-a...@kernel.org/
> 
> 
> Arnd Bergmann (9):
>   vgacon: rework Kconfig dependencies
>   vgacon: rework screen_info #ifdef checks
>   dummycon: limit Arm console size hack to footbridge
>   vgacon, arch/*: remove unused screen_info definitions
>   vgacon: remove screen_info dependency
>   vgacon: clean up global screen_info instances
>   vga16fb: drop powerpc support
>   hyperv: avoid dependency on screen_info
>   efi: move screen_info into efi init code
> 
>  arch/alpha/kernel/proto.h |  2 +
>  arch/alpha/kernel/setup.c |  8 +--
>  arch/alpha/kernel/sys_sio.c   |  8 ++-
>  arch/arm/include/asm/setup.h  |  5 ++
>  arch/arm/kernel/atags_parse.c | 20 +++---
>  arch/arm/kernel/efi.c |  6 --
>  arch/arm/kernel/setup.c   | 11 +--
>  arch/arm64/kernel/efi.c   |  4 --
>  arch/arm64/kernel/image-vars.h|  2 +
>  arch/csky/kernel/setup.c  | 12 
>  arch/hexagon/kernel/Makefile  |  2 -
>  arch/hexagon/kernel/screen_info.c |  3 -
>  arch/ia64/kernel/setup.c  | 53 ---
>  arch/loongarch/kernel/efi.c   |  3 +-
>  arch/loongarch/kernel/image-vars.h|  2 +
>  arch/loongarch/kernel/setup.c |  3 -
>  arch/mips/jazz/setup.c|  9 ---
>  arch/mips/kernel/setup.c  | 11 ---
>  arch/mips/mti-malta/malta-setup.c |  4 +-
>  arch/mips/sibyte/swarm/setup.c| 26 ---
>  arch/mips/sni/setup.c | 18 ++---
>  arch/nios2/kernel/setup.c |  5 --
>  arch/powerpc/kernel/setup-common.c| 16 -
>  arch/riscv/kernel/image-vars.h|  2 +
>  arch/riscv/kernel/setup.c | 12 
>  arch/sh/kernel/setup.c|  5 --
>  arch/sparc/kernel/setup_32.c  | 13 
>  arch/sparc/kernel/setup_64.c  | 13 
>  arch/x86/kernel/setup.c   |  2 +-
>  arch/xtensa/kernel/setup.c| 12 
>  drivers/firmware/efi/efi-init.c   | 14 +++-
>  drivers/firmware/efi/libstub/efi-stub-entry.c |  8 ++-
>  drivers/firmware/pcdp.c   |  1 -
>  drivers/gpu/drm/hyperv/hyperv_drm_drv.c   |  7 +-
>  drivers/hv/vmbus_drv.c|  6 +-
>  drivers/video/console/Kconfig | 11 +--
>  drivers/video/console/dummycon.c  |  2 +-
>  drivers/video/console/vgacon.c| 68 +++
>  drivers/video/fbdev/Kconfig   |  2 +-
>  drivers/video/fbdev/hyperv_fb.c   |  8 +--
>  drivers/video/fbdev/vga16fb.c |  9 +--
>  include/linux/console.h   |  7 ++
>  42 files changed, 183 insertions(+), 252 deletions(-)
>  delete mode 100644 arch/hexagon/kernel/screen_info.c
> 
> -- 
> 2.39.2
> 
> Cc: "David S. Miller" 
> Cc: "K. Y. Srinivasan" 
> Cc: Ard Biesheuvel 
> Cc: Borislav Petkov 
> Cc: Brian Cain 
> Cc: Catalin Marinas 
> Cc: Christophe Leroy 
> Cc: Daniel Vetter 
> Cc: Dave Hansen 
> Cc: David Airlie 
> Cc: Deepak Rawat 
> Cc: Dexuan Cui 
> Cc: Dinh Nguyen 
> Cc: Greg Kroah-Hartman 
> Cc: Guo Ren 
> Cc: Haiyang Zhang 
> Cc: Helge Deller 
> Cc: Huacai Chen 
> Cc: Ingo Molnar 
> Cc: Javier Martinez Canillas 
> Cc: John Paul Adrian Glaubitz 
> Cc: Khalid Aziz 
> Cc: Linus Walleij 
> Cc: Matt Turner 
> Cc: Max Filippov 
> Cc: Michael Ellerman 
> Cc: Nicholas Piggin 
> Cc: Palmer Dabbelt 
> Cc: Russell King 
> Cc: Thomas Bogendoerfer 
> Cc: Thomas Gleixner 
> Cc: Thomas Zimmermann 
> Cc: WANG Xuerui 
> Cc: Wei Liu 
> Cc: Will Deacon 
> Cc: x...@kernel.org
> Cc: 

[PATCH v3 0/9] video: screen_info cleanups

[Arnd Bergmann]

From: Arnd Bergmann 

v3 changelog

No real changes, just rebased for context changes, and picked up the Acks.

This now conflicts with the ia64 removal and introduces one new dependency
on IA64, but that is harmless and trivial to deal with later.

Link: https://lore.kernel.org/lkml/20230719123944.3438363-1-a...@kernel.org/
---
v2 changelog

I refreshed the first four patches that I sent before with very minor
updates, and then added some more to further disaggregate the use
of screen_info:

 - I found that powerpc wasn't using vga16fb any more

 - vgacon can be almost entirely separated from the global
   screen_info, except on x86

 - similarly, the EFI framebuffer initialization can be
   kept separate, except on x86.

I did extensive build testing on arm/arm64/x86 and the normal built bot
testing for the other architectures.

Which tree should this get merged through?

Link: https://lore.kernel.org/lkml/20230707095415.1449376-1-a...@kernel.org/


Arnd Bergmann (9):
  vgacon: rework Kconfig dependencies
  vgacon: rework screen_info #ifdef checks
  dummycon: limit Arm console size hack to footbridge
  vgacon, arch/*: remove unused screen_info definitions
  vgacon: remove screen_info dependency
  vgacon: clean up global screen_info instances
  vga16fb: drop powerpc support
  hyperv: avoid dependency on screen_info
  efi: move screen_info into efi init code

 arch/alpha/kernel/proto.h |  2 +
 arch/alpha/kernel/setup.c |  8 +--
 arch/alpha/kernel/sys_sio.c   |  8 ++-
 arch/arm/include/asm/setup.h  |  5 ++
 arch/arm/kernel/atags_parse.c | 20 +++---
 arch/arm/kernel/efi.c |  6 --
 arch/arm/kernel/setup.c   | 11 +--
 arch/arm64/kernel/efi.c   |  4 --
 arch/arm64/kernel/image-vars.h|  2 +
 arch/csky/kernel/setup.c  | 12 
 arch/hexagon/kernel/Makefile  |  2 -
 arch/hexagon/kernel/screen_info.c |  3 -
 arch/ia64/kernel/setup.c  | 53 ---
 arch/loongarch/kernel/efi.c   |  3 +-
 arch/loongarch/kernel/image-vars.h|  2 +
 arch/loongarch/kernel/setup.c |  3 -
 arch/mips/jazz/setup.c|  9 ---
 arch/mips/kernel/setup.c  | 11 ---
 arch/mips/mti-malta/malta-setup.c |  4 +-
 arch/mips/sibyte/swarm/setup.c| 26 ---
 arch/mips/sni/setup.c | 18 ++---
 arch/nios2/kernel/setup.c |  5 --
 arch/powerpc/kernel/setup-common.c| 16 -
 arch/riscv/kernel/image-vars.h|  2 +
 arch/riscv/kernel/setup.c | 12 
 arch/sh/kernel/setup.c|  5 --
 arch/sparc/kernel/setup_32.c  | 13 
 arch/sparc/kernel/setup_64.c  | 13 
 arch/x86/kernel/setup.c   |  2 +-
 arch/xtensa/kernel/setup.c| 12 
 drivers/firmware/efi/efi-init.c   | 14 +++-
 drivers/firmware/efi/libstub/efi-stub-entry.c |  8 ++-
 drivers/firmware/pcdp.c   |  1 -
 drivers/gpu/drm/hyperv/hyperv_drm_drv.c   |  7 +-
 drivers/hv/vmbus_drv.c|  6 +-
 drivers/video/console/Kconfig | 11 +--
 drivers/video/console/dummycon.c  |  2 +-
 drivers/video/console/vgacon.c| 68 +++
 drivers/video/fbdev/Kconfig   |  2 +-
 drivers/video/fbdev/hyperv_fb.c   |  8 +--
 drivers/video/fbdev/vga16fb.c |  9 +--
 include/linux/console.h   |  7 ++
 42 files changed, 183 insertions(+), 252 deletions(-)
 delete mode 100644 arch/hexagon/kernel/screen_info.c

-- 
2.39.2

Cc: "David S. Miller" 
Cc: "K. Y. Srinivasan" 
Cc: Ard Biesheuvel 
Cc: Borislav Petkov 
Cc: Brian Cain 
Cc: Catalin Marinas 
Cc: Christophe Leroy 
Cc: Daniel Vetter 
Cc: Dave Hansen 
Cc: David Airlie 
Cc: Deepak Rawat 
Cc: Dexuan Cui 
Cc: Dinh Nguyen 
Cc: Greg Kroah-Hartman 
Cc: Guo Ren 
Cc: Haiyang Zhang 
Cc: Helge Deller 
Cc: Huacai Chen 
Cc: Ingo Molnar 
Cc: Javier Martinez Canillas 
Cc: John Paul Adrian Glaubitz 
Cc: Khalid Aziz 
Cc: Linus Walleij 
Cc: Matt Turner 
Cc: Max Filippov 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Palmer Dabbelt 
Cc: Russell King 
Cc: Thomas Bogendoerfer 
Cc: Thomas Gleixner 
Cc: Thomas Zimmermann 
Cc: WANG Xuerui 
Cc: Wei Liu 
Cc: Will Deacon 
Cc: x...@kernel.org
Cc: linux-al...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-c...@vger.kernel.org
Cc: linux-hexa...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
Cc: loonga...@lists.linux.dev
Cc: linux-m...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ri...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: 

[RFC PATCH v3 0/9] Add audio support in v4l2 framework

[Shengjiu Wang]

Audio signal processing also has the requirement for memory to
memory similar as Video.

This asrc memory to memory (memory ->asrc->memory) case is a non
real time use case.

User fills the input buffer to the asrc module, after conversion, then asrc
sends back the output buffer to user. So it is not a traditional ALSA playback
and capture case.

It is a specific use case,  there is no reference in current kernel.
v4l2 memory to memory is the closed implementation,  v4l2 current
support video, image, radio, tuner, touch devices, so it is not
complicated to add support for this specific audio case.

Because we had implemented the "memory -> asrc ->i2s device-> codec"
use case in ALSA.  Now the "memory->asrc->memory" needs
to reuse the code in asrc driver, so the first 3 patches is for refining
the code to make it can be shared by the "memory->asrc->memory"
driver.

The main change is in the v4l2 side, A /dev/vl4-audioX will be created,
user applications only use the ioctl of v4l2 framework.

Other change is to add memory to memory support for two kinds of i.MX ASRC
module.

changes in v3:
- Modify documents for adding audio m2m support
- Add audio virtual m2m driver
- Defined V4L2_AUDIO_FMT_LPCM format type for audio.
- Defined V4L2_CAP_AUDIO_M2M capability type for audio m2m case.
- with modification in v4l-utils, pass v4l2-compliance test.

changes in v2:
- decouple the implementation in v4l2 and ALSA
- implement the memory to memory driver as a platfrom driver
  and move it to driver/media
- move fsl_asrc_common.h to include/sound folder

Shengjiu Wang (9):
  ASoC: fsl_asrc: define functions for memory to memory usage
  ASoC: fsl_easrc: define functions for memory to memory usage
  ASoC: fsl_asrc: move fsl_asrc_common.h to include/sound
  ASoC: fsl_asrc: register m2m platform device
  ASoC: fsl_easrc: register m2m platform device
  media: v4l2: Add audio capture and output support
  media: uapi: Add V4L2_CID_USER_IMX_ASRC_RATIO_MOD control
  media: audm2m: add virtual driver for audio memory to memory
  media: imx-asrc: Add memory to memory driver

 .../userspace-api/media/v4l/audio-formats.rst |   15 +
 .../userspace-api/media/v4l/buffer.rst|6 +
 .../userspace-api/media/v4l/control.rst   |5 +
 .../userspace-api/media/v4l/dev-audio.rst |   63 +
 .../userspace-api/media/v4l/devices.rst   |1 +
 .../media/v4l/pixfmt-aud-lpcm.rst |   31 +
 .../userspace-api/media/v4l/pixfmt.rst|1 +
 .../media/v4l/vidioc-enum-fmt.rst |2 +
 .../userspace-api/media/v4l/vidioc-g-fmt.rst  |4 +
 .../media/v4l/vidioc-querycap.rst |3 +
 .../media/videodev2.h.rst.exceptions  |2 +
 .../media/common/videobuf2/videobuf2-v4l2.c   |4 +
 drivers/media/platform/nxp/Kconfig|   12 +
 drivers/media/platform/nxp/Makefile   |1 +
 drivers/media/platform/nxp/imx-asrc.c | 1058 +
 drivers/media/test-drivers/Kconfig|9 +
 drivers/media/test-drivers/Makefile   |1 +
 drivers/media/test-drivers/audm2m.c   |  767 
 drivers/media/v4l2-core/v4l2-ctrls-defs.c |1 +
 drivers/media/v4l2-core/v4l2-dev.c|   17 +
 drivers/media/v4l2-core/v4l2-ioctl.c  |   53 +
 include/media/v4l2-dev.h  |2 +
 include/media/v4l2-ioctl.h|   34 +
 .../fsl => include/sound}/fsl_asrc_common.h   |   54 +
 include/uapi/linux/v4l2-controls.h|1 +
 include/uapi/linux/videodev2.h|   25 +
 sound/soc/fsl/fsl_asrc.c  |  162 +++
 sound/soc/fsl/fsl_asrc.h  |4 +-
 sound/soc/fsl/fsl_asrc_dma.c  |2 +-
 sound/soc/fsl/fsl_easrc.c |  239 
 sound/soc/fsl/fsl_easrc.h |8 +-
 31 files changed, 2584 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/userspace-api/media/v4l/audio-formats.rst
 create mode 100644 Documentation/userspace-api/media/v4l/dev-audio.rst
 create mode 100644 Documentation/userspace-api/media/v4l/pixfmt-aud-lpcm.rst
 create mode 100644 drivers/media/platform/nxp/imx-asrc.c
 create mode 100644 drivers/media/test-drivers/audm2m.c
 rename {sound/soc/fsl => include/sound}/fsl_asrc_common.h (60%)

-- 
2.34.1

Re: [PATCH v3 0/9] Cleanup/Optimise KUAP (v3)

[Michael Ellerman]

On Tue, 11 Jul 2023 17:59:12 +0200, Christophe Leroy wrote:
> This series is cleaning up a bit KUAP in preparation of using objtool
> to validate UACCESS.
> 
> There are two main changes in this series:
> 
> 1/ Simplification of KUAP on book3s/32
> 
> [...]

Applied to powerpc/next.

[1/9] powerpc/kuap: Avoid unnecessary reads of MD_AP
  https://git.kernel.org/powerpc/c/880df2d46a3f23f30f954f6e64c576d7f411cc46
[2/9] powerpc/kuap: Avoid useless jump_label on empty function
  https://git.kernel.org/powerpc/c/1bec4adcd59e923df6b7f5d492a9e4b8dfd22039
[3/9] powerpc/kuap: Fold kuep_is_disabled() into its only user
  https://git.kernel.org/powerpc/c/38bb171b958480b484e8e980be76c7d3656881ea
[4/9] powerpc/features: Add capability to update mmu features later
  https://git.kernel.org/powerpc/c/6b289911c80d45fd8da3d24ea14706361381b78d
[5/9] powerpc/kuap: MMU_FTR_BOOK3S_KUAP becomes MMU_FTR_KUAP
  https://git.kernel.org/powerpc/c/4589a2b7894d4266380b65e13291f609cf19dd19
[6/9] powerpc/kuap: Use MMU_FTR_KUAP on all and refactor disabling kuap
  https://git.kernel.org/powerpc/c/26e041208291bfdea1cb9e26bc94a0f9499efe15
[7/9] powerpc/kuap: Simplify KUAP lock/unlock on BOOK3S/32
  https://git.kernel.org/powerpc/c/5222a1d5142ec4f9ec063b274b80e20639584dbc
[8/9] powerpc/kuap: KUAP enabling/disabling functions must be __always_inline
  https://git.kernel.org/powerpc/c/eb52f66f0abd468caf8be4e690d7fdef96250c2f
[9/9] powerpc/kuap: Use ASM feature fixups instead of static branches
  https://git.kernel.org/powerpc/c/3a24ea0df83e32355d897a18bbd82e05986dcdc3

cheers

[PATCH v3 0/9] Cleanup/Optimise KUAP (v3)

[Christophe Leroy]

This series is cleaning up a bit KUAP in preparation of using objtool
to validate UACCESS.

There are two main changes in this series:

1/ Simplification of KUAP on book3s/32

2/ Using ASM features on 32 bits and booke as suggested by Nic.

Those changes will be required for objtool UACCESS validation, but
even before they are worth it, especially the simplification on 32s.

Changes in v3:
- Rearranged book3s/32 simplification in order to ease objtool UACCESS
check implementation (patches 7 and 9)

Christophe Leroy (9):
  powerpc/kuap: Avoid unnecessary reads of MD_AP
  powerpc/kuap: Avoid useless jump_label on empty function
  powerpc/kuap: Fold kuep_is_disabled() into its only user
  powerpc/features: Add capability to update mmu features later
  powerpc/kuap: MMU_FTR_BOOK3S_KUAP becomes MMU_FTR_KUAP
  powerpc/kuap: Use MMU_FTR_KUAP on all and refactor disabling kuap
  powerpc/kuap: Simplify KUAP lock/unlock on BOOK3S/32
  powerpc/kuap: KUAP enabling/disabling functions must be
__always_inline
  powerpc/kuap: Use ASM feature fixups instead of static branches

 arch/powerpc/include/asm/book3s/32/kup.h  | 123 --
 .../powerpc/include/asm/book3s/64/hash-pkey.h |   2 +-
 arch/powerpc/include/asm/book3s/64/kup.h  |  54 
 arch/powerpc/include/asm/bug.h|   1 +
 arch/powerpc/include/asm/feature-fixups.h |   1 +
 arch/powerpc/include/asm/kup.h|  91 +
 arch/powerpc/include/asm/mmu.h|   4 +-
 arch/powerpc/include/asm/nohash/32/kup-8xx.h  |  62 +
 arch/powerpc/include/asm/nohash/kup-booke.h   |  68 +-
 arch/powerpc/include/asm/uaccess.h|   6 +-
 arch/powerpc/kernel/cputable.c|   4 +
 arch/powerpc/kernel/syscall.c |   2 +-
 arch/powerpc/kernel/traps.c   |   2 +-
 arch/powerpc/lib/feature-fixups.c |  31 -
 arch/powerpc/mm/book3s32/kuap.c   |  20 +--
 arch/powerpc/mm/book3s32/mmu_context.c|   2 +-
 arch/powerpc/mm/book3s64/pkeys.c  |   2 +-
 arch/powerpc/mm/init_32.c |   2 +
 arch/powerpc/mm/nohash/kup.c  |   8 +-
 19 files changed, 222 insertions(+), 263 deletions(-)

-- 
2.41.0

Re: [PATCH v3 0/9] Introduce SMT level and add PowerPC support

[Laurent Dufour]

Le 05/07/2023 à 05:04, Zhang, Rui a écrit :

Hi, Laurent,

I want to test this patch set and found that it does not apply on top
of latest usptream git, because of some changes in this merge window,
so better rebase.


Hi Rui,

Thanks for your interest for this series.
The latest Thomas's changes came into the PowerPC next branch.
I'm working on a rebase.

Cheers,
Laurent.


thanks,
rui

On Thu, 2023-06-29 at 16:31 +0200, Laurent Dufour wrote:

I'm taking over the series Michael sent previously [1] which is
smartly
reviewing the initial series I sent [2].  This series is addressing
the
comments sent by Thomas and me on the Michael's one.

Here is a short introduction to the issue this series is addressing:

When a new CPU is added, the kernel is activating all its threads.
This
leads to weird, but functional, result when adding CPU on a SMT 4
system
for instance.

Here the newly added CPU 1 has 8 threads while the other one has 4
threads
active (system has been booted with the 'smt-enabled=4' kernel
option):

ltcden3-lp12:~ # ppc64_cpu --info
Core   0:    0*    1*    2*    3*    4 5 6 7
Core   1:    8*    9*   10*   11*   12*   13*   14*   15*

This mixed SMT level may confused end users and/or some applications.

There is no SMT level recorded in the kernel (common code), neither
in user
space, as far as I know. Such a level is helpful when adding new CPU
or
when optimizing the energy efficiency (when reactivating CPUs).

When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT
level
(cpu_smt_num_threads) and few callbacks allowing the architecture
code to
fine control this value, setting a max and a "at boot" level, and
controling whether a thread should be onlined or not.

v3:
   Fix a build error in the patch 6/9
v2:
   As Thomas suggested,
     Reword some commit's description
     Remove topology_smt_supported()
     Remove topology_smt_threads_supported()
     Introduce CONFIG_SMT_NUM_THREADS_DYNAMIC
     Remove switch() in __store_smt_control()
   Update kernel-parameters.txt

[1]
https://lore.kernel.org/linuxppc-dev/20230524155630.794584-1-...@ellerman.id.au/
[2]
https://lore.kernel.org/linuxppc-dev/20230331153905.31698-1-lduf...@linux.ibm.com/

Laurent Dufour (1):
   cpu/SMT: Remove topology_smt_supported()

Michael Ellerman (8):
   cpu/SMT: Move SMT prototypes into cpu_smt.h
   cpu/SMT: Move smt/control simple exit cases earlier
   cpu/SMT: Store the current/max number of threads
   cpu/SMT: Create topology_smt_thread_allowed()
   cpu/SMT: Allow enabling partial SMT states via sysfs
   powerpc/pseries: Initialise CPU hotplug callbacks earlier
   powerpc: Add HOTPLUG_SMT support
   powerpc/pseries: Honour current SMT state when DLPAR onlining CPUs

  .../ABI/testing/sysfs-devices-system-cpu  |   1 +
  .../admin-guide/kernel-parameters.txt |   4 +-
  arch/Kconfig  |   3 +
  arch/powerpc/Kconfig  |   2 +
  arch/powerpc/include/asm/topology.h   |  15 +++
  arch/powerpc/kernel/smp.c |   8 +-
  arch/powerpc/platforms/pseries/hotplug-cpu.c  |  30 +++--
  arch/powerpc/platforms/pseries/pseries.h  |   2 +
  arch/powerpc/platforms/pseries/setup.c    |   2 +
  arch/x86/include/asm/topology.h   |   4 +-
  arch/x86/kernel/cpu/bugs.c    |   3 +-
  arch/x86/kernel/smpboot.c |   8 --
  include/linux/cpu.h   |  25 +---
  include/linux/cpu_smt.h   |  33 +
  kernel/cpu.c  | 118 ++--
--
  15 files changed, 187 insertions(+), 71 deletions(-)
  create mode 100644 include/linux/cpu_smt.h

Re: [PATCH v3 0/9] Introduce SMT level and add PowerPC support

[Zhang, Rui]

Hi, Laurent,

I want to test this patch set and found that it does not apply on top
of latest usptream git, because of some changes in this merge window,
so better rebase.

thanks,
rui

On Thu, 2023-06-29 at 16:31 +0200, Laurent Dufour wrote:
> I'm taking over the series Michael sent previously [1] which is
> smartly
> reviewing the initial series I sent [2].  This series is addressing
> the
> comments sent by Thomas and me on the Michael's one.
> 
> Here is a short introduction to the issue this series is addressing:
> 
> When a new CPU is added, the kernel is activating all its threads.
> This
> leads to weird, but functional, result when adding CPU on a SMT 4
> system
> for instance.
> 
> Here the newly added CPU 1 has 8 threads while the other one has 4
> threads
> active (system has been booted with the 'smt-enabled=4' kernel
> option):
> 
> ltcden3-lp12:~ # ppc64_cpu --info
> Core   0:    0*    1*    2*    3*    4 5 6 7
> Core   1:    8*    9*   10*   11*   12*   13*   14*   15*
> 
> This mixed SMT level may confused end users and/or some applications.
> 
> There is no SMT level recorded in the kernel (common code), neither
> in user
> space, as far as I know. Such a level is helpful when adding new CPU
> or
> when optimizing the energy efficiency (when reactivating CPUs).
> 
> When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT
> level
> (cpu_smt_num_threads) and few callbacks allowing the architecture
> code to
> fine control this value, setting a max and a "at boot" level, and
> controling whether a thread should be onlined or not.
> 
> v3:
>   Fix a build error in the patch 6/9
> v2:
>   As Thomas suggested,
>     Reword some commit's description
>     Remove topology_smt_supported()
>     Remove topology_smt_threads_supported()
>     Introduce CONFIG_SMT_NUM_THREADS_DYNAMIC
>     Remove switch() in __store_smt_control()
>   Update kernel-parameters.txt
> 
> [1]
> https://lore.kernel.org/linuxppc-dev/20230524155630.794584-1-...@ellerman.id.au/
> [2]
> https://lore.kernel.org/linuxppc-dev/20230331153905.31698-1-lduf...@linux.ibm.com/
> 
> Laurent Dufour (1):
>   cpu/SMT: Remove topology_smt_supported()
> 
> Michael Ellerman (8):
>   cpu/SMT: Move SMT prototypes into cpu_smt.h
>   cpu/SMT: Move smt/control simple exit cases earlier
>   cpu/SMT: Store the current/max number of threads
>   cpu/SMT: Create topology_smt_thread_allowed()
>   cpu/SMT: Allow enabling partial SMT states via sysfs
>   powerpc/pseries: Initialise CPU hotplug callbacks earlier
>   powerpc: Add HOTPLUG_SMT support
>   powerpc/pseries: Honour current SMT state when DLPAR onlining CPUs
> 
>  .../ABI/testing/sysfs-devices-system-cpu  |   1 +
>  .../admin-guide/kernel-parameters.txt |   4 +-
>  arch/Kconfig  |   3 +
>  arch/powerpc/Kconfig  |   2 +
>  arch/powerpc/include/asm/topology.h   |  15 +++
>  arch/powerpc/kernel/smp.c |   8 +-
>  arch/powerpc/platforms/pseries/hotplug-cpu.c  |  30 +++--
>  arch/powerpc/platforms/pseries/pseries.h  |   2 +
>  arch/powerpc/platforms/pseries/setup.c    |   2 +
>  arch/x86/include/asm/topology.h   |   4 +-
>  arch/x86/kernel/cpu/bugs.c    |   3 +-
>  arch/x86/kernel/smpboot.c |   8 --
>  include/linux/cpu.h   |  25 +---
>  include/linux/cpu_smt.h   |  33 +
>  kernel/cpu.c  | 118 ++--
> --
>  15 files changed, 187 insertions(+), 71 deletions(-)
>  create mode 100644 include/linux/cpu_smt.h
> 

Re: [PATCH v3 0/9] Introduce SMT level and add PowerPC support

[Laurent Dufour]

Le 30/06/2023 à 15:32, Sachin Sant a écrit :




On 29-Jun-2023, at 8:01 PM, Laurent Dufour  wrote:

I'm taking over the series Michael sent previously [1] which is smartly
reviewing the initial series I sent [2].  This series is addressing the
comments sent by Thomas and me on the Michael's one.

Here is a short introduction to the issue this series is addressing:

When a new CPU is added, the kernel is activating all its threads. This
leads to weird, but functional, result when adding CPU on a SMT 4 system
for instance.

Here the newly added CPU 1 has 8 threads while the other one has 4 threads
active (system has been booted with the 'smt-enabled=4' kernel option):

ltcden3-lp12:~ # ppc64_cpu --info
Core   0:0*1*2*3*4 5 6 7
Core   1:8*9*   10*   11*   12*   13*   14*   15*

This mixed SMT level may confused end users and/or some applications.

There is no SMT level recorded in the kernel (common code), neither in user
space, as far as I know. Such a level is helpful when adding new CPU or
when optimizing the energy efficiency (when reactivating CPUs).

When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT level
(cpu_smt_num_threads) and few callbacks allowing the architecture code to
fine control this value, setting a max and a "at boot" level, and
controling whether a thread should be onlined or not.

v3:
  Fix a build error in the patch 6/9


Successfully tested the V3 version on a Power10 LPAR. Add/remove of
processor core worked correctly, preserving the SMT level (on a kernel
booted with smt-enabled= parameter)

Laurent (Thanks!) also provided a patch to update the ppc64_cpu &
lparstat utility. With patched ppc64_cpu utility verified that SMT level
changed at runtime was preserved across processor core add (on
a kernel booted without smt-enabled= parameter)

Based on these test results

Tested-by: Sachin Sant 


Thanks a lot, Sachin!

Once this series is accepted, I'll send the series to update ppc64_cpu.

Re: [PATCH v3 0/9] Introduce SMT level and add PowerPC support

[Sachin Sant]

> On 29-Jun-2023, at 8:01 PM, Laurent Dufour  wrote:
> 
> I'm taking over the series Michael sent previously [1] which is smartly
> reviewing the initial series I sent [2].  This series is addressing the
> comments sent by Thomas and me on the Michael's one.
> 
> Here is a short introduction to the issue this series is addressing:
> 
> When a new CPU is added, the kernel is activating all its threads. This
> leads to weird, but functional, result when adding CPU on a SMT 4 system
> for instance.
> 
> Here the newly added CPU 1 has 8 threads while the other one has 4 threads
> active (system has been booted with the 'smt-enabled=4' kernel option):
> 
> ltcden3-lp12:~ # ppc64_cpu --info
> Core   0:0*1*2*3*4 5 6 7
> Core   1:8*9*   10*   11*   12*   13*   14*   15*
> 
> This mixed SMT level may confused end users and/or some applications.
> 
> There is no SMT level recorded in the kernel (common code), neither in user
> space, as far as I know. Such a level is helpful when adding new CPU or
> when optimizing the energy efficiency (when reactivating CPUs).
> 
> When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT level
> (cpu_smt_num_threads) and few callbacks allowing the architecture code to
> fine control this value, setting a max and a "at boot" level, and
> controling whether a thread should be onlined or not.
> 
> v3:
>  Fix a build error in the patch 6/9

Successfully tested the V3 version on a Power10 LPAR. Add/remove of
processor core worked correctly, preserving the SMT level (on a kernel
booted with smt-enabled= parameter)

Laurent (Thanks!) also provided a patch to update the ppc64_cpu &
lparstat utility. With patched ppc64_cpu utility verified that SMT level
changed at runtime was preserved across processor core add (on
a kernel booted without smt-enabled= parameter)

Based on these test results

Tested-by: Sachin Sant 

- Sachin

[PATCH v3 0/9] Introduce SMT level and add PowerPC support

[Laurent Dufour]

I'm taking over the series Michael sent previously [1] which is smartly
reviewing the initial series I sent [2].  This series is addressing the
comments sent by Thomas and me on the Michael's one.

Here is a short introduction to the issue this series is addressing:

When a new CPU is added, the kernel is activating all its threads. This
leads to weird, but functional, result when adding CPU on a SMT 4 system
for instance.

Here the newly added CPU 1 has 8 threads while the other one has 4 threads
active (system has been booted with the 'smt-enabled=4' kernel option):

ltcden3-lp12:~ # ppc64_cpu --info
Core   0:0*1*2*3*4 5 6 7
Core   1:8*9*   10*   11*   12*   13*   14*   15*

This mixed SMT level may confused end users and/or some applications.

There is no SMT level recorded in the kernel (common code), neither in user
space, as far as I know. Such a level is helpful when adding new CPU or
when optimizing the energy efficiency (when reactivating CPUs).

When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT level
(cpu_smt_num_threads) and few callbacks allowing the architecture code to
fine control this value, setting a max and a "at boot" level, and
controling whether a thread should be onlined or not.

v3:
  Fix a build error in the patch 6/9
v2:
  As Thomas suggested,
Reword some commit's description
Remove topology_smt_supported()
Remove topology_smt_threads_supported()
Introduce CONFIG_SMT_NUM_THREADS_DYNAMIC
Remove switch() in __store_smt_control()
  Update kernel-parameters.txt

[1] 
https://lore.kernel.org/linuxppc-dev/20230524155630.794584-1-...@ellerman.id.au/
[2] 
https://lore.kernel.org/linuxppc-dev/20230331153905.31698-1-lduf...@linux.ibm.com/

Laurent Dufour (1):
  cpu/SMT: Remove topology_smt_supported()

Michael Ellerman (8):
  cpu/SMT: Move SMT prototypes into cpu_smt.h
  cpu/SMT: Move smt/control simple exit cases earlier
  cpu/SMT: Store the current/max number of threads
  cpu/SMT: Create topology_smt_thread_allowed()
  cpu/SMT: Allow enabling partial SMT states via sysfs
  powerpc/pseries: Initialise CPU hotplug callbacks earlier
  powerpc: Add HOTPLUG_SMT support
  powerpc/pseries: Honour current SMT state when DLPAR onlining CPUs

 .../ABI/testing/sysfs-devices-system-cpu  |   1 +
 .../admin-guide/kernel-parameters.txt |   4 +-
 arch/Kconfig  |   3 +
 arch/powerpc/Kconfig  |   2 +
 arch/powerpc/include/asm/topology.h   |  15 +++
 arch/powerpc/kernel/smp.c |   8 +-
 arch/powerpc/platforms/pseries/hotplug-cpu.c  |  30 +++--
 arch/powerpc/platforms/pseries/pseries.h  |   2 +
 arch/powerpc/platforms/pseries/setup.c|   2 +
 arch/x86/include/asm/topology.h   |   4 +-
 arch/x86/kernel/cpu/bugs.c|   3 +-
 arch/x86/kernel/smpboot.c |   8 --
 include/linux/cpu.h   |  25 +---
 include/linux/cpu_smt.h   |  33 +
 kernel/cpu.c  | 118 ++
 15 files changed, 187 insertions(+), 71 deletions(-)
 create mode 100644 include/linux/cpu_smt.h

-- 
2.41.0

Re: [PATCH v3 0/9] PCI/AER: Fix and optimize usage of status clearing api

[Zhuo Chen]

Ping. Gentle reminder


On 11/5/22 1:20 AM, Zhuo Chen wrote:

Hi Bjorn, a gentle reminder.

Thanks and regards.

On 9/28/22 6:59 PM, Zhuo Chen wrote:

Hello.

Here comes patch v3, which contains some fixes and optimizations of
aer api usage. The v1 and v2 can be found on the mailing list.

v3:
- Modifications to comments proposed by Sathyanarayanan. Remove
   pci_aer_clear_nonfatal_status() call in NTB and improve commit log.

v2:
- Modifications to comments proposed by Bjorn. Split patch into more
   obvious parts.

Zhuo Chen (9):
   PCI/AER: Add pci_aer_clear_uncorrect_error_status() to PCI core
   PCI/DPC: Use pci_aer_clear_uncorrect_error_status() to clear
 uncorrectable error status
   NTB: Remove pci_aer_clear_nonfatal_status() call
   scsi: lpfc: Change to use pci_aer_clear_uncorrect_error_status()
   PCI/AER: Unexport pci_aer_clear_nonfatal_status()
   PCI/AER: Move check inside pcie_clear_device_status().
   PCI/AER: Use pcie_aer_is_native() to judge whether OS owns AER
   PCI/ERR: Clear fatal error status when pci_channel_io_frozen
   PCI/AER: Refine status clearing process with api

  drivers/ntb/hw/idt/ntb_hw_idt.c |  2 --
  drivers/pci/pci.c   |  7 +++--
  drivers/pci/pci.h   |  2 ++
  drivers/pci/pcie/aer.c  | 45 +++--
  drivers/pci/pcie/dpc.c  |  3 +--
  drivers/pci/pcie/err.c  | 15 ---
  drivers/pci/pcie/portdrv_core.c |  3 +--
  drivers/scsi/lpfc/lpfc_attr.c   |  4 +--
  include/linux/aer.h |  4 +--
  9 files changed, 44 insertions(+), 41 deletions(-)





--
Zhuo Chen

Re: [PATCH v3 0/9] PCI/AER: Fix and optimize usage of status clearing api

[Zhuo Chen]

Hi Bjorn, a gentle reminder.

Thanks and regards.

On 9/28/22 6:59 PM, Zhuo Chen wrote:

Hello.

Here comes patch v3, which contains some fixes and optimizations of
aer api usage. The v1 and v2 can be found on the mailing list.

v3:
- Modifications to comments proposed by Sathyanarayanan. Remove
   pci_aer_clear_nonfatal_status() call in NTB and improve commit log.

v2:
- Modifications to comments proposed by Bjorn. Split patch into more
   obvious parts.

Zhuo Chen (9):
   PCI/AER: Add pci_aer_clear_uncorrect_error_status() to PCI core
   PCI/DPC: Use pci_aer_clear_uncorrect_error_status() to clear
 uncorrectable error status
   NTB: Remove pci_aer_clear_nonfatal_status() call
   scsi: lpfc: Change to use pci_aer_clear_uncorrect_error_status()
   PCI/AER: Unexport pci_aer_clear_nonfatal_status()
   PCI/AER: Move check inside pcie_clear_device_status().
   PCI/AER: Use pcie_aer_is_native() to judge whether OS owns AER
   PCI/ERR: Clear fatal error status when pci_channel_io_frozen
   PCI/AER: Refine status clearing process with api

  drivers/ntb/hw/idt/ntb_hw_idt.c |  2 --
  drivers/pci/pci.c   |  7 +++--
  drivers/pci/pci.h   |  2 ++
  drivers/pci/pcie/aer.c  | 45 +++--
  drivers/pci/pcie/dpc.c  |  3 +--
  drivers/pci/pcie/err.c  | 15 ---
  drivers/pci/pcie/portdrv_core.c |  3 +--
  drivers/scsi/lpfc/lpfc_attr.c   |  4 +--
  include/linux/aer.h |  4 +--
  9 files changed, 44 insertions(+), 41 deletions(-)



--
Zhuo Chen

Re: [External] Re: [PATCH v3 0/9] PCI/AER: Fix and optimize usage of status clearing api

[Zhuo Chen]

On 9/28/22 7:06 PM, Serge Semin wrote:

On Wed, Sep 28, 2022 at 06:59:37PM +0800, Zhuo Chen wrote:

Hello.

Here comes patch v3, which contains some fixes and optimizations of
aer api usage. The v1 and v2 can be found on the mailing list.

v3:
- Modifications to comments proposed by Sathyanarayanan.



Remove
   pci_aer_clear_nonfatal_status() call in NTB and improve commit log.


Failed to see who has requested that...

-Sergey


Hi, Sergey

Currently other vendor drivers do not clear error status in their own 
init code, I don't exactly know what is special reason for clearing 
error status during init code in ntb driver.


An evidence is in pci_aer_init(), PCI core driver has do 
pci_aer_clear_status() and pci_enable_pcie_error_reporting() in common 
process. So vendor drivers don't need to do again.


But I don't know the reason why many vendor drivers reserve 
pci_enable_pcie_error_reporting() after commit f26e58bf6f54 ("PCI/AER: 
Enable error reporting when AER is native"). Do they need to be removed?

Could Bjorn and Sathyanarayanan help look into it, thanks a lot.

Thanks.


v2:
- Modifications to comments proposed by Bjorn. Split patch into more
   obvious parts.

Zhuo Chen (9):
   PCI/AER: Add pci_aer_clear_uncorrect_error_status() to PCI core
   PCI/DPC: Use pci_aer_clear_uncorrect_error_status() to clear
 uncorrectable error status
   NTB: Remove pci_aer_clear_nonfatal_status() call
   scsi: lpfc: Change to use pci_aer_clear_uncorrect_error_status()
   PCI/AER: Unexport pci_aer_clear_nonfatal_status()
   PCI/AER: Move check inside pcie_clear_device_status().
   PCI/AER: Use pcie_aer_is_native() to judge whether OS owns AER
   PCI/ERR: Clear fatal error status when pci_channel_io_frozen
   PCI/AER: Refine status clearing process with api

  drivers/ntb/hw/idt/ntb_hw_idt.c |  2 --
  drivers/pci/pci.c   |  7 +++--
  drivers/pci/pci.h   |  2 ++
  drivers/pci/pcie/aer.c  | 45 +++--
  drivers/pci/pcie/dpc.c  |  3 +--
  drivers/pci/pcie/err.c  | 15 ---
  drivers/pci/pcie/portdrv_core.c |  3 +--
  drivers/scsi/lpfc/lpfc_attr.c   |  4 +--
  include/linux/aer.h |  4 +--
  9 files changed, 44 insertions(+), 41 deletions(-)

--
2.30.1 (Apple Git-130)



--
Zhuo Chen

Re: [PATCH v3 0/9] PCI/AER: Fix and optimize usage of status clearing api

[Serge Semin]

On Wed, Sep 28, 2022 at 06:59:37PM +0800, Zhuo Chen wrote:
> Hello.
> 
> Here comes patch v3, which contains some fixes and optimizations of
> aer api usage. The v1 and v2 can be found on the mailing list.
> 
> v3:
> - Modifications to comments proposed by Sathyanarayanan.

> Remove
>   pci_aer_clear_nonfatal_status() call in NTB and improve commit log. 

Failed to see who has requested that...

-Sergey

> 
> v2:
> - Modifications to comments proposed by Bjorn. Split patch into more
>   obvious parts.
> 
> Zhuo Chen (9):
>   PCI/AER: Add pci_aer_clear_uncorrect_error_status() to PCI core
>   PCI/DPC: Use pci_aer_clear_uncorrect_error_status() to clear
> uncorrectable error status
>   NTB: Remove pci_aer_clear_nonfatal_status() call
>   scsi: lpfc: Change to use pci_aer_clear_uncorrect_error_status()
>   PCI/AER: Unexport pci_aer_clear_nonfatal_status()
>   PCI/AER: Move check inside pcie_clear_device_status().
>   PCI/AER: Use pcie_aer_is_native() to judge whether OS owns AER
>   PCI/ERR: Clear fatal error status when pci_channel_io_frozen
>   PCI/AER: Refine status clearing process with api
> 
>  drivers/ntb/hw/idt/ntb_hw_idt.c |  2 --
>  drivers/pci/pci.c   |  7 +++--
>  drivers/pci/pci.h   |  2 ++
>  drivers/pci/pcie/aer.c  | 45 +++--
>  drivers/pci/pcie/dpc.c  |  3 +--
>  drivers/pci/pcie/err.c  | 15 ---
>  drivers/pci/pcie/portdrv_core.c |  3 +--
>  drivers/scsi/lpfc/lpfc_attr.c   |  4 +--
>  include/linux/aer.h |  4 +--
>  9 files changed, 44 insertions(+), 41 deletions(-)
> 
> -- 
> 2.30.1 (Apple Git-130)
> 

[PATCH v3 0/9] PCI/AER: Fix and optimize usage of status clearing api

[Zhuo Chen]

Hello.

Here comes patch v3, which contains some fixes and optimizations of
aer api usage. The v1 and v2 can be found on the mailing list.

v3:
- Modifications to comments proposed by Sathyanarayanan. Remove
  pci_aer_clear_nonfatal_status() call in NTB and improve commit log. 

v2:
- Modifications to comments proposed by Bjorn. Split patch into more
  obvious parts.

Zhuo Chen (9):
  PCI/AER: Add pci_aer_clear_uncorrect_error_status() to PCI core
  PCI/DPC: Use pci_aer_clear_uncorrect_error_status() to clear
uncorrectable error status
  NTB: Remove pci_aer_clear_nonfatal_status() call
  scsi: lpfc: Change to use pci_aer_clear_uncorrect_error_status()
  PCI/AER: Unexport pci_aer_clear_nonfatal_status()
  PCI/AER: Move check inside pcie_clear_device_status().
  PCI/AER: Use pcie_aer_is_native() to judge whether OS owns AER
  PCI/ERR: Clear fatal error status when pci_channel_io_frozen
  PCI/AER: Refine status clearing process with api

 drivers/ntb/hw/idt/ntb_hw_idt.c |  2 --
 drivers/pci/pci.c   |  7 +++--
 drivers/pci/pci.h   |  2 ++
 drivers/pci/pcie/aer.c  | 45 +++--
 drivers/pci/pcie/dpc.c  |  3 +--
 drivers/pci/pcie/err.c  | 15 ---
 drivers/pci/pcie/portdrv_core.c |  3 +--
 drivers/scsi/lpfc/lpfc_attr.c   |  4 +--
 include/linux/aer.h |  4 +--
 9 files changed, 44 insertions(+), 41 deletions(-)

-- 
2.30.1 (Apple Git-130)

[PATCH v3 0/9] sections: Unify kernel sections range check and use

[Kefeng Wang]

There are three head files(kallsyms.h, kernel.h and sections.h) which
include the kernel sections range check, let's make some cleanup and
unify them.

1. cleanup arch specific text/data check and fix address boundary check
   in kallsyms.h
2. make all the basic/core kernel range check function into sections.h
3. update all the callers, and use the helper in sections.h to simplify
   the code

After this series, we have 5 APIs about kernel sections range check in
sections.h

 * is_kernel_rodata()   --- already in sections.h
 * is_kernel_core_data()--- come from core_kernel_data() in kernel.h
 * is_kernel_inittext() --- come from kernel.h and kallsyms.h
 * __is_kernel_text()   --- add new internal helper
 * __is_kernel()--- add new internal helper

Note: For the last two helpers, people should not use directly, consider to
  use corresponding function in kallsyms.h.

v3:
- Add Steven's RB to patch2
- Introduce two internal helper, then use is_kernel_text() in core_kernel_text()
  and is_kernel() in kernel_or_module_addr() suggested by Steven

v2:
https://lore.kernel.org/linux-arch/20210728081320.20394-1-wangkefeng.w...@huawei.com/
- add ACK/RW to patch2, and drop inappropriate fix tag
- keep 'core' to check kernel data, suggestted by Steven Rostedt
  , rename is_kernel_data() to is_kernel_core_data()
- drop patch8 which is merged
- drop patch9 which is resend independently

v1:
https://lore.kernel.org/linux-arch/20210626073439.150586-1-wangkefeng.w...@huawei.com

Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-a...@vger.kernel.org 
Cc: b...@vger.kernel.org 

Kefeng Wang (9):
  kallsyms: Remove arch specific text and data check
  kallsyms: Fix address-checks for kernel related range
  sections: Move and rename core_kernel_data() to is_kernel_core_data()
  sections: Move is_kernel_inittext() into sections.h
  x86: mm: Rename __is_kernel_text() to is_x86_32_kernel_text()
  sections: Provide internal __is_kernel() and __is_kernel_text() helper
  mm: kasan: Use is_kernel() helper
  extable: Use is_kernel_text() helper
  powerpc/mm: Use is_kernel_text() and is_kernel_inittext() helper

 arch/powerpc/mm/pgtable_32.c   |  7 +---
 arch/x86/kernel/unwind_orc.c   |  2 +-
 arch/x86/mm/init_32.c  | 14 +++
 include/asm-generic/sections.h | 75 ++
 include/linux/kallsyms.h   | 13 +-
 include/linux/kernel.h |  2 -
 kernel/extable.c   | 33 ++-
 kernel/locking/lockdep.c   |  3 --
 kernel/trace/ftrace.c  |  2 +-
 mm/kasan/report.c  |  2 +-
 net/sysctl_net.c   |  2 +-
 11 files changed, 75 insertions(+), 80 deletions(-)

-- 
2.26.2

Re: [PATCH v3 0/9] powerpc: fast interrupt exit bug and misc fixes

[Michael Ellerman]

On Wed, 30 Jun 2021 17:46:12 +1000, Nicholas Piggin wrote:
> This is a bunch of fixes for powerpc next, mostly a nasty hole in fast
> interrupt exit code found by Sachin and some other bits along the way
> while looking at it.
> 
> Since v2:
> - Fixed 64e patch 3 to really set exit_must_hard_disable.
> - Reworded some changelogs.
> 
> [...]

Applied to powerpc/next.

[1/9] powerpc/64s: fix hash page fault interrupt handler
  https://git.kernel.org/powerpc/c/5567b1ee29b7a83e8c01d99d34b5bbd306ce0bcf
[2/9] powerpc/64e: fix CONFIG_RELOCATABLE build warnings
  https://git.kernel.org/powerpc/c/fce01acf830a697110ed72ecace4b0afdbcd53cb
[3/9] powerpc/64e: remove implicit soft-masking and interrupt exit restart logic
  https://git.kernel.org/powerpc/c/9b69d48c7516a29cdaacd18d8bf5f575014a42a1
[4/9] powerpc/64s: add a table of implicit soft-masked addresses
  https://git.kernel.org/powerpc/c/325678fd052259e7c05ef29060a73c705ea90432
[5/9] powerpc/64s/interrupt: preserve regs->softe for NMI interrupts
  https://git.kernel.org/powerpc/c/1b0482229c302a3c6afd00d6b3bf0169cf279b44
[6/9] powerpc/64: enable MSR[EE] in irq replay pt_regs
  https://git.kernel.org/powerpc/c/2b43dd7653cca47d297756980846ebbfe8887fa1
[7/9] powerpc/64/interrupt: add missing kprobe annotations on interrupt exit 
symbols
  https://git.kernel.org/powerpc/c/98798f33c6be5a511ab61958b40835b3ef08def2
[8/9] powerpc/64s/interrupt: clean up interrupt return labels
  https://git.kernel.org/powerpc/c/c59458b00aec4ba580d9628d36d6c984af94d192
[9/9] powerpc/64s: move ret_from_fork etc above __end_soft_masked
  https://git.kernel.org/powerpc/c/91fc46eced0f70526d74468ac6c932c90a8585b3

cheers

[PATCH v3 0/9] powerpc: fast interrupt exit bug and misc fixes

[Nicholas Piggin]

This is a bunch of fixes for powerpc next, mostly a nasty hole in fast
interrupt exit code found by Sachin and some other bits along the way
while looking at it.

Since v2:
- Fixed 64e patch 3 to really set exit_must_hard_disable.
- Reworded some changelogs.

Since v1:
- Fixed a bisection compile error due to a fix incorrectly going to
  a later patch.
- Fixed the "add a table of implicit soft-masked addresses" patch to
  include the low scv vector range as a soft-masked table entry. scv
  was the original reason for implicit soft masking, and the previous
  version breaks it. My stress testing was using an image without
  scv glibc unfortunately.
- Fixed a bug with the same patch that would restore r12 with SRR1
  rather than HSRR1 in the case of masked hypervisor interrupts after
  searching the soft-mask table. Again unfortunately my stress testing
  was in a guest so no HV interrupts.

Thanks to Michael for noticing these issues.

- Pulled in the hash page fault interrupt handler fix into this series
  to make the dependencies clear (well it's not exactly dependent but
  assertions introduced later make the existing bug crash more often).

Thanks,
Nick

Nicholas Piggin (9):
  powerpc/64s: fix hash page fault interrupt handler
  powerpc/64e: fix CONFIG_RELOCATABLE build warnings
  powerpc/64e: remove implicit soft-masking and interrupt exit restart
logic
  powerpc/64s: add a table of implicit soft-masked addresses
  powerpc/64s/interrupt: preserve regs->softe for NMI interrupts
  powerpc/64: enable MSR[EE] in irq replay pt_regs
  powerpc/64/interrupt: add missing kprobe annotations on interrupt exit
symbols
  powerpc/64s/interrupt: clean up interrupt return labels
  powerpc/64s: move ret_from_fork etc above __end_soft_masked

 arch/powerpc/include/asm/interrupt.h  | 41 +---
 arch/powerpc/include/asm/ppc_asm.h|  7 +++
 arch/powerpc/kernel/exceptions-64e.S  | 23 +++
 arch/powerpc/kernel/exceptions-64s.S  | 64 ---
 arch/powerpc/kernel/interrupt.c   |  2 +-
 arch/powerpc/kernel/interrupt_64.S| 90 ++-
 arch/powerpc/kernel/irq.c |  1 +
 arch/powerpc/kernel/vmlinux.lds.S |  9 +++
 arch/powerpc/lib/restart_table.c  | 26 
 arch/powerpc/mm/book3s64/hash_utils.c | 24 ---
 10 files changed, 212 insertions(+), 75 deletions(-)

-- 
2.23.0

[PATCH v3 0/9] Remove DISCONTIGMEM memory model

[Mike Rapoport]

From: Mike Rapoport 

Hi,

SPARSEMEM memory model was supposed to entirely replace DISCONTIGMEM a
(long) while ago. The last architectures that used DISCONTIGMEM were
updated to use other memory models in v5.11 and it is about the time to
entirely remove DISCONTIGMEM from the kernel.

This set removes DISCONTIGMEM from alpha, arc and m68k, simplifies memory
model selection in mm/Kconfig and replaces usage of redundant
CONFIG_NEED_MULTIPLE_NODES and CONFIG_FLAT_NODE_MEM_MAP with CONFIG_NUMA
and CONFIG_FLATMEM respectively. 

I've also removed NUMA support on alpha that was BROKEN for more than 15
years.

There were also minor updates all over arch/ to remove mentions of
DISCONTIGMEM in comments and #ifdefs.

v3:
* Remove stale reference of CONFIG_NEED_MULTIPLE_NODES and stale
  discontigmem comment, per Geert
* Add Vineet Acks
* Fix spelling in cover letter subject

v2: Link: https://lore.kernel.org/lkml/20210604064916.26580-1-r...@kernel.org
* Fix build errors reported by kbuild bot
* Add additional cleanups in m68k as suggested by Geert

v1: Link: https://lore.kernel.org/lkml/20210602105348.13387-1-r...@kernel.org

Mike Rapoport (9):
  alpha: remove DISCONTIGMEM and NUMA
  arc: update comment about HIGHMEM implementation
  arc: remove support for DISCONTIGMEM
  m68k: remove support for DISCONTIGMEM
  mm: remove CONFIG_DISCONTIGMEM
  arch, mm: remove stale mentions of DISCONIGMEM
  docs: remove description of DISCONTIGMEM
  mm: replace CONFIG_NEED_MULTIPLE_NODES with CONFIG_NUMA
  mm: replace CONFIG_FLAT_NODE_MEM_MAP with CONFIG_FLATMEM

 Documentation/admin-guide/sysctl/vm.rst |  12 +-
 Documentation/vm/memory-model.rst   |  45 +
 arch/alpha/Kconfig  |  22 ---
 arch/alpha/include/asm/machvec.h|   6 -
 arch/alpha/include/asm/mmzone.h | 100 ---
 arch/alpha/include/asm/pgtable.h|   4 -
 arch/alpha/include/asm/topology.h   |  39 -
 arch/alpha/kernel/core_marvel.c |  53 +-
 arch/alpha/kernel/core_wildfire.c   |  29 +--
 arch/alpha/kernel/pci_iommu.c   |  29 ---
 arch/alpha/kernel/proto.h   |   8 -
 arch/alpha/kernel/setup.c   |  16 --
 arch/alpha/kernel/sys_marvel.c  |   5 -
 arch/alpha/kernel/sys_wildfire.c|   5 -
 arch/alpha/mm/Makefile  |   2 -
 arch/alpha/mm/init.c|   3 -
 arch/alpha/mm/numa.c| 223 
 arch/arc/Kconfig|  13 --
 arch/arc/include/asm/mmzone.h   |  40 -
 arch/arc/mm/init.c  |  21 +--
 arch/arm64/Kconfig  |   2 +-
 arch/ia64/Kconfig   |   2 +-
 arch/ia64/kernel/topology.c |   5 +-
 arch/ia64/mm/numa.c |   5 +-
 arch/m68k/Kconfig.cpu   |  10 --
 arch/m68k/include/asm/mmzone.h  |  10 --
 arch/m68k/include/asm/page.h|   2 +-
 arch/m68k/include/asm/page_mm.h |  35 
 arch/m68k/mm/init.c |  20 ---
 arch/mips/Kconfig   |   2 +-
 arch/mips/include/asm/mmzone.h  |   8 +-
 arch/mips/include/asm/page.h|   2 +-
 arch/mips/mm/init.c |   7 +-
 arch/nds32/include/asm/memory.h |   6 -
 arch/powerpc/Kconfig|   2 +-
 arch/powerpc/include/asm/mmzone.h   |   4 +-
 arch/powerpc/kernel/setup_64.c  |   2 +-
 arch/powerpc/kernel/smp.c   |   2 +-
 arch/powerpc/kexec/core.c   |   4 +-
 arch/powerpc/mm/Makefile|   2 +-
 arch/powerpc/mm/mem.c   |   4 +-
 arch/riscv/Kconfig  |   2 +-
 arch/s390/Kconfig   |   2 +-
 arch/sh/include/asm/mmzone.h|   4 +-
 arch/sh/kernel/topology.c   |   2 +-
 arch/sh/mm/Kconfig  |   2 +-
 arch/sh/mm/init.c   |   2 +-
 arch/sparc/Kconfig  |   2 +-
 arch/sparc/include/asm/mmzone.h |   4 +-
 arch/sparc/kernel/smp_64.c  |   2 +-
 arch/sparc/mm/init_64.c |  12 +-
 arch/x86/Kconfig|   2 +-
 arch/x86/kernel/setup_percpu.c  |   6 +-
 arch/x86/mm/init_32.c   |   4 +-
 arch/xtensa/include/asm/page.h  |   4 -
 include/asm-generic/memory_model.h  |  37 +---
 include/asm-generic/topology.h  |   2 +-
 include/linux/gfp.h |   4 +-
 include/linux/memblock.h|   6 +-
 include/linux/mm.h  |   4 +-
 include/linux/mmzone.h  |  20 ++-
 kernel/crash_core.c |   4 +-
 mm/Kconfig  |  36 +---
 mm/memblock.c   |   8 +-
 mm/memory.c |   3 +-
 mm/page_alloc.c |  25 +--
 mm/page_ext.c   |   2 +-
 67 files changed, 101 

Re: [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

[Michael Ellerman]

On Wed, 31 Mar 2021 16:45:05 +0200, Cédric Le Goater wrote:
> ipistorm [*] can be used to benchmark the raw interrupt rate of an
> interrupt controller by measuring the number of IPIs a system can
> sustain. When applied to the XIVE interrupt controller of POWER9 and
> POWER10 systems, a significant drop of the interrupt rate can be
> observed when crossing the second node boundary.
> 
> This is due to the fact that a single IPI interrupt is used for all
> CPUs of the system. The structure is shared and the cache line updates
> impact greatly the traffic between nodes and the overall IPI
> performance.
> 
> [...]

Patches 2-9 applied to powerpc/next.

[2/9] powerpc/xive: Introduce an IPI interrupt domain
  https://git.kernel.org/powerpc/c/7d348494136c8b47c39d1f7ccba28c47d5094a54
[3/9] powerpc/xive: Remove useless check on XIVE_IPI_HW_IRQ
  https://git.kernel.org/powerpc/c/1835e72942b5aa779c8ada62aaeba03ab66d92c9
[4/9] powerpc/xive: Simplify xive_core_debug_show()
  https://git.kernel.org/powerpc/c/5159d9872823230669b7949ba3caf18c4c314846
[5/9] powerpc/xive: Drop check on irq_data in xive_core_debug_show()
  https://git.kernel.org/powerpc/c/a74ce5926b20cd0e6d624a9b2527073a96dfed7f
[6/9] powerpc/xive: Simplify the dump of XIVE interrupts under xmon
  https://git.kernel.org/powerpc/c/6bf66eb8f404050030805c65cf39a810892f5f8e
[7/9] powerpc/xive: Fix xmon command "dxi"
  https://git.kernel.org/powerpc/c/33e4bc5946432a4ac173fd08e8e30a13ab94d06d
[8/9] powerpc/xive: Map one IPI interrupt per node
  https://git.kernel.org/powerpc/c/7dcc37b3eff97379b194adb17eb9a8270512dd1d
[9/9] powerpc/xive: Modernize XIVE-IPI domain with an 'alloc' handler
  https://git.kernel.org/powerpc/c/fd6db2892ebaa1383a93b4a609c65b96e615510a

cheers

Re: [PATCH v3 0/9] Speedup mremap on ppc64

[Aneesh Kumar K.V]

"Aneesh Kumar K.V"  writes:

> This patchset enables MOVE_PMD/MOVE_PUD support on power. This requires
> the platform to support updating higher-level page tables without
> updating page table entries. This also needs to invalidate the Page Walk
> Cache on architecture supporting the same.
>
> Changes from v2:
> * switch from using mmu_gather to flush_pte_tlb_pwc_range() 
>
> Changes from v1:
> * Rebase to recent upstream
> * Fix build issues with tlb_gather_mmu changes
>

Gentle ping. Any objections for this series? 

-aneesh

Re: [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

[Cédric Le Goater]

On 4/1/21 2:45 PM, Greg Kurz wrote:
> On Thu, 1 Apr 2021 11:18:10 +0200
> Cédric Le Goater  wrote:
> 
>> Hello,
>>
>> On 4/1/21 10:04 AM, Greg Kurz wrote:
>>> On Wed, 31 Mar 2021 16:45:05 +0200
>>> Cédric Le Goater  wrote:
>>>

 Hello,

 ipistorm [*] can be used to benchmark the raw interrupt rate of an
 interrupt controller by measuring the number of IPIs a system can
 sustain. When applied to the XIVE interrupt controller of POWER9 and
 POWER10 systems, a significant drop of the interrupt rate can be
 observed when crossing the second node boundary.

 This is due to the fact that a single IPI interrupt is used for all
 CPUs of the system. The structure is shared and the cache line updates
 impact greatly the traffic between nodes and the overall IPI
 performance.

 As a workaround, the impact can be reduced by deactivating the IRQ
 lockup detector ("noirqdebug") which does a lot of accounting in the
 Linux IRQ descriptor structure and is responsible for most of the
 performance penalty.

 As a fix, this proposal allocates an IPI interrupt per node, to be
 shared by all CPUs of that node. It solves the scaling issue, the IRQ
 lockup detector still has an impact but the XIVE interrupt rate scales
 linearly. It also improves the "noirqdebug" case as showed in the
 tables below. 

>>>
>>> As explained by David and others, NUMA nodes happen to match sockets
>>> with current POWER CPUs but these are really different concepts. NUMA
>>> is about CPU memory accesses latency, 
>>
>> This is exactly our problem. we have cache issues because hw threads 
>> on different chips are trying to access the same structure in memory.
>> It happens on virtual platforms and baremetal platforms. This is not
>> restricted to pseries.
>>
> 
> Ok, I get it... the XIVE HW accesses structures in RAM, just like HW threads
> do, so the closer, the better. 

No. That's another problem related to the XIVE internal tables which
should be allocated on the chip where it is "mostly" used. 

The problem is much simpler. As the commit log says : 

 This is due to the fact that a single IPI interrupt is used for all
 CPUs of the system. The structure is shared and the cache line updates
 impact greatly the traffic between nodes and the overall IPI
 performance.

So, we have multiple threads competing for the same IRQ descriptor and 
overloading the PowerBUS with cache update synchronization. 


> This definitely looks NUMA related indeed. So
> yes, the idea of having the XIVE HW to only access local in-RAM data when
> handling IPIs between vCPUs in the same NUMA node makes sense.

yes. That's the goal.
 
> What is less clear is the exact role of ibm,chip-id actually. This is
> currently used on PowerNV only to pick up a default target on the same
> "chip" as the source if possible. What is the detailed motivation behind
> this ?

The "ibm,chip-id" issue is extra noise and not a requirement for this 
patchset.

>>> while in the case of XIVE you
>>> really need to identify a XIVE chip localized in a given socket.
>>>
>>> PAPR doesn't know about sockets, only cores. In other words, a PAPR
>>> compliant guest sees all vCPUs like they all sit in a single socket.
>>
>> There are also NUMA nodes on PAPR.
>>
> 
> Yes but nothing prevents a NUMA node to span over multiple sockets
> or having several NUMA nodes within the same socket, even if this
> isn't the case in practice with current POWER hardware.

yes. A NUMA node could even be a PCI adapter attached to storage. 
I don't know what to say. We are missing a concept maybe.

>>> Same for the XIVE. Trying to introduce a concept of socket, either
>>> by hijacking OPAL's ibm,chip-id or NUMA node ids, is a kind of
>>> spec violation in this context. If the user cares for locality of
>>> the vCPUs and XIVE on the same socket, then it should bind vCPU
>>> threads to host CPUs from the same socket in the first place.
>>
>> Yes. that's a must have of course. You need to reflect the real HW
>> topology in the guest or LPAR if you are after performance, or 
>> restrict the virtual machine to be on a single socket/chip/node.  
>>
>> And this is not only a XIVE problem. XICS has the same problem with
>> a shared single IPI interrupt descriptor but XICS doesn't scale well 
>> by design, so it doesn't show.
>>
>>
>>> Isn't this enough to solve the performance issues this series
>>> want to fix, without the need for virtual socket ids ?
>> what are virtual socket ids ? A new concept ? 
>>
> 
> For now, we have virtual CPUs identified by a virtual CPU id.
> It thus seems natural to speak of a virtual socket id, but
> anyway, the wording isn't really important here and you
> don't answer the question ;-)

if, on the hypervisor, you restrict the virtual machine vCPUs to be 
on a single POWER processor/chip, there is no problem. But large 
KVM guests or PowerVM LPARs do exist on 16s systems.

C.
 

Re: [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

[Greg Kurz]

On Thu, 1 Apr 2021 11:18:10 +0200
Cédric Le Goater  wrote:

> Hello,
> 
> On 4/1/21 10:04 AM, Greg Kurz wrote:
> > On Wed, 31 Mar 2021 16:45:05 +0200
> > Cédric Le Goater  wrote:
> > 
> >>
> >> Hello,
> >>
> >> ipistorm [*] can be used to benchmark the raw interrupt rate of an
> >> interrupt controller by measuring the number of IPIs a system can
> >> sustain. When applied to the XIVE interrupt controller of POWER9 and
> >> POWER10 systems, a significant drop of the interrupt rate can be
> >> observed when crossing the second node boundary.
> >>
> >> This is due to the fact that a single IPI interrupt is used for all
> >> CPUs of the system. The structure is shared and the cache line updates
> >> impact greatly the traffic between nodes and the overall IPI
> >> performance.
> >>
> >> As a workaround, the impact can be reduced by deactivating the IRQ
> >> lockup detector ("noirqdebug") which does a lot of accounting in the
> >> Linux IRQ descriptor structure and is responsible for most of the
> >> performance penalty.
> >>
> >> As a fix, this proposal allocates an IPI interrupt per node, to be
> >> shared by all CPUs of that node. It solves the scaling issue, the IRQ
> >> lockup detector still has an impact but the XIVE interrupt rate scales
> >> linearly. It also improves the "noirqdebug" case as showed in the
> >> tables below. 
> >>
> > 
> > As explained by David and others, NUMA nodes happen to match sockets
> > with current POWER CPUs but these are really different concepts. NUMA
> > is about CPU memory accesses latency, 
> 
> This is exactly our problem. we have cache issues because hw threads 
> on different chips are trying to access the same structure in memory.
> It happens on virtual platforms and baremetal platforms. This is not
> restricted to pseries.
> 

Ok, I get it... the XIVE HW accesses structures in RAM, just like HW threads
do, so the closer, the better. This definitely looks NUMA related indeed. So
yes, the idea of having the XIVE HW to only access local in-RAM data when
handling IPIs between vCPUs in the same NUMA node makes sense.

What is less clear is the exact role of ibm,chip-id actually. This is
currently used on PowerNV only to pick up a default target on the same
"chip" as the source if possible. What is the detailed motivation behind
this ?

> > while in the case of XIVE you
> > really need to identify a XIVE chip localized in a given socket.
> > 
> > PAPR doesn't know about sockets, only cores. In other words, a PAPR
> > compliant guest sees all vCPUs like they all sit in a single socket.
> 
> There are also NUMA nodes on PAPR.
> 

Yes but nothing prevents a NUMA node to span over multiple sockets
or having several NUMA nodes within the same socket, even if this
isn't the case in practice with current POWER hardware.

> > Same for the XIVE. Trying to introduce a concept of socket, either
> > by hijacking OPAL's ibm,chip-id or NUMA node ids, is a kind of
> > spec violation in this context. If the user cares for locality of
> > the vCPUs and XIVE on the same socket, then it should bind vCPU
> > threads to host CPUs from the same socket in the first place.
> 
> Yes. that's a must have of course. You need to reflect the real HW
> topology in the guest or LPAR if you are after performance, or 
> restrict the virtual machine to be on a single socket/chip/node.  
> 
> And this is not only a XIVE problem. XICS has the same problem with
> a shared single IPI interrupt descriptor but XICS doesn't scale well 
> by design, so it doesn't show.
> 
> 
> > Isn't this enough to solve the performance issues this series
> > want to fix, without the need for virtual socket ids ?
> what are virtual socket ids ? A new concept ? 
> 

For now, we have virtual CPUs identified by a virtual CPU id.
It thus seems natural to speak of a virtual socket id, but
anyway, the wording isn't really important here and you
don't answer the question ;-)

> Thanks,
> 
> C.
> 
> > 
> >>  * P9 DD2.2 - 2s * 64 threads
> >>
> >>"noirqdebug"
> >> Mint/sMint/s   
> >>  chips  cpus  IPI/sys   IPI/chip   IPI/chipIPI/sys 
> >>  --
> >>  1  0-15 4.984023   4.875405   4.996536   5.048892
> >> 0-3110.879164  10.544040  10.757632  11.037859
> >> 0-4715.345301  14.688764  14.926520  15.310053
> >> 0-6317.064907  17.066812  17.613416  17.874511
> >>  2  0-7911.768764  21.650749  22.689120  22.566508
> >> 0-9510.616812  26.878789  28.434703  28.320324
> >> 0-111   10.151693  31.397803  31.771773  32.388122
> >> 0-1279.948502  33.139336  34.875716  35.224548
> >>
> >>
> >>  * P10 DD1 - 4s (not homogeneous) 352 threads
> >>
> >>"noirqdebug"
> >> Mint/sMint/s   
> 

Re: [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

[Cédric Le Goater]

Hello,

On 4/1/21 10:04 AM, Greg Kurz wrote:
> On Wed, 31 Mar 2021 16:45:05 +0200
> Cédric Le Goater  wrote:
> 
>>
>> Hello,
>>
>> ipistorm [*] can be used to benchmark the raw interrupt rate of an
>> interrupt controller by measuring the number of IPIs a system can
>> sustain. When applied to the XIVE interrupt controller of POWER9 and
>> POWER10 systems, a significant drop of the interrupt rate can be
>> observed when crossing the second node boundary.
>>
>> This is due to the fact that a single IPI interrupt is used for all
>> CPUs of the system. The structure is shared and the cache line updates
>> impact greatly the traffic between nodes and the overall IPI
>> performance.
>>
>> As a workaround, the impact can be reduced by deactivating the IRQ
>> lockup detector ("noirqdebug") which does a lot of accounting in the
>> Linux IRQ descriptor structure and is responsible for most of the
>> performance penalty.
>>
>> As a fix, this proposal allocates an IPI interrupt per node, to be
>> shared by all CPUs of that node. It solves the scaling issue, the IRQ
>> lockup detector still has an impact but the XIVE interrupt rate scales
>> linearly. It also improves the "noirqdebug" case as showed in the
>> tables below. 
>>
> 
> As explained by David and others, NUMA nodes happen to match sockets
> with current POWER CPUs but these are really different concepts. NUMA
> is about CPU memory accesses latency, 

This is exactly our problem. we have cache issues because hw threads 
on different chips are trying to access the same structure in memory.
It happens on virtual platforms and baremetal platforms. This is not
restricted to pseries.

> while in the case of XIVE you
> really need to identify a XIVE chip localized in a given socket.
> 
> PAPR doesn't know about sockets, only cores. In other words, a PAPR
> compliant guest sees all vCPUs like they all sit in a single socket.

There are also NUMA nodes on PAPR.

> Same for the XIVE. Trying to introduce a concept of socket, either
> by hijacking OPAL's ibm,chip-id or NUMA node ids, is a kind of
> spec violation in this context. If the user cares for locality of
> the vCPUs and XIVE on the same socket, then it should bind vCPU
> threads to host CPUs from the same socket in the first place.

Yes. that's a must have of course. You need to reflect the real HW
topology in the guest or LPAR if you are after performance, or 
restrict the virtual machine to be on a single socket/chip/node.  

And this is not only a XIVE problem. XICS has the same problem with
a shared single IPI interrupt descriptor but XICS doesn't scale well 
by design, so it doesn't show.


> Isn't this enough to solve the performance issues this series
> want to fix, without the need for virtual socket ids ?
what are virtual socket ids ? A new concept ? 

Thanks,

C.

> 
>>  * P9 DD2.2 - 2s * 64 threads
>>
>>"noirqdebug"
>> Mint/sMint/s   
>>  chips  cpus  IPI/sys   IPI/chip   IPI/chipIPI/sys 
>>  --
>>  1  0-15 4.984023   4.875405   4.996536   5.048892
>> 0-3110.879164  10.544040  10.757632  11.037859
>> 0-4715.345301  14.688764  14.926520  15.310053
>> 0-6317.064907  17.066812  17.613416  17.874511
>>  2  0-7911.768764  21.650749  22.689120  22.566508
>> 0-9510.616812  26.878789  28.434703  28.320324
>> 0-111   10.151693  31.397803  31.771773  32.388122
>> 0-1279.948502  33.139336  34.875716  35.224548
>>
>>
>>  * P10 DD1 - 4s (not homogeneous) 352 threads
>>
>>"noirqdebug"
>> Mint/sMint/s   
>>  chips  cpus  IPI/sys   IPI/chip   IPI/chipIPI/sys 
>>  --
>>  1  0-15 2.409402   2.364108   2.383303   2.395091
>> 0-31 6.028325   6.046075   6.08   6.073750
>> 0-47 8.655178   8.644531   8.712830   8.724702
>> 0-6311.629652  11.735953  12.088203  12.055979
>> 0-7914.392321  14.729959  14.986701  14.973073
>> 0-9512.604158  13.004034  17.528748  17.568095
>>  2  0-1119.767753  13.719831  19.968606  20.024218
>> 0-1276.744566  16.418854  22.898066  22.995110
>> 0-1436.005699  19.174421  25.425622  25.417541
>> 0-1595.649719  21.938836  27.952662  28.059603
>> 0-1755.441410  24.109484  31.133915  31.127996
>>  3  0-1915.318341  24.405322  33.999221  33.775354
>> 0-2075.191382  26.449769  36.050161  35.867307
>> 0-2235.102790  29.356943  39.544135  39.508169
>> 0-2395.035295  31.933051  42.135075  42.071975
>> 0-2554.969209  

Re: [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

[Cédric Le Goater]

Hello,


On 3/31/21 4:45 PM, Cédric Le Goater wrote:
> 
> Hello,
> 
> ipistorm [*] can be used to benchmark the raw interrupt rate of an
> interrupt controller by measuring the number of IPIs a system can
> sustain. When applied to the XIVE interrupt controller of POWER9 and
> POWER10 systems, a significant drop of the interrupt rate can be
> observed when crossing the second node boundary.
> 
> This is due to the fact that a single IPI interrupt is used for all
> CPUs of the system. The structure is shared and the cache line updates
> impact greatly the traffic between nodes and the overall IPI
> performance.
> 
> As a workaround, the impact can be reduced by deactivating the IRQ
> lockup detector ("noirqdebug") which does a lot of accounting in the
> Linux IRQ descriptor structure and is responsible for most of the
> performance penalty.
> 
> As a fix, this proposal allocates an IPI interrupt per node, to be
> shared by all CPUs of that node. It solves the scaling issue, the IRQ
> lockup detector still has an impact but the XIVE interrupt rate scales
> linearly. It also improves the "noirqdebug" case as showed in the
> tables below. Hello,

>From the comments, I received on different email threads. It seems 
I am doing some wrong assumption on the code and concepts. We canpostpone this 
patchset. It's an optimization and there are some 
more cleanups that can be done before. 

Thanks for the time and the shared expertise,

C.

> 
>  * P9 DD2.2 - 2s * 64 threads
> 
>"noirqdebug"
> Mint/sMint/s   
>  chips  cpus  IPI/sys   IPI/chip   IPI/chipIPI/sys 
>  --
>  1  0-15 4.984023   4.875405   4.996536   5.048892
> 0-3110.879164  10.544040  10.757632  11.037859
> 0-4715.345301  14.688764  14.926520  15.310053
> 0-6317.064907  17.066812  17.613416  17.874511
>  2  0-7911.768764  21.650749  22.689120  22.566508
> 0-9510.616812  26.878789  28.434703  28.320324
> 0-111   10.151693  31.397803  31.771773  32.388122
> 0-1279.948502  33.139336  34.875716  35.224548
> 
> 
>  * P10 DD1 - 4s (not homogeneous) 352 threads
> 
>"noirqdebug"
> Mint/sMint/s   
>  chips  cpus  IPI/sys   IPI/chip   IPI/chipIPI/sys 
>  --
>  1  0-15 2.409402   2.364108   2.383303   2.395091
> 0-31 6.028325   6.046075   6.08   6.073750
> 0-47 8.655178   8.644531   8.712830   8.724702
> 0-6311.629652  11.735953  12.088203  12.055979
> 0-7914.392321  14.729959  14.986701  14.973073
> 0-9512.604158  13.004034  17.528748  17.568095
>  2  0-1119.767753  13.719831  19.968606  20.024218
> 0-1276.744566  16.418854  22.898066  22.995110
> 0-1436.005699  19.174421  25.425622  25.417541
> 0-1595.649719  21.938836  27.952662  28.059603
> 0-1755.441410  24.109484  31.133915  31.127996
>  3  0-1915.318341  24.405322  33.999221  33.775354
> 0-2075.191382  26.449769  36.050161  35.867307
> 0-2235.102790  29.356943  39.544135  39.508169
> 0-2395.035295  31.933051  42.135075  42.071975
> 0-2554.969209  34.477367  44.655395  44.757074
>  4  0-2714.907652  35.887016  47.080545  47.318537
> 0-2874.839581  38.076137  50.464307  50.636219
> 0-3034.786031  40.881319  53.478684  53.310759
> 0-3194.743750  43.448424  56.388102  55.973969
> 0-3354.709936  45.623532  59.400930  58.926857
> 0-3514.681413  45.646151  62.035804  61.830057
> 
> [*] https://github.com/antonblanchard/ipistorm
> 
> Thanks,
> 
> C.
> 
> Changes in v3:
> 
>   - improved commit log for the misuse of "ibm,chip-id"
>   - better error handling of xive_request_ipi()
>   - use of a fwnode_handle to name the new domain 
>   - increased IPI name length
>   - use of early_cpu_to_node() for hotplugged CPUs
>   - filter CPU-less nodes
> 
> Changes in v2:
> 
>   - extra simplification on xmon
>   - fixes on issues reported by the kernel test robot
> 
> Cédric Le Goater (9):
>   powerpc/xive: Use cpu_to_node() instead of "ibm,chip-id" property
>   powerpc/xive: Introduce an IPI interrupt domain
>   powerpc/xive: Remove useless check on XIVE_IPI_HW_IRQ
>   powerpc/xive: Simplify xive_core_debug_show()
>   powerpc/xive: Drop check on irq_data in xive_core_debug_show()
>   powerpc/xive: Simplify the dump of XIVE interrupts under xmon
>   powerpc/xive: Fix xmon command "dxi"
>   powerpc/xive: Map one IPI interrupt per node
>   

Re: [PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

[Greg Kurz]

On Wed, 31 Mar 2021 16:45:05 +0200
Cédric Le Goater  wrote:

> 
> Hello,
> 
> ipistorm [*] can be used to benchmark the raw interrupt rate of an
> interrupt controller by measuring the number of IPIs a system can
> sustain. When applied to the XIVE interrupt controller of POWER9 and
> POWER10 systems, a significant drop of the interrupt rate can be
> observed when crossing the second node boundary.
> 
> This is due to the fact that a single IPI interrupt is used for all
> CPUs of the system. The structure is shared and the cache line updates
> impact greatly the traffic between nodes and the overall IPI
> performance.
> 
> As a workaround, the impact can be reduced by deactivating the IRQ
> lockup detector ("noirqdebug") which does a lot of accounting in the
> Linux IRQ descriptor structure and is responsible for most of the
> performance penalty.
> 
> As a fix, this proposal allocates an IPI interrupt per node, to be
> shared by all CPUs of that node. It solves the scaling issue, the IRQ
> lockup detector still has an impact but the XIVE interrupt rate scales
> linearly. It also improves the "noirqdebug" case as showed in the
> tables below. 
> 

As explained by David and others, NUMA nodes happen to match sockets
with current POWER CPUs but these are really different concepts. NUMA
is about CPU memory accesses latency, while in the case of XIVE you
really need to identify a XIVE chip localized in a given socket.

PAPR doesn't know about sockets, only cores. In other words, a PAPR
compliant guest sees all vCPUs like they all sit in a single socket.
Same for the XIVE. Trying to introduce a concept of socket, either
by hijacking OPAL's ibm,chip-id or NUMA node ids, is a kind of
spec violation in this context. If the user cares for locality of
the vCPUs and XIVE on the same socket, then it should bind vCPU
threads to host CPUs from the same socket in the first place.
Isn't this enough to solve the performance issues this series
want to fix, without the need for virtual socket ids ?

>  * P9 DD2.2 - 2s * 64 threads
> 
>"noirqdebug"
> Mint/sMint/s   
>  chips  cpus  IPI/sys   IPI/chip   IPI/chipIPI/sys 
>  --
>  1  0-15 4.984023   4.875405   4.996536   5.048892
> 0-3110.879164  10.544040  10.757632  11.037859
> 0-4715.345301  14.688764  14.926520  15.310053
> 0-6317.064907  17.066812  17.613416  17.874511
>  2  0-7911.768764  21.650749  22.689120  22.566508
> 0-9510.616812  26.878789  28.434703  28.320324
> 0-111   10.151693  31.397803  31.771773  32.388122
> 0-1279.948502  33.139336  34.875716  35.224548
> 
> 
>  * P10 DD1 - 4s (not homogeneous) 352 threads
> 
>"noirqdebug"
> Mint/sMint/s   
>  chips  cpus  IPI/sys   IPI/chip   IPI/chipIPI/sys 
>  --
>  1  0-15 2.409402   2.364108   2.383303   2.395091
> 0-31 6.028325   6.046075   6.08   6.073750
> 0-47 8.655178   8.644531   8.712830   8.724702
> 0-6311.629652  11.735953  12.088203  12.055979
> 0-7914.392321  14.729959  14.986701  14.973073
> 0-9512.604158  13.004034  17.528748  17.568095
>  2  0-1119.767753  13.719831  19.968606  20.024218
> 0-1276.744566  16.418854  22.898066  22.995110
> 0-1436.005699  19.174421  25.425622  25.417541
> 0-1595.649719  21.938836  27.952662  28.059603
> 0-1755.441410  24.109484  31.133915  31.127996
>  3  0-1915.318341  24.405322  33.999221  33.775354
> 0-2075.191382  26.449769  36.050161  35.867307
> 0-2235.102790  29.356943  39.544135  39.508169
> 0-2395.035295  31.933051  42.135075  42.071975
> 0-2554.969209  34.477367  44.655395  44.757074
>  4  0-2714.907652  35.887016  47.080545  47.318537
> 0-2874.839581  38.076137  50.464307  50.636219
> 0-3034.786031  40.881319  53.478684  53.310759
> 0-3194.743750  43.448424  56.388102  55.973969
> 0-3354.709936  45.623532  59.400930  58.926857
> 0-3514.681413  45.646151  62.035804  61.830057
> 
> [*] https://github.com/antonblanchard/ipistorm
> 
> Thanks,
> 
> C.
> 
> Changes in v3:
> 
>   - improved commit log for the misuse of "ibm,chip-id"
>   - better error handling of xive_request_ipi()
>   - use of a fwnode_handle to name the new domain 
>   - increased IPI name length
>   - use of early_cpu_to_node() for hotplugged CPUs
>   - filter CPU-less nodes
> 
> Changes in v2:
> 
>   - extra simplification 

[PATCH v3 0/9] powerpc/xive: Map one IPI interrupt per node

[Cédric Le Goater]

Hello,

ipistorm [*] can be used to benchmark the raw interrupt rate of an
interrupt controller by measuring the number of IPIs a system can
sustain. When applied to the XIVE interrupt controller of POWER9 and
POWER10 systems, a significant drop of the interrupt rate can be
observed when crossing the second node boundary.

This is due to the fact that a single IPI interrupt is used for all
CPUs of the system. The structure is shared and the cache line updates
impact greatly the traffic between nodes and the overall IPI
performance.

As a workaround, the impact can be reduced by deactivating the IRQ
lockup detector ("noirqdebug") which does a lot of accounting in the
Linux IRQ descriptor structure and is responsible for most of the
performance penalty.

As a fix, this proposal allocates an IPI interrupt per node, to be
shared by all CPUs of that node. It solves the scaling issue, the IRQ
lockup detector still has an impact but the XIVE interrupt rate scales
linearly. It also improves the "noirqdebug" case as showed in the
tables below. 

 * P9 DD2.2 - 2s * 64 threads

   "noirqdebug"
Mint/sMint/s   
 chips  cpus  IPI/sys   IPI/chip   IPI/chipIPI/sys 
 --
 1  0-15 4.984023   4.875405   4.996536   5.048892
0-3110.879164  10.544040  10.757632  11.037859
0-4715.345301  14.688764  14.926520  15.310053
0-6317.064907  17.066812  17.613416  17.874511
 2  0-7911.768764  21.650749  22.689120  22.566508
0-9510.616812  26.878789  28.434703  28.320324
0-111   10.151693  31.397803  31.771773  32.388122
0-1279.948502  33.139336  34.875716  35.224548


 * P10 DD1 - 4s (not homogeneous) 352 threads

   "noirqdebug"
Mint/sMint/s   
 chips  cpus  IPI/sys   IPI/chip   IPI/chipIPI/sys 
 --
 1  0-15 2.409402   2.364108   2.383303   2.395091
0-31 6.028325   6.046075   6.08   6.073750
0-47 8.655178   8.644531   8.712830   8.724702
0-6311.629652  11.735953  12.088203  12.055979
0-7914.392321  14.729959  14.986701  14.973073
0-9512.604158  13.004034  17.528748  17.568095
 2  0-1119.767753  13.719831  19.968606  20.024218
0-1276.744566  16.418854  22.898066  22.995110
0-1436.005699  19.174421  25.425622  25.417541
0-1595.649719  21.938836  27.952662  28.059603
0-1755.441410  24.109484  31.133915  31.127996
 3  0-1915.318341  24.405322  33.999221  33.775354
0-2075.191382  26.449769  36.050161  35.867307
0-2235.102790  29.356943  39.544135  39.508169
0-2395.035295  31.933051  42.135075  42.071975
0-2554.969209  34.477367  44.655395  44.757074
 4  0-2714.907652  35.887016  47.080545  47.318537
0-2874.839581  38.076137  50.464307  50.636219
0-3034.786031  40.881319  53.478684  53.310759
0-3194.743750  43.448424  56.388102  55.973969
0-3354.709936  45.623532  59.400930  58.926857
0-3514.681413  45.646151  62.035804  61.830057

[*] https://github.com/antonblanchard/ipistorm

Thanks,

C.

Changes in v3:

  - improved commit log for the misuse of "ibm,chip-id"
  - better error handling of xive_request_ipi()
  - use of a fwnode_handle to name the new domain 
  - increased IPI name length
  - use of early_cpu_to_node() for hotplugged CPUs
  - filter CPU-less nodes

Changes in v2:

  - extra simplification on xmon
  - fixes on issues reported by the kernel test robot

Cédric Le Goater (9):
  powerpc/xive: Use cpu_to_node() instead of "ibm,chip-id" property
  powerpc/xive: Introduce an IPI interrupt domain
  powerpc/xive: Remove useless check on XIVE_IPI_HW_IRQ
  powerpc/xive: Simplify xive_core_debug_show()
  powerpc/xive: Drop check on irq_data in xive_core_debug_show()
  powerpc/xive: Simplify the dump of XIVE interrupts under xmon
  powerpc/xive: Fix xmon command "dxi"
  powerpc/xive: Map one IPI interrupt per node
  powerpc/xive: Modernize XIVE-IPI domain with an 'alloc' handler

 arch/powerpc/include/asm/xive.h  |   1 +
 arch/powerpc/sysdev/xive/xive-internal.h |   2 -
 arch/powerpc/sysdev/xive/common.c| 211 +++
 arch/powerpc/xmon/xmon.c |  28 +--
 4 files changed, 139 insertions(+), 103 deletions(-)

-- 
2.26.3

[PATCH v3 0/9] Speedup mremap on ppc64

[Aneesh Kumar K.V]

This patchset enables MOVE_PMD/MOVE_PUD support on power. This requires
the platform to support updating higher-level page tables without
updating page table entries. This also needs to invalidate the Page Walk
Cache on architecture supporting the same.

Changes from v2:
* switch from using mmu_gather to flush_pte_tlb_pwc_range() 

Changes from v1:
* Rebase to recent upstream
* Fix build issues with tlb_gather_mmu changes



Aneesh Kumar K.V (9):
  selftest/mremap_test: Update the test to handle pagesize other than 4K
  selftest/mremap_test: Avoid crash with static build
  mm/mremap: Use pmd/pud_poplulate to update page table entries
  powerpc/mm/book3s64: Fix possible build error
  powerpc/mm/book3s64: Update tlb flush routines to take a page walk
cache flush argument
  mm/mremap: Use range flush that does TLB and page walk cache flush
  mm/mremap: Move TLB flush outside page table lock
  mm/mremap: Allow arch runtime override
  powerpc/mm: Enable move pmd/pud

 arch/arc/include/asm/tlb.h|   5 +
 arch/arm64/include/asm/tlb.h  |   6 +
 .../include/asm/book3s/64/tlbflush-radix.h|  19 +--
 arch/powerpc/include/asm/book3s/64/tlbflush.h |  30 -
 arch/powerpc/include/asm/tlb.h|   6 +
 arch/powerpc/mm/book3s64/radix_hugetlbpage.c  |   4 +-
 arch/powerpc/mm/book3s64/radix_tlb.c  |  49 
 arch/powerpc/platforms/Kconfig.cputype|   2 +
 arch/x86/include/asm/tlb.h|   5 +
 mm/mremap.c   |  40 --
 tools/testing/selftests/vm/mremap_test.c  | 118 ++
 11 files changed, 187 insertions(+), 97 deletions(-)

-- 
2.30.2

[PATCH v3 0/9] powerpc/watchpoint: Enable 2nd DAWR on baremetal and powervm

[Ravi Bangoria]

Last series[1] was to add basic infrastructure support for more than
one watchpoint on Book3S powerpc. This series actually enables the 2nd 
DAWR for baremetal and powervm. Kvm guest is still not supported.

v2: 
https://lore.kernel.org/linuxppc-dev/20200604033443.70591-1-ravi.bango...@linux.ibm.com/

v2->v3:
 - patch #2 is new. It fixes an issue with DAWR exception constraint
 - Rename dawr1 to debug-facilities-v31 in dt cpu feature, suggested
   by Nick Piggin.
 - Rebased to powerpc/next

[1]: 
https://lore.kernel.org/linuxppc-dev/20200514111741.97993-1-ravi.bango...@linux.ibm.com/

Ravi Bangoria (9):
  powerpc/watchpoint: Fix 512 byte boundary limit
  powerpc/watchpoint: Fix DAWR exception constraint
  powerpc/watchpoint: Enable watchpoint functionality on power10 guest
  powerpc/dt_cpu_ftrs: Add feature for 2nd DAWR
  powerpc/watchpoint: Set CPU_FTR_DAWR1 based on pa-features bit
  powerpc/watchpoint: Rename current H_SET_MODE DAWR macro
  powerpc/watchpoint: Guest support for 2nd DAWR hcall
  powerpc/watchpoint: Return available watchpoints dynamically
  powerpc/watchpoint: Remove 512 byte boundary

 arch/powerpc/include/asm/cputable.h   | 13 ++-
 arch/powerpc/include/asm/hvcall.h |  3 +-
 arch/powerpc/include/asm/hw_breakpoint.h  |  5 +-
 arch/powerpc/include/asm/machdep.h|  2 +-
 arch/powerpc/include/asm/plpar_wrappers.h |  7 +-
 arch/powerpc/kernel/dawr.c|  2 +-
 arch/powerpc/kernel/dt_cpu_ftrs.c |  7 ++
 arch/powerpc/kernel/hw_breakpoint.c   | 98 +++
 arch/powerpc/kernel/prom.c|  2 +
 arch/powerpc/kvm/book3s_hv.c  |  2 +-
 arch/powerpc/platforms/pseries/setup.c|  7 +-
 11 files changed, 103 insertions(+), 45 deletions(-)

-- 
2.26.2

Re: [PATCH v3 0/9] crypto/nx: Enable GZIP engine and provide userpace API

[Haren Myneni]

On Tue, 2020-03-17 at 00:04 +1100, Daniel Axtens wrote:
> Hi Haren,
> 
> If I understand correctly, to test these, I need to apply both this
> series and your VAS userspace page fault handling series - is that
> right?

Daniel, 

Yes, This patch series enables GZIP engine and provides user space API.
Whereas VAS fault handling series process faults if NX sees fault on
request buffer.  

selftest -
https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-March/206035.html

or https://github.com/abalib/power-gzip/tree/develop/selftest

More tests are available - https://github.com/abalib/power-gzip

libnxz - https://github.com/libnxz/power-gzip  

Thanks
Haren

> 
> Kind regards,
> Daniel
> 
> > Power9 processor supports Virtual Accelerator Switchboard (VAS) which
> > allows kernel and userspace to send compression requests to Nest
> > Accelerator (NX) directly. The NX unit comprises of 2 842 compression
> > engines and 1 GZIP engine. Linux kernel already has 842 compression
> > support on kernel. This patch series adds GZIP compression support
> > from user space. The GZIP Compression engine implements the ZLIB and
> > GZIP compression algorithms. No plans of adding NX-GZIP compression
> > support in kernel right now.
> >
> > Applications can send requests to NX directly with COPY/PASTE
> > instructions. But kernel has to establish channel / window on NX-GZIP
> > device for the userspace. So userspace access to the GZIP engine is
> > provided through /dev/crypto/nx-gzip device with several operations.
> >
> > An application must open the this device to obtain a file descriptor (fd).
> > Using the fd, application should issue the VAS_TX_WIN_OPEN ioctl to
> > establish a connection to the engine. Once window is opened, should use
> > mmap() system call to map the hardware address of engine's request queue
> > into the application's virtual address space. Then user space forms the
> > request as co-processor Request Block (CRB) and paste this CRB on the
> > mapped HW address using COPY/PASTE instructions. Application can poll
> > on status flags (part of CRB) with timeout for request completion.
> >
> > For VAS_TX_WIN_OPEN ioctl, if user space passes vas_id = -1 (struct
> > vas_tx_win_open_attr), kernel determines the VAS instance on the
> > corresponding chip based on the CPU on which the process is executing.
> > Otherwise, the specified VAS instance is used if application passes the
> > proper VAS instance (vas_id listed in /proc/device-tree/vas@*/ibm,vas_id).
> >
> > Process can open multiple windows with different FDs or can send several
> > requests to NX on the same window at the same time.
> >
> > A userspace library libnxz is available:
> > https://github.com/abalib/power-gzip
> >
> > Applications that use inflate/deflate calls can link with libNXz and use
> > NX GZIP compression without any modification.
> >
> > Tested the available 842 compression on power8 and power9 system to make
> > sure no regression and tested GZIP compression on power9 with tests
> > available in the above link.
> >
> > Thanks to Bulent Abali for nxz library and tests development.
> >
> > Changelog:
> > V2:
> >   - Move user space API code to powerpc as suggested. Also this API
> > can be extended to any other coprocessor type that VAS can support
> > in future. Example: Fast thread wakeup feature from VAS
> >   - Rebased to 5.6-rc3
> >
> > V3:
> >   - Fix sparse warnings (patches 3&6)
> >
> > Haren Myneni (9):
> >   powerpc/vas: Initialize window attributes for GZIP coprocessor type
> >   powerpc/vas: Define VAS_TX_WIN_OPEN ioctl API
> >   powerpc/vas: Add VAS user space API
> >   crypto/nx: Initialize coproc entry with kzalloc
> >   crypto/nx: Rename nx-842-powernv file name to nx-common-powernv
> >   crypto/NX: Make enable code generic to add new GZIP compression type
> >   crypto/nx: Enable and setup GZIP compresstion type
> >   crypto/nx: Remove 'pid' in vas_tx_win_attr struct
> >   Documentation/powerpc: VAS API
> >
> >  Documentation/powerpc/index.rst|1 +
> >  Documentation/powerpc/vas-api.rst  |  246 +
> >  Documentation/userspace-api/ioctl/ioctl-number.rst |1 +
> >  arch/powerpc/include/asm/vas.h |   12 +-
> >  arch/powerpc/include/uapi/asm/vas-api.h|   22 +
> >  arch/powerpc/platforms/powernv/Makefile|2 +-
> >  arch/powerpc/platforms/powernv/vas-api.c   |  290 +
> >  arch/powerpc/platforms/powernv/vas-window.c|   23 +-
> >  arch/powerpc/platforms/powernv/vas.h   |2 +
> >  drivers/crypto/nx/Makefile |2 +-
> >  drivers/crypto/nx/nx-842-powernv.c | 1062 
> > --
> >  drivers/crypto/nx/nx-common-powernv.c  | 1133 
> > 
> >  12 files changed, 1723 insertions(+), 1073 deletions(-)
> >  create mode 100644 Documentation/powerpc/vas-api.rst
> >  create mode 100644 

Re: [PATCH v3 0/9] crypto/nx: Enable GZIP engine and provide userpace API

[Daniel Axtens]

Hi Haren,

If I understand correctly, to test these, I need to apply both this
series and your VAS userspace page fault handling series - is that
right?

Kind regards,
Daniel

> Power9 processor supports Virtual Accelerator Switchboard (VAS) which
> allows kernel and userspace to send compression requests to Nest
> Accelerator (NX) directly. The NX unit comprises of 2 842 compression
> engines and 1 GZIP engine. Linux kernel already has 842 compression
> support on kernel. This patch series adds GZIP compression support
> from user space. The GZIP Compression engine implements the ZLIB and
> GZIP compression algorithms. No plans of adding NX-GZIP compression
> support in kernel right now.
>
> Applications can send requests to NX directly with COPY/PASTE
> instructions. But kernel has to establish channel / window on NX-GZIP
> device for the userspace. So userspace access to the GZIP engine is
> provided through /dev/crypto/nx-gzip device with several operations.
>
> An application must open the this device to obtain a file descriptor (fd).
> Using the fd, application should issue the VAS_TX_WIN_OPEN ioctl to
> establish a connection to the engine. Once window is opened, should use
> mmap() system call to map the hardware address of engine's request queue
> into the application's virtual address space. Then user space forms the
> request as co-processor Request Block (CRB) and paste this CRB on the
> mapped HW address using COPY/PASTE instructions. Application can poll
> on status flags (part of CRB) with timeout for request completion.
>
> For VAS_TX_WIN_OPEN ioctl, if user space passes vas_id = -1 (struct
> vas_tx_win_open_attr), kernel determines the VAS instance on the
> corresponding chip based on the CPU on which the process is executing.
> Otherwise, the specified VAS instance is used if application passes the
> proper VAS instance (vas_id listed in /proc/device-tree/vas@*/ibm,vas_id).
>
> Process can open multiple windows with different FDs or can send several
> requests to NX on the same window at the same time.
>
> A userspace library libnxz is available:
> https://github.com/abalib/power-gzip
>
> Applications that use inflate/deflate calls can link with libNXz and use
> NX GZIP compression without any modification.
>
> Tested the available 842 compression on power8 and power9 system to make
> sure no regression and tested GZIP compression on power9 with tests
> available in the above link.
>
> Thanks to Bulent Abali for nxz library and tests development.
>
> Changelog:
> V2:
>   - Move user space API code to powerpc as suggested. Also this API
> can be extended to any other coprocessor type that VAS can support
> in future. Example: Fast thread wakeup feature from VAS
>   - Rebased to 5.6-rc3
>
> V3:
>   - Fix sparse warnings (patches 3&6)
>
> Haren Myneni (9):
>   powerpc/vas: Initialize window attributes for GZIP coprocessor type
>   powerpc/vas: Define VAS_TX_WIN_OPEN ioctl API
>   powerpc/vas: Add VAS user space API
>   crypto/nx: Initialize coproc entry with kzalloc
>   crypto/nx: Rename nx-842-powernv file name to nx-common-powernv
>   crypto/NX: Make enable code generic to add new GZIP compression type
>   crypto/nx: Enable and setup GZIP compresstion type
>   crypto/nx: Remove 'pid' in vas_tx_win_attr struct
>   Documentation/powerpc: VAS API
>
>  Documentation/powerpc/index.rst|1 +
>  Documentation/powerpc/vas-api.rst  |  246 +
>  Documentation/userspace-api/ioctl/ioctl-number.rst |1 +
>  arch/powerpc/include/asm/vas.h |   12 +-
>  arch/powerpc/include/uapi/asm/vas-api.h|   22 +
>  arch/powerpc/platforms/powernv/Makefile|2 +-
>  arch/powerpc/platforms/powernv/vas-api.c   |  290 +
>  arch/powerpc/platforms/powernv/vas-window.c|   23 +-
>  arch/powerpc/platforms/powernv/vas.h   |2 +
>  drivers/crypto/nx/Makefile |2 +-
>  drivers/crypto/nx/nx-842-powernv.c | 1062 --
>  drivers/crypto/nx/nx-common-powernv.c  | 1133 
> 
>  12 files changed, 1723 insertions(+), 1073 deletions(-)
>  create mode 100644 Documentation/powerpc/vas-api.rst
>  create mode 100644 arch/powerpc/include/uapi/asm/vas-api.h
>  create mode 100644 arch/powerpc/platforms/powernv/vas-api.c
>  delete mode 100644 drivers/crypto/nx/nx-842-powernv.c
>  create mode 100644 drivers/crypto/nx/nx-common-powernv.c
>
> -- 
> 1.8.3.1

[PATCH v3 0/9] crypto/nx: Enable GZIP engine and provide userpace API

[Haren Myneni]

Power9 processor supports Virtual Accelerator Switchboard (VAS) which
allows kernel and userspace to send compression requests to Nest
Accelerator (NX) directly. The NX unit comprises of 2 842 compression
engines and 1 GZIP engine. Linux kernel already has 842 compression
support on kernel. This patch series adds GZIP compression support
from user space. The GZIP Compression engine implements the ZLIB and
GZIP compression algorithms. No plans of adding NX-GZIP compression
support in kernel right now.

Applications can send requests to NX directly with COPY/PASTE
instructions. But kernel has to establish channel / window on NX-GZIP
device for the userspace. So userspace access to the GZIP engine is
provided through /dev/crypto/nx-gzip device with several operations.

An application must open the this device to obtain a file descriptor (fd).
Using the fd, application should issue the VAS_TX_WIN_OPEN ioctl to
establish a connection to the engine. Once window is opened, should use
mmap() system call to map the hardware address of engine's request queue
into the application's virtual address space. Then user space forms the
request as co-processor Request Block (CRB) and paste this CRB on the
mapped HW address using COPY/PASTE instructions. Application can poll
on status flags (part of CRB) with timeout for request completion.

For VAS_TX_WIN_OPEN ioctl, if user space passes vas_id = -1 (struct
vas_tx_win_open_attr), kernel determines the VAS instance on the
corresponding chip based on the CPU on which the process is executing.
Otherwise, the specified VAS instance is used if application passes the
proper VAS instance (vas_id listed in /proc/device-tree/vas@*/ibm,vas_id).

Process can open multiple windows with different FDs or can send several
requests to NX on the same window at the same time.

A userspace library libnxz is available:
https://github.com/abalib/power-gzip

Applications that use inflate/deflate calls can link with libNXz and use
NX GZIP compression without any modification.

Tested the available 842 compression on power8 and power9 system to make
sure no regression and tested GZIP compression on power9 with tests
available in the above link.

Thanks to Bulent Abali for nxz library and tests development.

Changelog:
V2:
  - Move user space API code to powerpc as suggested. Also this API
can be extended to any other coprocessor type that VAS can support
in future. Example: Fast thread wakeup feature from VAS
  - Rebased to 5.6-rc3

V3:
  - Fix sparse warnings (patches 3&6)

Haren Myneni (9):
  powerpc/vas: Initialize window attributes for GZIP coprocessor type
  powerpc/vas: Define VAS_TX_WIN_OPEN ioctl API
  powerpc/vas: Add VAS user space API
  crypto/nx: Initialize coproc entry with kzalloc
  crypto/nx: Rename nx-842-powernv file name to nx-common-powernv
  crypto/NX: Make enable code generic to add new GZIP compression type
  crypto/nx: Enable and setup GZIP compresstion type
  crypto/nx: Remove 'pid' in vas_tx_win_attr struct
  Documentation/powerpc: VAS API

 Documentation/powerpc/index.rst|1 +
 Documentation/powerpc/vas-api.rst  |  246 +
 Documentation/userspace-api/ioctl/ioctl-number.rst |1 +
 arch/powerpc/include/asm/vas.h |   12 +-
 arch/powerpc/include/uapi/asm/vas-api.h|   22 +
 arch/powerpc/platforms/powernv/Makefile|2 +-
 arch/powerpc/platforms/powernv/vas-api.c   |  290 +
 arch/powerpc/platforms/powernv/vas-window.c|   23 +-
 arch/powerpc/platforms/powernv/vas.h   |2 +
 drivers/crypto/nx/Makefile |2 +-
 drivers/crypto/nx/nx-842-powernv.c | 1062 --
 drivers/crypto/nx/nx-common-powernv.c  | 1133 
 12 files changed, 1723 insertions(+), 1073 deletions(-)
 create mode 100644 Documentation/powerpc/vas-api.rst
 create mode 100644 arch/powerpc/include/uapi/asm/vas-api.h
 create mode 100644 arch/powerpc/platforms/powernv/vas-api.c
 delete mode 100644 drivers/crypto/nx/nx-842-powernv.c
 create mode 100644 drivers/crypto/nx/nx-common-powernv.c

-- 
1.8.3.1

[PATCH v3 0/9]

[Sam Bobroff]

Hi all,

Here is v3, addressing feedback from v2 to do with debug logging.

It includes a new patch from Oliver O'Halloran (patch 7) and two additional
patches based on it. See those patches for details.

Cover letter:

This patch set adds support for EEH recovery of hot plugged devices on pSeries
machines. Specifically, devices discovered by PCI rescanning using
/sys/bus/pci/rescan, which includes devices hotplugged by QEMU's device_add
command. (Upstream Linux pSeries guests running under QEMU/KVM don't currently
use slot power control for hotplugging.)

As a side effect this also provides EEH support for devices removed by
/sys/bus/pci/devices/*/remove and re-discovered by writing to 
/sys/bus/pci/rescan,
on all platforms.

The approach I've taken is to use the fact that the existing
pcibios_bus_add_device() platform hooks (which are used to set up EEH on
Virtual Function devices (VFs)) are actually called for all devices, so I've
widened their scope and made other adjustments necessary to allow them to work
for hotplugged and boot-time devices as well.

Because some of the changes are in generic PowerPC code, it's
possible that I've disturbed something for another PowerPC platform. I've tried
to minimize this by leaving that code alone as much as possible and so there
are a few cases where eeh_add_device_{early,late}() or eeh_add_sysfs_files() is
called more than once. I think these can be looked at later, as duplicate calls
are not harmful.

The first patch is a rework of the pcibios_init reordering patch I posted
earlier, which I've included here because it's necessary for this set.

I have done some testing for PowerNV on Power9 using a modified pnv_php module
and some testing on pSeries with slot power control using a modified rpaphp
module, and the EEH-related parts seem to work.

Cheers,
Sam.

Patch set changelog follows:

Patch set v3: 
Patch 1/9: powerpc/64: Adjust order in pcibios_init()
Patch 2/9: powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag
Patch 3/9: powerpc/eeh: Improve debug messages around device addition
Patch 4/9: powerpc/eeh: Initialize EEH address cache earlier
Patch 5/9: powerpc/eeh: EEH for pSeries hot plug
Patch 6/9: powerpc/eeh: Refactor around eeh_probe_devices()
Patch 7/9 (new in this version): powerpc/eeh: Add bdfn field to eeh_dev
Patch 8/9 (new in this version): powerpc/eeh: Introduce EEH edev logging macros
Patch 9/9 (new in this version): powerpc/eeh: Convert log messages to 
eeh_edev_* macros

Patch set v2: 
Patch 1/6: powerpc/64: Adjust order in pcibios_init()
Patch 2/6: powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag
* Also clear EEH_DEV_NO_HANDLER in eeh_handle_special_event().
Patch 3/6 (was 4/8): powerpc/eeh: Improve debug messages around device addition
Patch 4/6 (was 6/8): powerpc/eeh: Initialize EEH address cache earlier
Patch 5/6 (was 3/8 and 7/8): powerpc/eeh: EEH for pSeries hot plug
- Dropped changes to the PowerNV PHB EEH flag, instead refactor just enough to
  use the existing flag from multiple places.
- Merge the little remaining work from the above change into the patch where
  it's used.
Patch 6/6 (was 5/8 and 8/8): powerpc/eeh: Refactor around eeh_probe_devices()
- As it's so small, merged the enablement message patch into this one (where 
it's used).
- Reworked enablement messages.

Patch set v1:
Patch 1/8: powerpc/64: Adjust order in pcibios_init()
Patch 2/8: powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag
Patch 3/8: powerpc/eeh: Convert PNV_PHB_FLAG_EEH to global flag
Patch 4/8: powerpc/eeh: Improve debug messages around device addition
Patch 5/8: powerpc/eeh: Add eeh_show_enabled()
Patch 6/8: powerpc/eeh: Initialize EEH address cache earlier
Patch 7/8: powerpc/eeh: EEH for pSeries hot plug
Patch 8/8: powerpc/eeh: Remove eeh_probe_devices() and eeh_addr_cache_build()

Oliver O'Halloran (1):
  powerpc/eeh: Add bdfn field to eeh_dev

Sam Bobroff (8):
  powerpc/64: Adjust order in pcibios_init()
  powerpc/eeh: Clear stale EEH_DEV_NO_HANDLER flag
  powerpc/eeh: Improve debug messages around device addition
  powerpc/eeh: Initialize EEH address cache earlier
  powerpc/eeh: EEH for pSeries hot plug
  powerpc/eeh: Refactor around eeh_probe_devices()
  powerpc/eeh: Introduce EEH edev logging macros
  powerpc/eeh: Convert log messages to eeh_edev_* macros

 arch/powerpc/include/asm/eeh.h   | 21 --
 arch/powerpc/include/asm/ppc-pci.h   |  7 +-
 arch/powerpc/kernel/eeh.c| 50 ++
 arch/powerpc/kernel/eeh_cache.c  | 37 ++-
 arch/powerpc/kernel/eeh_dev.c|  2 +
 arch/powerpc/kernel/eeh_driver.c | 32 -
 arch/powerpc/kernel/eeh_pe.c | 51 ---
 arch/powerpc/kernel/of_platform.c|  3 +-
 arch/powerpc/kernel/pci-common.c |  4 --
 arch/powerpc/kernel/pci_32.c |  4 ++
 arch/powerpc/kernel/pci_64.c | 12 +++-
 arch/powerpc/platforms/powernv/eeh-powernv.c | 56 +---
 

[PATCH v3 0/9] Provide vcpu dispatch statistics

[Naveen N. Rao]

Changes since v2:
- Moved most prototypes to asm/lppaca.h instead of asm/plpar_wrappers.h
- Patch 4/9 changed to use rwlocks for guarding DTL buffer usage across 
  debugfs and the new vcpudispatch_stats.
- Patch 6/9 has been updated to address breakage of the vphn selftest 
  under tools/testing/selftests/powerpc/vphn.
- Patch 7/9 has changes to accommodate use of rwlocks, as well as some 
  simplification for locking while enabling/disabling statistics.

Changes since v1:
- Changes have been done primarily to address a few build issues, by 
  moving changes out of mm/numa.c to other places.
- Patches 1-5,8-9 have been rebased with patches 4 and 5 being 
  interchanged, and patch 4 incorporating #ifdef CONFIG_PPC_SPLPAR.
- Patch 6 is new and moves vphn code under pseries.
- Patch 7 has changes to move most of the code from mm/numa.c into 
  platforms/pseries/lpar.c, along with guarding some of these under 
  CONFIG_PPC_SPLPAR. 

Changes since RFC:
- Patches 1/8 to 5/8: no changes, except rebase to powerpc/merge
- Patch 6/8: The mutex guarding the vphn hcall has been dropped. It was 
  only meant to serialize hcalls issued when stats are initially 
  enabled.  However, in reality, the various per-cpu workers will be 
  scheduled at slightly different times and chances of hcalls for 
  retrieving the same associativity information at the same time is very 
  less. Even in that case, there are no other side effects.
- Patch 6/8: The third column for vcpu dispatches on the same core, but 
  different thread has been dropped and merged with the second column.  
- Patch 7/8: new patch to ensure we don't take too much time while 
  enabling/disabling statistics on large systems with heavy workload.
- Patch 8/8: new patch adding a document describing the fields in the 
  procfs file.

--
This series adds a new procfs file /proc/powerpc/vcpudispatch_stats for 
providing statistics around how the LPAR processors are dispatched by 
the POWER Hypervisor, in a shared LPAR environment. Patch 7/9 has more 
details on how the statistics are gathered.

An example output:
$ sudo cat /proc/powerpc/vcpudispatch_stats
cpu0 6839 4126 2683 30 0 6821 18 0
cpu1 2515 1274 1229 12 0 2509 6 0
cpu2 2317 1198 1109 10 0 2312 5 0
cpu3 2259 1165 1088 6 0 2256 3 0
cpu4 2205 1143 1056 6 0 2202 3 0
cpu5 2165 1121 1038 6 0 2162 3 0
cpu6 2183 1127 1050 6 0 2180 3 0
cpu7 2193 1133 1052 8 0 2187 6 0
cpu8 2165 1115 1032 18 0 2156 9 0
cpu9 2301 1252 1033 16 0 2293 8 0
cpu10 2197 1138 1041 18 0 2187 10 0
cpu11 2273 1185 1062 26 0 2260 13 0
cpu12 2186 1125 1043 18 0 2177 9 0
cpu13 2161 1115 1030 16 0 2153 8 0
cpu14 2206 1153 1033 20 0 2196 10 0
cpu15 2163 1115 1032 16 0 2155 8 0

In the output above, for vcpu0, there have been 6839 dispatches since
statistics were enabled. 4126 of those dispatches were on the same
physical cpu as the last time. 2683 were on a different core, but within
the same chip, while 30 dispatches were on a different chip compared to
its last dispatch.

Also, out of the total of 6839 dispatches, we see that there have been
6821 dispatches on the vcpu's home node, while 18 dispatches were
outside its home node, on a neighbouring chip.


- Naveen

Naveen N. Rao (9):
  powerpc/pseries: Use macros for referring to the DTL enable mask
  powerpc/pseries: Do not save the previous DTL mask value
  powerpc/pseries: Factor out DTL buffer allocation and registration
routines
  powerpc/pseries: Introduce rwlock to gatekeep DTLB usage
  powerpc/pseries: Generalize hcall_vphn()
  powerpc/pseries: Move mm/book3s64/vphn.c under platforms/pseries/
  powerpc/pseries: Provide vcpu dispatch statistics
  powerpc/pseries: Protect against hogging the cpu while setting up the
stats
  powerpc/pseries: Add documentation for vcpudispatch_stats

 Documentation/powerpc/vcpudispatch_stats.txt  |  68 ++
 arch/powerpc/include/asm/lppaca.h |  40 ++
 arch/powerpc/include/asm/topology.h   |   6 +
 arch/powerpc/mm/book3s64/Makefile |   1 -
 arch/powerpc/mm/book3s64/vphn.h   |  16 -
 arch/powerpc/mm/numa.c|  35 +-
 arch/powerpc/platforms/pseries/Makefile   |   1 +
 arch/powerpc/platforms/pseries/dtl.c  |  23 +-
 arch/powerpc/platforms/pseries/lpar.c | 602 +-
 arch/powerpc/platforms/pseries/setup.c|  34 +-
 .../{mm/book3s64 => platforms/pseries}/vphn.c |  20 +-
 tools/testing/selftests/powerpc/vphn/Makefile |   2 +-
 .../selftests/powerpc/vphn/asm/lppaca.h   |   1 +
 tools/testing/selftests/powerpc/vphn/vphn.c   |   2 +-
 tools/testing/selftests/powerpc/vphn/vphn.h   |   1 -
 15 files changed, 752 insertions(+), 100 deletions(-)
 create mode 100644 Documentation/powerpc/vcpudispatch_stats.txt
 delete mode 100644 arch/powerpc/mm/book3s64/vphn.h
 rename arch/powerpc/{mm/book3s64 => platforms/pseries}/vphn.c (80%)
 create mode 12 

[PATCH v3 0/9] kvmppc: Paravirtualize KVM to support ultravisor

[Claudio Carvalho]

POWER platforms that supports the Protected Execution Facility (PEF)
introduce features that combine hardware facilities and firmware to
enable secure virtual machines. That includes a new processor mode
(ultravisor mode) and the ultravisor firmware.

In PEF enabled systems, the ultravisor firmware runs at a privilege
level above the hypervisor and also takes control over some system
resources. The hypervisor, though, can make system calls to access these
resources. Such system calls, a.k.a. ucalls, are handled by the
ultravisor firmware.

The processor allows part of the system memory to be configured as
secure memory, and introduces a a new mode, called secure mode, where
any software entity in that mode can access secure memory. The
hypervisor doesn't (and can't) run in secure mode, but a secure guest
and the ultravisor firmware do.

This patch set adds support for ultravisor calls and do some preparation
for running secure guests.

---
Changelog:
---
v2->v3:
 - Squashed patches:
 "[PATCH v2 08/10] KVM: PPC: Ultravisor: Return to UV for hcalls from SVM"
 "[PATCH v2 09/10] KVM: PPC: Book3S HV: Fixed for running secure guests"
 - Renamed patch from/to:
 "[PATCH v2 08/10] KVM: PPC: Ultravisor: Return to UV for hcalls from SVM"
 "[PATCH v3 08/09] KVM: PPC: Ultravisor: Enter a secure guest
 - Rebased
 - Addressed comments from Paul Mackerras
 - Dropped ultravisor checks made in power8 code
 - Updated the commit message for:
 "[PATCH v3 08/09] KVM: PPC: Ultravisor: Enter a secure guest"
 - Addressed comments from Maddy
 - Dropped imc-pmu.c changes
 - Changed opal-imc.c to fail the probe when the ultravisor is enabled
 - Fixed "ucall defined but not used" issue when CONFIG_PPC_UV not set 

v1->v2:
 - Addressed comments from Paul Mackerras:
 - Write the pate in HV's table before doing that in UV's
 - Renamed and better documented the ultravisor header files. Also added
   all possible return codes for each ucall
 - Updated the commit message that introduces the MSR_S bit 
 - Moved ultravisor.c and ucall.S to arch/powerpc/kernel
 - Changed ucall.S to not save CR
 - Rebased
 - Changed the patches order
 - Updated several commit messages
 - Added FW_FEATURE_ULTRAVISOR to enable use of firmware_has_feature()
 - Renamed CONFIG_PPC_KVM_UV to CONFIG_PPC_UV and used it to ifdef the ucall
   handler and the code that populates the powerpc_firmware_features for 
   ultravisor
 - Exported the ucall symbol. KVM may be built as module.
 - Restricted LDBAR access if the ultravisor firmware is available
 - Dropped patches:
 "[PATCH 06/13] KVM: PPC: Ultravisor: UV_RESTRICTED_SPR_WRITE ucall"
 "[PATCH 07/13] KVM: PPC: Ultravisor: UV_RESTRICTED_SPR_READ ucall"
 "[PATCH 08/13] KVM: PPC: Ultravisor: fix mtspr and mfspr"
 - Squashed patches:
 "[PATCH 09/13] KVM: PPC: Ultravisor: Return to UV for hcalls from SVM"
 "[PATCH 13/13] KVM: PPC: UV: Have fast_guest_return check secure_guest"

Anshuman Khandual (1):
  KVM: PPC: Ultravisor: Add PPC_UV config option

Claudio Carvalho (2):
  powerpc: Introduce FW_FEATURE_ULTRAVISOR
  KVM: PPC: Ultravisor: Restrict LDBAR access

Michael Anderson (2):
  KVM: PPC: Ultravisor: Use UV_WRITE_PATE ucall to register a PATE
  KVM: PPC: Ultravisor: Check for MSR_S during hv_reset_msr

Ram Pai (2):
  KVM: PPC: Ultravisor: Add generic ultravisor call handler
  KVM: PPC: Ultravisor: Restrict flush of the partition tlb cache

Sukadev Bhattiprolu (2):
  KVM: PPC: Ultravisor: Introduce the MSR_S bit
  KVM: PPC: Ultravisor: Enter a secure guest

 arch/powerpc/Kconfig  | 20 +++
 arch/powerpc/include/asm/firmware.h   |  5 +-
 arch/powerpc/include/asm/kvm_host.h   |  1 +
 arch/powerpc/include/asm/reg.h|  3 ++
 arch/powerpc/include/asm/ultravisor-api.h | 24 +
 arch/powerpc/include/asm/ultravisor.h | 49 +
 arch/powerpc/kernel/Makefile  |  1 +
 arch/powerpc/kernel/asm-offsets.c |  1 +
 arch/powerpc/kernel/prom.c|  6 +++
 arch/powerpc/kernel/ucall.S   | 31 +++
 arch/powerpc/kernel/ultravisor.c  | 28 ++
 arch/powerpc/kvm/book3s_64_mmu_hv.c   |  1 +
 arch/powerpc/kvm/book3s_hv_rmhandlers.S   | 39 +++---
 arch/powerpc/mm/book3s64/hash_utils.c |  3 +-
 arch/powerpc/mm/book3s64/pgtable.c| 65 +--
 arch/powerpc/mm/book3s64/radix_pgtable.c  |  9 ++--
 arch/powerpc/platforms/powernv/idle.c |  6 ++-
 arch/powerpc/platforms/powernv/opal-imc.c |  7 +++
 18 files changed, 269 insertions(+), 30 deletions(-)
 create mode 100644 arch/powerpc/include/asm/ultravisor-api.h
 create mode 100644 arch/powerpc/include/asm/ultravisor.h
 create mode 100644 arch/powerpc/kernel/ucall.S
 create mode 100644 arch/powerpc/kernel/ultravisor.c

-- 
2.20.1

[PATCH v3 0/9] Devicetree build consolidation

[Rob Herring]

This series addresses a couple of issues I have with building dts files.

First, the ability to build all the dts files in the tree. This has been
supported on most arches for some time with powerpc being the main
exception. The reason powerpc wasn't supported was it needed a change
in the location built dtb files are put.

Secondly, it's a pain to acquire all the cross-compilers needed to build
dtbs for each arch. There's no reason to build with the cross compiler and
the host compiler is perfectly fine as we only need the pre-processor.

I started addressing just those 2 problems, but kept finding small
differences such as target dependencies and dtbs_install support across
architectures. Instead of trying to align all these, I've consolidated the
build targets moving them out of the arch makefiles.

I'd like to take the series via the DT tree.

Rob

v3:
 - Rework dtc dependency to avoid 2 entry paths to scripts/dtc/. Essentially,
   I copied 'scripts_basic'.
 - Add missing scripts_basic dependency for dtc and missing PHONY tag.
 - Drop the '|' order only from dependencies
 - Drop %.dtb.S and %.dtb.o as top-level targets
 - PPC: remove duplicate mpc5200 dtbs from image-y targets

v2:
 - Fix $arch/boot/dts path check for out of tree builds
 - Fix dtc dependency for building built-in dtbs
 - Fix microblaze built-in dtb building
 - Add dtbs target for microblaze

Rob Herring (9):
  powerpc: build .dtb files in dts directory
  nios2: build .dtb files in dts directory
  nios2: use common rules to build built-in dtb
  nios2: fix building all dtbs
  c6x: use common built-in dtb support
  kbuild: consolidate Devicetree dtb build rules
  powerpc: enable building all dtbs
  c6x: enable building all dtbs
  microblaze: enable building all dtbs

 Makefile   | 35 ++-
 arch/arc/Makefile  |  6 
 arch/arm/Makefile  | 20 +--
 arch/arm64/Makefile| 17 +
 arch/c6x/Makefile  |  2 --
 arch/c6x/boot/dts/Makefile | 17 -
 arch/c6x/boot/dts/linked_dtb.S |  2 --
 arch/c6x/include/asm/sections.h|  1 -
 arch/c6x/kernel/setup.c|  4 +--
 arch/c6x/kernel/vmlinux.lds.S  | 10 --
 arch/h8300/Makefile| 11 +-
 arch/microblaze/Makefile   |  4 +--
 arch/microblaze/boot/dts/Makefile  |  4 +++
 arch/mips/Makefile | 15 +---
 arch/nds32/Makefile|  2 +-
 arch/nios2/Makefile| 11 +-
 arch/nios2/boot/Makefile   | 22 
 arch/nios2/boot/dts/Makefile   |  6 
 arch/nios2/boot/linked_dtb.S   | 19 ---
 arch/powerpc/Makefile  |  3 --
 arch/powerpc/boot/Makefile | 55 ++
 arch/powerpc/boot/dts/Makefile |  6 
 arch/powerpc/boot/dts/fsl/Makefile |  4 +++
 arch/xtensa/Makefile   | 12 +--
 scripts/Makefile   |  3 +-
 scripts/Makefile.lib   |  2 +-
 scripts/dtc/Makefile   |  2 +-
 27 files changed, 100 insertions(+), 195 deletions(-)
 delete mode 100644 arch/c6x/boot/dts/linked_dtb.S
 create mode 100644 arch/nios2/boot/dts/Makefile
 delete mode 100644 arch/nios2/boot/linked_dtb.S
 create mode 100644 arch/powerpc/boot/dts/Makefile
 create mode 100644 arch/powerpc/boot/dts/fsl/Makefile

--
2.17.1

[PATCH v3 0/9] powerpc: Modernize unhandled signals message

[Murilo Opsfelder Araujo]

Hi, everyone.

This series was inspired by the need to modernize and display more
informative messages about unhandled signals.

The "unhandled signal NN" is not very informative.  We thought it would be
helpful adding a human-readable message describing what the signal number
means, printing the VMA address, and dumping the instructions.

Before this series:

  pandafault32[4724]: unhandled signal 11 at 15e4 nip 1444 lr 0fe31ef4 
code 2

  pandafault64[4725]: unhandled signal 11 at 1718 nip 
1574 lr 7fff7faa7a6c code 2

After this series:

  pandafault32[4753]: segfault (11) at 15e4 nip 1444 lr fe31ef4 code 2 
in pandafault32[1000+1]
  pandafault32[4753]: code: 4b3c 6000 6042 4b30 9421ffd0 
93e1002c 7c3f0b78 3d201000
  pandafault32[4753]: code: 392905e4 913f0008 813f0008 39400048 <9949> 
3920 7d234b78 397f0030

  pandafault64[4754]: segfault (11) at 1718 nip 1574 lr 7fffb0007a6c 
code 2 in pandafault64[1000+1]
  pandafault64[4754]: code: e8010010 7c0803a6 4bfffef4 4bfffef0 fbe1fff8 
f821ffb1 7c3f0b78 3d22fffe
  pandafault64[4754]: code: 39298818 f93f0030 e93f0030 39400048 <9949> 
3920 7d234b78 383f0050

Link to v2:

  https://lore.kernel.org/lkml/20180727145811.12334-1-muri...@linux.ibm.com/

v2..v3:

  - Dropped patch 3
  - Updated patch 4 to use %lx

Cheers!

Murilo Opsfelder Araujo (9):
  powerpc/traps: Print unhandled signals in a separate function
  powerpc/traps: Return early in show_signal_msg()
  powerpc/traps: Use %lx format in show_signal_msg()
  powerpc/traps: Print VMA for unhandled signals
  powerpc/traps: Print signal name for unhandled signals
  powerpc: Do not call __kernel_text_address() in show_instructions()
  powerpc: Add stacktrace.h header
  powerpc/traps: Show instructions on exceptions
  powerpc/traps: Add line prefix in show_instructions()

 arch/powerpc/include/asm/stacktrace.h | 13 +
 arch/powerpc/kernel/process.c | 13 +++--
 arch/powerpc/kernel/traps.c   | 72 +++
 3 files changed, 83 insertions(+), 15 deletions(-)
 create mode 100644 arch/powerpc/include/asm/stacktrace.h

-- 
2.17.1

[PATCH v3 0/9] powerpc/pkeys: fixes to pkeys

[Ram Pai]

Assortment of fixes to pkey to match its behavior to that on x86.

Patch 1  makes pkey consumable in multithreaded applications.

Patch 2  Deny, by default, permissions on all unallocated keys.

Patch 3  pkey allocation/free must not change pkey registers.

Patch 4  fixes fork to inherit the key attributes.

Patch 5  A off-by-one bug made one key unusable. Fixes it.

Patch 6  Makes pkey-0 less special.

Patch 7 fix to core-pkeys selftest to capture the modified behavior

Patch 8 fix to ptrace-pkeys selftest to capture the modified behavior

The above patch series is successfully verified using pkey selftests,
on both powerpc and x86.

Ram Pai (9):
  powerpc/pkeys: Give all threads control of their key permissions
  powerpc/pkeys: Deny read/write/execute by default
  powerpc/pkeys: key allocation/deallocation must not change pkey
registers
  powerpc/pkeys: Save the pkey registers before fork
  powerpc/pkeys: fix calculation of total pkeys.
  powerpc/pkeys: Preallocate execute-only key
  powerpc/pkeys: make protection key 0 less special
  powerpc/core-pkeys: execute-permission on keys are disabled by
default
  powerpc/ptrace-pkeys: execute-permission on keys are disabled by
default

 arch/powerpc/include/asm/pkeys.h   |   40 +++---
 arch/powerpc/kernel/process.c  |1 +
 arch/powerpc/mm/pkeys.c|  141 +++-
 tools/testing/selftests/powerpc/ptrace/core-pkey.c |4 +
 .../testing/selftests/powerpc/ptrace/ptrace-pkey.c |5 +
 5 files changed, 79 insertions(+), 112 deletions(-)

Re: [PATCH V3 0/9] powerpc: Support for ibm,dynamic-memory-v2

[Michael Ellerman]

Tyrel Datwyler  writes:

> On 12/03/2017 09:13 PM, Michael Ellerman wrote:
>> Nathan Fontenot  writes:
>> 
>>> This patch set provides a series of updates to de-couple the LMB
>>> information provided in the device tree property from the device
>>> tree property format. This eases the ability to support a new
>>> format for the dynamic memory property, ibm,dynamic-memory-v2.
>> 
>> Something in here is still blowing up for me in a KVM guest:
>
> So, it looks like this series was applied despite observing this KVM
> guest crash.

The crash has gone away for me, I do that KVM guest test on every push.

So I applied the series, but yeah you're right that was probably silly
of me.

cheers

Re: [PATCH V3 0/9] powerpc: Support for ibm,dynamic-memory-v2

[Nathan Fontenot]

On 02/14/2018 03:30 PM, Tyrel Datwyler wrote:
> On 12/03/2017 09:13 PM, Michael Ellerman wrote:
>> Nathan Fontenot  writes:
>>
>>> This patch set provides a series of updates to de-couple the LMB
>>> information provided in the device tree property from the device
>>> tree property format. This eases the ability to support a new
>>> format for the dynamic memory property, ibm,dynamic-memory-v2.
>>
>> Something in here is still blowing up for me in a KVM guest:
> 
> So, it looks like this series was applied despite observing this KVM guest 
> crash. Cyril posted yesterday to the list about hitting this same issue with 
> 4.16-rc1.
> 
> -Tyrel
> 

Yes, Michael pointed out that he hit this on his system but I have never
been able to replicate this error.

Now that others are seeing it any help I could get on re-creating the failure
would be appreciated.

-Nathan

>>
>> OF stdout device is: /vdevice/vty@7100
>> Preparing to boot Linux version 4.14.0-rc2-gcc6x-g9e1fc7e 
>> (kerkins@alpine1-p1) (gcc version 6.4.1 20171202 (Custom 6328ca9eaa476138)) 
>> #1 SMP Sun Dec 3 21:45:32 AEDT 2017
>> Detected machine type: 0101
>> command line: 
>> Max number of cores passed to firmware: 256 (NR_CPUS = 2048)
>> Calling ibm,client-architecture-support... done
>> memory layout at init:
>>   memory_limit :  (16 MB aligned)
>>   alloc_bottom : 015c
>>   alloc_top: 3000
>>   alloc_top_hi : 0001
>>   rmo_top  : 3000
>>   ram_top  : 0001
>> instantiating rtas at 0x2fff... done
>> prom_hold_cpus: skipped
>> copying OF device tree...
>> Building dt strings...
>> Building dt structure...
>> Device tree strings 0x017d -> 0x017d09d8
>> Device tree struct  0x017e -> 0x017f
>> Quiescing Open Firmware ...
>> Booting Linux via __start() @ 0x0040 ...
>> [0.00] bootconsole [udbg0] enabled
>> [0.00] Allocated 2883584 bytes for 2048 pacas at cfd4
>> [0.00] hash-mmu: Page sizes from device-tree:
>> [0.00] hash-mmu: base_shift=12: shift=12, sllp=0x, 
>> avpnm=0x, tlbiel=1, penc=0
>> [0.00] hash-mmu: base_shift=16: shift=16, sllp=0x0110, 
>> avpnm=0x, tlbiel=1, penc=1
>> [0.00]  -> fw_vec5_feature_init()
>> [0.00]  <- fw_vec5_feature_init()
>> [0.00]  -> fw_hypertas_feature_init()
>> [0.00]  <- fw_hypertas_feature_init()
>> [0.00] Page orders: linear mapping = 16, virtual = 16, io = 16, 
>> vmemmap = 16
>> [0.00] Using 1TB segments
>> [0.00] hash-mmu: Initializing hash mmu with SLB
>> [0.00] Linux version 4.14.0-rc2-gcc6x-g9e1fc7e 
>> (kerkins@alpine1-p1) (gcc version 6.4.1 20171202 (Custom 6328ca9eaa476138)) 
>> #1 SMP Sun Dec 3 21:45:32 AEDT 2017
>> [0.00] Found initrd at 0xc15c:0xc178d70b
>> [0.00] Machine is LPAR !
>> [0.00]  -> pseries_init()
>> [0.00]  -> fw_cmo_feature_init()
>> [0.00] CMO not available
>> [0.00]  <- fw_cmo_feature_init()
>> [0.00]  <- pseries_init()
>> [0.00] Using pSeries machine description
>> [0.00] Partition configured for 16 cpus.
>> [0.00] CPU maps initialized for 8 threads per core
>> [0.00]  (thread shift is 3)
>> [0.00] Freed 2818048 bytes for unused pacas
>> [0.00] -
>> [0.00] ppc64_pft_size= 0x19
>> [0.00] phys_mem_size = 0x1
>> [0.00] dcache_bsize  = 0x80
>> [0.00] icache_bsize  = 0x80
>> [0.00] cpu_features  = 0x17dc7aec18500249
>> [0.00]   possible= 0xdfdf18500649
>> [0.00]   always  = 0x18100040
>> [0.00] cpu_user_features = 0xdc0065c2 0xef00
>> [0.00] mmu_features  = 0x78006001
>> [0.00] firmware_features = 0x0001405a440b
>> [0.00] htab_hash_mask= 0x3
>> [0.00] -
>> [0.00] numa:   NODE_DATA [mem 0xfff6a300-0xfff73fff]
>> [0.00]  -> smp_init_pSeries()
>> [0.00]  <- smp_init_pSeries()
>> [0.00] PCI host bridge /pci@8002000  ranges:
>> [0.00]   IO 0x01008000..0x01008000 -> 
>> 0x
>> [0.00]  MEM 0x0100a000..0x01101fff -> 
>> 0x8000 
>> [0.00] PPC64 nvram contains 65536 bytes
>> [0.00] Top of RAM: 0x1, Total RAM: 0x1
>> [0.00] Memory hole size: 0MB
>> [

Re: [PATCH V3 0/9] powerpc: Support for ibm,dynamic-memory-v2

[Tyrel Datwyler]

On 12/03/2017 09:13 PM, Michael Ellerman wrote:
> Nathan Fontenot  writes:
> 
>> This patch set provides a series of updates to de-couple the LMB
>> information provided in the device tree property from the device
>> tree property format. This eases the ability to support a new
>> format for the dynamic memory property, ibm,dynamic-memory-v2.
> 
> Something in here is still blowing up for me in a KVM guest:

So, it looks like this series was applied despite observing this KVM guest 
crash. Cyril posted yesterday to the list about hitting this same issue with 
4.16-rc1.

-Tyrel

> 
> OF stdout device is: /vdevice/vty@7100
> Preparing to boot Linux version 4.14.0-rc2-gcc6x-g9e1fc7e 
> (kerkins@alpine1-p1) (gcc version 6.4.1 20171202 (Custom 6328ca9eaa476138)) 
> #1 SMP Sun Dec 3 21:45:32 AEDT 2017
> Detected machine type: 0101
> command line: 
> Max number of cores passed to firmware: 256 (NR_CPUS = 2048)
> Calling ibm,client-architecture-support... done
> memory layout at init:
>   memory_limit :  (16 MB aligned)
>   alloc_bottom : 015c
>   alloc_top: 3000
>   alloc_top_hi : 0001
>   rmo_top  : 3000
>   ram_top  : 0001
> instantiating rtas at 0x2fff... done
> prom_hold_cpus: skipped
> copying OF device tree...
> Building dt strings...
> Building dt structure...
> Device tree strings 0x017d -> 0x017d09d8
> Device tree struct  0x017e -> 0x017f
> Quiescing Open Firmware ...
> Booting Linux via __start() @ 0x0040 ...
> [0.00] bootconsole [udbg0] enabled
> [0.00] Allocated 2883584 bytes for 2048 pacas at cfd4
> [0.00] hash-mmu: Page sizes from device-tree:
> [0.00] hash-mmu: base_shift=12: shift=12, sllp=0x, 
> avpnm=0x, tlbiel=1, penc=0
> [0.00] hash-mmu: base_shift=16: shift=16, sllp=0x0110, 
> avpnm=0x, tlbiel=1, penc=1
> [0.00]  -> fw_vec5_feature_init()
> [0.00]  <- fw_vec5_feature_init()
> [0.00]  -> fw_hypertas_feature_init()
> [0.00]  <- fw_hypertas_feature_init()
> [0.00] Page orders: linear mapping = 16, virtual = 16, io = 16, 
> vmemmap = 16
> [0.00] Using 1TB segments
> [0.00] hash-mmu: Initializing hash mmu with SLB
> [0.00] Linux version 4.14.0-rc2-gcc6x-g9e1fc7e 
> (kerkins@alpine1-p1) (gcc version 6.4.1 20171202 (Custom 6328ca9eaa476138)) 
> #1 SMP Sun Dec 3 21:45:32 AEDT 2017
> [0.00] Found initrd at 0xc15c:0xc178d70b
> [0.00] Machine is LPAR !
> [0.00]  -> pseries_init()
> [0.00]  -> fw_cmo_feature_init()
> [0.00] CMO not available
> [0.00]  <- fw_cmo_feature_init()
> [0.00]  <- pseries_init()
> [0.00] Using pSeries machine description
> [0.00] Partition configured for 16 cpus.
> [0.00] CPU maps initialized for 8 threads per core
> [0.00]  (thread shift is 3)
> [0.00] Freed 2818048 bytes for unused pacas
> [0.00] -
> [0.00] ppc64_pft_size= 0x19
> [0.00] phys_mem_size = 0x1
> [0.00] dcache_bsize  = 0x80
> [0.00] icache_bsize  = 0x80
> [0.00] cpu_features  = 0x17dc7aec18500249
> [0.00]   possible= 0xdfdf18500649
> [0.00]   always  = 0x18100040
> [0.00] cpu_user_features = 0xdc0065c2 0xef00
> [0.00] mmu_features  = 0x78006001
> [0.00] firmware_features = 0x0001405a440b
> [0.00] htab_hash_mask= 0x3
> [0.00] -
> [0.00] numa:   NODE_DATA [mem 0xfff6a300-0xfff73fff]
> [0.00]  -> smp_init_pSeries()
> [0.00]  <- smp_init_pSeries()
> [0.00] PCI host bridge /pci@8002000  ranges:
> [0.00]   IO 0x01008000..0x01008000 -> 
> 0x
> [0.00]  MEM 0x0100a000..0x01101fff -> 
> 0x8000 
> [0.00] PPC64 nvram contains 65536 bytes
> [0.00] Top of RAM: 0x1, Total RAM: 0x1
> [0.00] Memory hole size: 0MB
> [0.00] Zone ranges:
> [0.00]   DMA  [mem 0x-0x]
> [0.00]   DMA32empty
> [0.00]   Normal   empty
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x-0x]
> [

Re: [PATCH V3 0/9] powerpc: Support for ibm,dynamic-memory-v2

[Michael Ellerman]

Nathan Fontenot  writes:

> This patch set provides a series of updates to de-couple the LMB
> information provided in the device tree property from the device
> tree property format. This eases the ability to support a new
> format for the dynamic memory property, ibm,dynamic-memory-v2.

Something in here is still blowing up for me in a KVM guest:

OF stdout device is: /vdevice/vty@7100
Preparing to boot Linux version 4.14.0-rc2-gcc6x-g9e1fc7e 
(kerkins@alpine1-p1) (gcc version 6.4.1 20171202 (Custom 6328ca9eaa476138)) #1 
SMP Sun Dec 3 21:45:32 AEDT 2017
Detected machine type: 0101
command line: 
Max number of cores passed to firmware: 256 (NR_CPUS = 2048)
Calling ibm,client-architecture-support... done
memory layout at init:
  memory_limit :  (16 MB aligned)
  alloc_bottom : 015c
  alloc_top: 3000
  alloc_top_hi : 0001
  rmo_top  : 3000
  ram_top  : 0001
instantiating rtas at 0x2fff... done
prom_hold_cpus: skipped
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x017d -> 0x017d09d8
Device tree struct  0x017e -> 0x017f
Quiescing Open Firmware ...
Booting Linux via __start() @ 0x0040 ...
[0.00] bootconsole [udbg0] enabled
[0.00] Allocated 2883584 bytes for 2048 pacas at cfd4
[0.00] hash-mmu: Page sizes from device-tree:
[0.00] hash-mmu: base_shift=12: shift=12, sllp=0x, 
avpnm=0x, tlbiel=1, penc=0
[0.00] hash-mmu: base_shift=16: shift=16, sllp=0x0110, 
avpnm=0x, tlbiel=1, penc=1
[0.00]  -> fw_vec5_feature_init()
[0.00]  <- fw_vec5_feature_init()
[0.00]  -> fw_hypertas_feature_init()
[0.00]  <- fw_hypertas_feature_init()
[0.00] Page orders: linear mapping = 16, virtual = 16, io = 16, 
vmemmap = 16
[0.00] Using 1TB segments
[0.00] hash-mmu: Initializing hash mmu with SLB
[0.00] Linux version 4.14.0-rc2-gcc6x-g9e1fc7e (kerkins@alpine1-p1) 
(gcc version 6.4.1 20171202 (Custom 6328ca9eaa476138)) #1 SMP Sun Dec 3 
21:45:32 AEDT 2017
[0.00] Found initrd at 0xc15c:0xc178d70b
[0.00] Machine is LPAR !
[0.00]  -> pseries_init()
[0.00]  -> fw_cmo_feature_init()
[0.00] CMO not available
[0.00]  <- fw_cmo_feature_init()
[0.00]  <- pseries_init()
[0.00] Using pSeries machine description
[0.00] Partition configured for 16 cpus.
[0.00] CPU maps initialized for 8 threads per core
[0.00]  (thread shift is 3)
[0.00] Freed 2818048 bytes for unused pacas
[0.00] -
[0.00] ppc64_pft_size= 0x19
[0.00] phys_mem_size = 0x1
[0.00] dcache_bsize  = 0x80
[0.00] icache_bsize  = 0x80
[0.00] cpu_features  = 0x17dc7aec18500249
[0.00]   possible= 0xdfdf18500649
[0.00]   always  = 0x18100040
[0.00] cpu_user_features = 0xdc0065c2 0xef00
[0.00] mmu_features  = 0x78006001
[0.00] firmware_features = 0x0001405a440b
[0.00] htab_hash_mask= 0x3
[0.00] -
[0.00] numa:   NODE_DATA [mem 0xfff6a300-0xfff73fff]
[0.00]  -> smp_init_pSeries()
[0.00]  <- smp_init_pSeries()
[0.00] PCI host bridge /pci@8002000  ranges:
[0.00]   IO 0x01008000..0x01008000 -> 
0x
[0.00]  MEM 0x0100a000..0x01101fff -> 
0x8000 
[0.00] PPC64 nvram contains 65536 bytes
[0.00] Top of RAM: 0x1, Total RAM: 0x1
[0.00] Memory hole size: 0MB
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x-0x]
[0.00]   DMA32empty
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x]
[0.00] Initmem setup node 0 [mem 
0x-0x]
[0.00] On node 0 totalpages: 65536
[0.00]   DMA zone: 64 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 65536 pages, LIFO batch:1
[0.00] percpu: Embedded 4 pages/cpu @c000ffb0 s167064 r0 
d95080 u262144
[0.00] pcpu-alloc: s167064 

[PATCH V3 0/9] powerpc: Support for ibm,dynamic-memory-v2

[Nathan Fontenot]

This patch set provides a series of updates to de-couple the LMB
information provided in the device tree property from the device
tree property format. This eases the ability to support a new
format for the dynamic memory property, ibm,dynamic-memory-v2.

This series of patches consolidates the routines for parsing the
LMB device tree properties into a new file, powerpc/mm/drmem.c,
and provides the ability to retrieve LMB information without having
to know the backing device tree format.

To do this, a set of routines are introduced that will walk the
device tree property and make a call back for each LMB represented
in the device tree. These are to be used by init routines during
boot, currently in prom.c and numa.c.

A late_initcall is used to allocate and initialize a LMB array to
provide a common data structure of per-LMB data. This array provides
a data structure to retrieve LMB information without knowing the
backing tree format. This is used in numa.c and pseries/hotplug-memory.c.

This is a big design change from the first two version of the patch set
that attempted to allocate the LMB array with bootmem very early.
Testing showed that this allocation can fail which pushed the change
to the current design.

To support memory hotplug needing to update the device tree, a
common routine is introduced to create a new copy of the device
tree property in the proper format.

The first three patches update the of_get_assoc_arrays(),
of_get_usable_memory(), and of_drconf_to_nid_single() routines
to do device tree lookups for information they need instead of having
the nodes/properties passed in. These are updates needed for later
changes.

The fourth patch adds the walk_drmem_lmbs_early() routine to provide
parsing of the flattened device tree and make a per-LMB call back,
used in prom.c

The fifth patch provides a walk_drmem_lmbs() routine to parse the
device tree and provide a per-LMB call back, used in numa.c. This
also allocates and initializes the LMB array, and updates numa.c
to use the array.

The sixth patch updates pseries hotplug code new LMB array data 
instead of parsing the device tree directly and introduces the
common routine to create a new device tree property.

The seventh patch moves the of_drconf_cell struct to drmem.h where it
fits better than prom.h

The eighth patch introduces support for the ibm,dynamic-memory-v2
property format by updating the new drmem.c code to be able to parse
and create this new device tree format.

The last patch in the series updates the architecture vector to indicate
support for ibm,dynamic-memory-v2.

-Nathan
---

Nathan Fontenot (9):
  powerpc/numa: Look up device node in of_get_assoc_arrays()
  powerpc/numa: Look up device node in of_get_usable_memory()
  powerpc/numa: Look up associativity array in of_drconf_to_nid_single
  powerpc/mm: Separate ibm,dynamic-memory data from DT format
  powerpc/numa: Update numa code use walk_drmem_lmbs
  powerpc/pseries: Update memory hotplug code to use drmem LMB array
  powerpc: Move of_drconf_cell struct to asm/drmem.h
  powerpc/drmem: Add support for ibm,dynamic-memory-v2 property
  powerpc: Enable support of ibm,dynamic-memory-v2


 arch/powerpc/include/asm/drmem.h|  100 
 arch/powerpc/include/asm/firmware.h |3 
 arch/powerpc/include/asm/prom.h |   17 -
 arch/powerpc/kernel/prom.c  |  114 ++---
 arch/powerpc/kernel/prom_init.c |1 
 arch/powerpc/mm/Makefile|2 
 arch/powerpc/mm/drmem.c |  438 +++
 arch/powerpc/mm/numa.c  |  252 +++
 arch/powerpc/platforms/pseries/firmware.c   |1 
 arch/powerpc/platforms/pseries/hotplug-memory.c |  522 +--
 10 files changed, 864 insertions(+), 586 deletions(-)
 create mode 100644 arch/powerpc/include/asm/drmem.h
 create mode 100644 arch/powerpc/mm/drmem.c

Re: [PATCH V3 0/9] cpufreq: transition-latency cleanups

[Rafael J. Wysocki]

On Wednesday, July 19, 2017 03:42:40 PM Viresh Kumar wrote:
> Hi Rafael,
> 
> This series tries to cleanup the code around transition-latency and its
> users. Some of the old legacy code, which may not make much sense now,
> is dropped as well. And some code consolidation is also done across
> governors.
> 
> Based of: v4.13-rc1
> Tested on: ARM64 Hikey board.

>From the first quick look this version is fine by me.

Unless I find anything of concern later, this will be queued up for 4.14.

Thanks,
Rafael

[PATCH V3 0/9] cpufreq: transition-latency cleanups

[Viresh Kumar]

Hi Rafael,

This series tries to cleanup the code around transition-latency and its
users. Some of the old legacy code, which may not make much sense now,
is dropped as well. And some code consolidation is also done across
governors.

Based of: v4.13-rc1
Tested on: ARM64 Hikey board.

I have pushed it here as well (which gets tested by kbuild test bot):

git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git 
cpufreq/transition-latency

V2->V3:
- Rearranged patches to keep related stuff together
- Introduce CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING flag (Rafael)
- Minor optimization in cpufreq_policy_transition_delay_us() and moved
  it to cpufreq.c (Rafael)
- Allow dynamic switching for drivers which don't know their transition
  latency.

V1->V2:
- While we still get rid of the limitation of 10ms for using
  ondemand/conservative, but we preserve the earlier behavior where the
  transition latency set to CPUFREQ_ETERNAL would not allow use of
  ondemand/conservative governors. Thanks to Dominik for his feedback on
  that.

--
viresh

Viresh Kumar (9):
  cpufreq: governor: Drop min_sampling_rate
  cpufreq: Use transition_delay_us for legacy governors as well
  cpufreq: Cap the default transition delay value to 10 ms
  cpufreq: Don't set transition_latency for setpolicy drivers
  cpufreq: arm_big_little: Make ->get_transition_latency() mandatory
  cpufreq: Replace "max_transition_latency" with "dynamic_switching"
  cpufreq: schedutil: Set dynamic_switching to true
  cpufreq: Add CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING cpufreq driver flag
  cpufreq: Allow dynamic switching with CPUFREQ_ETERNAL latency

 Documentation/admin-guide/pm/cpufreq.rst |  8 
 drivers/cpufreq/arm_big_little.c | 10 --
 drivers/cpufreq/cpufreq-nforce2.c|  2 +-
 drivers/cpufreq/cpufreq.c| 34 
 drivers/cpufreq/cpufreq_conservative.c   |  6 --
 drivers/cpufreq/cpufreq_governor.c   | 17 ++--
 drivers/cpufreq/cpufreq_governor.h   |  3 +--
 drivers/cpufreq/cpufreq_ondemand.c   | 12 ---
 drivers/cpufreq/elanfreq.c   |  4 +---
 drivers/cpufreq/gx-suspmod.c |  2 +-
 drivers/cpufreq/intel_pstate.c   |  1 -
 drivers/cpufreq/longrun.c|  1 -
 drivers/cpufreq/pmac32-cpufreq.c |  7 +--
 drivers/cpufreq/sa1100-cpufreq.c |  5 +++--
 drivers/cpufreq/sa1110-cpufreq.c |  5 +++--
 drivers/cpufreq/sh-cpufreq.c |  3 +--
 drivers/cpufreq/speedstep-smi.c  |  2 +-
 drivers/cpufreq/unicore2-cpufreq.c   |  3 +--
 include/linux/cpufreq.h  | 18 -
 kernel/sched/cpufreq_schedutil.c | 12 ++-
 20 files changed, 65 insertions(+), 90 deletions(-)

-- 
2.13.0.71.gd7076ec9c9cb

[PATCH v3 0/9] Enable STRICT_KERNEL_RWX

[Balbir Singh]

Enable STRICT_KERNEL_RWX for PPC64/BOOK3S

These patches enable RX mappings of kernel text.
rodata is mapped RX as well as a trade-off, there
are more details in the patch description

As a prerequisite for R/O text, patch_instruction
is moved over to using a separate mapping that
allows write to kernel text. xmon/ftrace/kprobes
have been moved over to work with patch_instruction

There is a bug fix, the updatepp and updateboltedpp
(pseries) providers, did not use flags as described in
PAPR

There are patches for 32 bit support from Christophe Leroy
at http://patchwork.ozlabs.org/patch/768257/. The patches
for map_page to map_kernel_page are a pre-requisite to
this series being applied.

Another build failure was reported, because instead
of using ARCH_HAS_SET_MEMORY as a gate for set_memory.h
inclusion, some of the infrastructure in the core kernel
uses CONFIG_STRICT_KERNEL_RWX. I've sent a fix to the
fix the latter.

Changelog v3:
Support radix
Drop ptdump patch, already picked from v2
Changelog v2:
Support optprobes via patch_instruction

Balbir Singh (9):
  powerpc/lib/code-patching: Enhance code patching
  powerpc/kprobes: Move kprobes over to patch_instruction
  powerpc/kprobes/optprobes: Move over to patch_instruction
  powerpc/xmon: Add patch_instruction supporf for xmon
  powerpc/vmlinux.lds: Align __init_begin to 16M
  powerpc/platform/pseries/lpar: Fix updatepp and updateboltedpp
  powerpc/mm/hash: Implement mark_rodata_ro() for hash
  powerpc/Kconfig: Enable STRICT_KERNEL_RWX
  powerpc/mm/radix: Implement mark_rodata_ro() for radix

 arch/powerpc/Kconfig   |   1 +
 arch/powerpc/include/asm/book3s/64/hash.h  |   3 +
 arch/powerpc/include/asm/book3s/64/radix.h |   4 +
 arch/powerpc/kernel/kprobes.c  |   4 +-
 arch/powerpc/kernel/optprobes.c|  58 +++-
 arch/powerpc/kernel/vmlinux.lds.S  |  10 ++-
 arch/powerpc/lib/code-patching.c   | 140 -
 arch/powerpc/mm/pgtable-hash64.c   |  35 
 arch/powerpc/mm/pgtable-radix.c|  73 ++-
 arch/powerpc/mm/pgtable_64.c   |   9 ++
 arch/powerpc/platforms/pseries/lpar.c  |  13 ++-
 arch/powerpc/xmon/xmon.c   |   7 +-
 12 files changed, 323 insertions(+), 34 deletions(-)

-- 
2.9.4

[PATCH v3 0/9] ima: carry the measurement list across kexec

[Mimi Zohar]

The TPM PCRs are only reset on a hard reboot.  In order to validate a
TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list
of the running kernel must be saved and then restored on the subsequent
boot, possibly of a different architecture.

The existing securityfs binary_runtime_measurements file conveniently
provides a serialized format of the IMA measurement list. This patch
set serializes the measurement list in this format and restores it.

Up to now, the binary_runtime_measurements was defined as architecture
native format.  The assumption being that userspace could and would
handle any architecture conversions.  With the ability of carrying the
measurement list across kexec, possibly from one architecture to a
different one, the per boot architecture information is lost and with it
the ability of recalculating the template digest hash.  To resolve this
problem, without breaking the existing ABI, this patch set introduces
the boot command line option "ima_canonical_fmt", which is arbitrarily
defined as little endian.

The need for this boot command line option will be limited to the
existing version 1 format of the binary_runtime_measurements.
Subsequent formats will be defined as canonical format (eg. TPM 2.0
support for larger digests).

This patch set pre-req's Thiago Bauermann's "kexec_file: Add buffer
hand-over for the next kernel" patch set. 

These patches can also be found in the next-kexec-restore branch of:
git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git

Changelog v3:
- Cleaned up the code for calculating the requested kexec segment size
needed for the IMA measurement list, limiting the segment size to half
of the totalram_pages.
- Fixed kernel test robot reports as enumerated in the respective
patch changelog.

Changelog v2:
- Canonical measurement list support added
- Redefined the ima_kexec_hdr struct to use well defined sizes

Mimi

Andreas Steffen (1):
  ima: platform-independent hash value

Mimi Zohar (7):
  ima: on soft reboot, restore the measurement list
  ima: permit duplicate measurement list entries
  ima: maintain memory size needed for serializing the measurement list
  ima: serialize the binary_runtime_measurements
  ima: store the builtin/custom template definitions in a list
  ima: support restoring multiple template formats
  ima: define a canonical binary_runtime_measurements list format

Thiago Jung Bauermann (1):
  ima: on soft reboot, save the measurement list

 Documentation/kernel-parameters.txt   |   4 +
 include/linux/ima.h   |  12 ++
 kernel/kexec_file.c   |   4 +
 security/integrity/ima/Kconfig|  12 ++
 security/integrity/ima/Makefile   |   1 +
 security/integrity/ima/ima.h  |  28 +++
 security/integrity/ima/ima_crypto.c   |   6 +-
 security/integrity/ima/ima_fs.c   |  30 ++-
 security/integrity/ima/ima_init.c |   2 +
 security/integrity/ima/ima_kexec.c| 209 +
 security/integrity/ima/ima_main.c |   1 +
 security/integrity/ima/ima_queue.c|  76 +++-
 security/integrity/ima/ima_template.c | 293 --
 security/integrity/ima/ima_template_lib.c |   7 +-
 14 files changed, 653 insertions(+), 32 deletions(-)
 create mode 100644 security/integrity/ima/ima_kexec.c

-- 
2.1.0

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

[Thiago Jung Bauermann]

Am Freitag, 24 Juni 2016, 08:33:24 schrieb Balbir Singh:
> On 24/06/16 02:44, Thiago Jung Bauermann wrote:
> > Sorry, I still don't understand your concern. What kind of cheating?
> > Which values? If it's the values in the event log, there's no need to
> > trust the old kernel. The new kernel knows that the old kernel didn't
> > pass wrong measurement values in the event log because it can
> > recalculate the PCR extend operations recorded in the log and compare
> > the results of the replay with the current PCR values stored in the TPM
> > device. If they match, then the event log is guaranteed to be correct.
> > If they don't match, either the memory was corrupted somehow during the
> > kexec process, or the old kernel tried to pass a falsified event log.
> 
> Yep, get it/got it. My concern was anything using passed on the values
> should compare the results with the current PCR values.
> 
> BTW, what do we gain by passing the values if we are relying on the PCR
> registers anyway, can't we directly read them off from there? Aren't we
> going to ready anyway to compare, what does passing the values gain?

The PCR values themselves change for reasons that the application/user may 
not care about. For example, just changing the order in which measurements 
are made changes the final value of the PCR, even if all the measurements 
themselves don't change. And in current multi-processor machines this order 
does change at each boot, so you can't rely on two boots of the same machine 
with the same software to have the same PCR values.

Also, you may want to verify only the measurement of one of the components 
and not care about the other components.

With an event log, you can verify the checksum of each measured component 
individually, and the PCR value serves to confirm that the event log is 
correct. Just having the final PCR value without the event log, you don't 
know which measurements were made.

> >> and
> >> 
> >> How do we know the new kernel is safe to load - I guess via a signature
> >> that the new kernel is signed with (assuming it is present in the key
> >> ring).
> > 
> > Correct. That goal is met by signature verification, not by integrity
> > assurance.
> > 
> > I'll note that even with both of my patch series there's still code
> > missing for kernel signature verification in PowerPC. I believe there's
> > not a file format defined yet for how to store a signature in a PowerPC
> > kernel image.
> > 
> > Integrity assurance doesn't depend on kernel signature verification
> > though. There's value in both my patch series even without kernel
> > signature verification support. They're complementary features.
> 
> Thanks for clarifying

Thank you for your interest.

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

[Balbir Singh]

On 24/06/16 02:44, Thiago Jung Bauermann wrote:
> Am Donnerstag, 23 Juni 2016, 09:57:51 schrieb Balbir Singh:
>> On 23/06/16 03:02, Thiago Jung Bauermann wrote:
> 3. have IMA pass-on its event log (where integrity measurements are
>
>registered) accross kexec to the second kernel, so that the event
>history is preserved.

 OK.. and this is safe? Do both the kernels need to be signed by the
 same certificate?
>>>
>>> They don't. The integrity of the event log (assuming that is what you
>>> mean by "this" in "this is safe") is guaranteed by the TPM device. Each
>>> event in the measurement list extends a PCR and records its PCR value.
>>> It is cryptographically guaranteed that if you replay the PCR extends
>>> recorded in the event log and in the end of the process they match the
>>> current PCR values in the TPM device, then that event log is correct.
>>
>> What I meant was how does the new kernel know that the old kernel did not
>> cheat while passing on the values? I presume because we trust that kernel
>> via a signature.
> 
> Sorry, I still don't understand your concern. What kind of cheating? Which 
> values? If it's the values in the event log, there's no need to trust the 
> old kernel. The new kernel knows that the old kernel didn't pass wrong 
> measurement values in the event log because it can recalculate the PCR 
> extend operations recorded in the log and compare the results of the replay 
> with the current PCR values stored in the TPM device. If they match, then 
> the event log is guaranteed to be correct. If they don't match, either the 
> memory was corrupted somehow during the kexec process, or the old kernel 
> tried to pass a falsified event log.
> 

Yep, get it/got it. My concern was anything using passed on the values should
compare the results with the current PCR values.

BTW, what do we gain by passing the values if we are relying on the PCR 
registers
anyway, can't we directly read them off from there? Aren't we going to ready 
anyway
to compare, what does passing the values gain?

[snip]

>> and
>>
>> How do we know the new kernel is safe to load - I guess via a signature
>> that the new kernel is signed with (assuming it is present in the key
>> ring).
> 
> Correct. That goal is met by signature verification, not by integrity 
> assurance.
> 
> I'll note that even with both of my patch series there's still code missing 
> for kernel signature verification in PowerPC. I believe there's not a file 
> format defined yet for how to store a signature in a PowerPC kernel image.
> 
> Integrity assurance doesn't depend on kernel signature verification though. 
> There's value in both my patch series even without kernel signature 
> verification support. They're complementary features.
>  

Thanks for clarifying

Balbir Singh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

[Thiago Jung Bauermann]

Am Donnerstag, 23 Juni 2016, 09:57:51 schrieb Balbir Singh:
> On 23/06/16 03:02, Thiago Jung Bauermann wrote:
> >>> 3. have IMA pass-on its event log (where integrity measurements are
> >>> 
> >>>registered) accross kexec to the second kernel, so that the event
> >>>history is preserved.
> >> 
> >> OK.. and this is safe? Do both the kernels need to be signed by the
> >> same certificate?
> > 
> > They don't. The integrity of the event log (assuming that is what you
> > mean by "this" in "this is safe") is guaranteed by the TPM device. Each
> > event in the measurement list extends a PCR and records its PCR value.
> > It is cryptographically guaranteed that if you replay the PCR extends
> > recorded in the event log and in the end of the process they match the
> > current PCR values in the TPM device, then that event log is correct.
> 
> What I meant was how does the new kernel know that the old kernel did not
> cheat while passing on the values? I presume because we trust that kernel
> via a signature.

Sorry, I still don't understand your concern. What kind of cheating? Which 
values? If it's the values in the event log, there's no need to trust the 
old kernel. The new kernel knows that the old kernel didn't pass wrong 
measurement values in the event log because it can recalculate the PCR 
extend operations recorded in the log and compare the results of the replay 
with the current PCR values stored in the TPM device. If they match, then 
the event log is guaranteed to be correct. If they don't match, either the 
memory was corrupted somehow during the kexec process, or the old kernel 
tried to pass a falsified event log.

There's no known way to construct an alternative series of PCR extend 
operations that will result in the same final value in the PCR register of 
the TPM device. If you can do that, you discovered a hash collision attack 
on the SHA-1 or SHA-256 algorithms (depending on which algorithm is being 
used by IMA in the event log). Or a bug in the TPM device implementation.

> and
> 
> How do we know the new kernel is safe to load - I guess via a signature
> that the new kernel is signed with (assuming it is present in the key
> ring).

Correct. That goal is met by signature verification, not by integrity 
assurance.

I'll note that even with both of my patch series there's still code missing 
for kernel signature verification in PowerPC. I believe there's not a file 
format defined yet for how to store a signature in a PowerPC kernel image.

Integrity assurance doesn't depend on kernel signature verification though. 
There's value in both my patch series even without kernel signature 
verification support. They're complementary features.
 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

[Balbir Singh]

On 23/06/16 03:02, Thiago Jung Bauermann wrote:
> Hello Balbir,
>
Hi Thiago
 
>>> 3. have IMA pass-on its event log (where integrity measurements are
>>>
>>>registered) accross kexec to the second kernel, so that the event
>>>history is preserved.
>>
>> OK.. and this is safe? Do both the kernels need to be signed by the
>> same certificate?
> 
> They don't. The integrity of the event log (assuming that is what you mean 
> by "this" in "this is safe") is guaranteed by the TPM device. Each event in 
> the measurement list extends a PCR and records its PCR value. It is 
> cryptographically guaranteed that if you replay the PCR extends recorded in 
> the event log and in the end of the process they match the current PCR 
> values in the TPM device, then that event log is correct.


What I meant was how does the new kernel know that the old kernel did not
cheat while passing on the values? I presume because we trust that kernel
via a signature.


and

How do we know the new kernel is safe to load - I guess via a signature that
the new kernel is signed with (assuming it is present in the key ring).

Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

[Thiago Jung Bauermann]

Hello Balbir,

Am Mittwoch, 22 Juni 2016, 23:29:46 schrieb Balbir Singh:
> On Tue, 21 Jun 2016 16:48:32 -0300
> Thiago Jung Bauermann  wrote:
> > This patch series implements the kexec_file_load system call on
> > PowerPC.
> > 
> > This system call moves the reading of the kernel, initrd and the
> > device tree from the userspace kexec tool to the kernel. This is
> > needed if you want to do one or both of the following:
> > 
> > 1. only allow loading of signed kernels.
> > 2. "measure" (i.e., record the hashes of) the kernel, initrd, kernel
> > 
> >command line and other boot inputs for the Integrity Measurement
> >Architecture subsystem.
> > 
> > The above are the functions kexec already has built into
> > kexec_file_load. Yesterday I posted a set of patches which allows a
> > third feature:
> > 
> > 3. have IMA pass-on its event log (where integrity measurements are
> > 
> >registered) accross kexec to the second kernel, so that the event
> >history is preserved.
> 
> OK.. and this is safe? Do both the kernels need to be signed by the
> same certificate?

They don't. The integrity of the event log (assuming that is what you mean 
by "this" in "this is safe") is guaranteed by the TPM device. Each event in 
the measurement list extends a PCR and records its PCR value. It is 
cryptographically guaranteed that if you replay the PCR extends recorded in 
the event log and in the end of the process they match the current PCR 
values in the TPM device, then that event log is correct.

The kernel signature serves to ensure that you only run kernels from an 
authorized provider. It doesn't play a role in integrity assurance, which 
aims to verify that the machine is really running the code it says it is 
running. As I understand it, at least. It's a bit subtle and I could be 
missing something...

[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

[Balbir Singh]

On Tue, 21 Jun 2016 16:48:32 -0300
Thiago Jung Bauermann  wrote:

> Hello,
> 
> This patch series implements the kexec_file_load system call on
> PowerPC.
> 
> This system call moves the reading of the kernel, initrd and the
> device tree from the userspace kexec tool to the kernel. This is
> needed if you want to do one or both of the following:
> 
> 1. only allow loading of signed kernels.
> 2. "measure" (i.e., record the hashes of) the kernel, initrd, kernel
>command line and other boot inputs for the Integrity Measurement
>Architecture subsystem.
> 
> The above are the functions kexec already has built into
> kexec_file_load. Yesterday I posted a set of patches which allows a
> third feature:
> 
> 3. have IMA pass-on its event log (where integrity measurements are
>registered) accross kexec to the second kernel, so that the event
>history is preserved.

OK.. and this is safe? Do both the kernels need to be signed by the
same certificate?


Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 0/9] kexec_file_load implementation for PowerPC

[Thiago Jung Bauermann]

Hello,

This patch series implements the kexec_file_load system call on PowerPC.

This system call moves the reading of the kernel, initrd and the device tree
from the userspace kexec tool to the kernel. This is needed if you want to
do one or both of the following:

1. only allow loading of signed kernels.
2. "measure" (i.e., record the hashes of) the kernel, initrd, kernel
   command line and other boot inputs for the Integrity Measurement
   Architecture subsystem.

The above are the functions kexec already has built into kexec_file_load.
Yesterday I posted a set of patches which allows a third feature:

3. have IMA pass-on its event log (where integrity measurements are
   registered) accross kexec to the second kernel, so that the event
   history is preserved.

Because OpenPower uses an intermediary Linux instance as a boot loader
(skiroot), feature 1 is needed to implement secure boot for the platform,
while features 2 and 3 are needed to implement trusted boot.

This patch series starts by removing an x86 assumption from kexec_file:
kexec_add_buffer uses iomem to find reserved memory ranges, but PowerPC
uses the memblock subsystem.  A hook is added so that each arch can
specify how memory ranges can be found.

Also, the memory-walking logic in kexec_add_buffer is useful in this
implementation to find a free area for the purgatory's stack, so the
next patch moves that logic to kexec_locate_mem_hole.

The kexec_file_load system call needs to apply relocations to the
purgatory but adding code for that would duplicate functionality with
the module loading mechanism, which also needs to apply relocations to
the kernel modules.  Therefore, this patch series factors out the module
relocation code so that it can be shared.

One thing that is still missing is crashkernel support, which I intend
to submit shortly. For now, arch_kexec_kernel_image_probe rejects crash
kernels.

This code is based on kexec-tools, but with many modifications to adapt
it to the kernel environment and facilities. Except the purgatory,
which only has minimal changes.

Changes for v3:
- Rebased series on today's powerpc/next.
- Patch "kexec_file: Generalize kexec_add_buffer.":
- Removed most arguments from arch_kexec_walk_mem and pass kbuf
  explicitly.
- Patch "powerpc: Add functions to read ELF files of any endianness.":
- Fixed whitespace issues found by checkpatch.pl.
- Patch "powerpc: Factor out relocation code from module_64.c to
  elf_util_64.c.":
- Changed to use the new PPC64_ELF_ABI_v2 macro.
- Patch "powerpc: Add support for loading ELF kernels with
  kexec_file_load.":
- Adapted arch_kexec_walk_mem implementation to changes in its
  argument list.
- Fixed whitespace and GPL header issues found by checkpatch.pl.
- Patch "powerpc: Add purgatory for kexec_file_load implementation.":
- Fixed whitespace and GPL header issues found by checkpatch.pl.
- Changed to use the new PPC64_ELF_ABI_v2 macro.

Changes for v2:

- All patches: forgot to add Signed-off-by lines in v1, so added them now.
- Patch "kexec_file: Generalize kexec_add_buffer.": broke in two, one
  adding arch_kexec_walk_mem and the other adding kexec_locate_mem_hole.
- Patch "powerpc: Implement kexec_file_load.":
- Moved relocation changes and the arch_kexec_walk_mem implementation
  to the next patch in the series.
- Removed pr_fmt from machine_kexec_64.c, since the patch doesn't add
  any call to pr_debug in that file.
- Changed arch_kexec_kernel_image_probe to reject crash kernels.

Changes for v3:
- Rebased series on today's powerpc/next.
- Patch "kexec_file: Generalize kexec_add_buffer.":
- Removed most arguments from arch_kexec_walk_mem and pass kbuf
  explicitly.
- Patch "powerpc: Add functions to read ELF files of any endianness.":
- Fixed whitespace issues found by checkpatch.pl.
- Patch "powerpc: Factor out relocation code from module_64.c to
  elf_util_64.c.":
- Changed to use the new PPC64_ELF_ABI_v2 macro.
- Patch "powerpc: Add support for loading ELF kernels with
  kexec_file_load.":
- Adapted arch_kexec_walk_mem implementation to changes in its
  argument list.
- Fixed whitespace and GPL header issues found by checkpatch.pl.
- Patch "powerpc: Add purgatory for kexec_file_load implementation.":
- Fixed whitespace and GPL header issues found by checkpatch.pl.
- Changed to use the new PPC64_ELF_ABI_v2 macro.

Changes for v2:

- All patches: forgot to add Signed-off-by lines in v1, so added them now.
- Patch "kexec_file: Generalize kexec_add_buffer.": broke in two, one
  adding arch_kexec_walk_mem and the other adding kexec_locate_mem_hole.
- Patch "powerpc: Implement kexec_file_load.":
- Moved relocation changes and the arch_kexec_walk_mem implementation
  to the next patch in the series.
- Removed pr_fmt from machine_kexec_64.c, since the patch doesn't add
  any call to pr_debug in that file.
- Changed arch_kexec_kernel_image_probe to reject 

[PATCH v3 0/9] powerpc/powernv/cpuidle: Add support for POWER ISA v3 idle states

[Shreyas B. Prabhu]

POWER ISA v3 defines a new idle processor core mechanism. In summary,
 a) new instruction named stop is added. This instruction replaces
instructions like nap, sleep, rvwinkle.
 b) new per thread SPR named PSSCR is added which controls the behavior
of stop instruction. 

PSSCR has following key fields
Bits 0:3  - Power-Saving Level Status. This field indicates the
lowest power-saving state the thread entered since stop
instruction was last executed.

Bit 42 - Enable State Loss  
0 - No state is lost irrespective of other fields  
1 - Allows state loss

Bits 44:47 - Power-Saving Level Limit  
This limits the power-saving level that can be entered into.

Bits 60:63 - Requested Level  
Used to specify which power-saving level must be entered on
executing stop instruction

Stop idle states and their properties like name, latency, target
residency, psscr value are exposed via device tree.

This patch series adds support for this new mechanism.

Patches 1-6 are cleanups and code movement.
Patch 7 adds platform specific support for stop and psscr handling.
Patch 8 adds cpuidle driver support.
Patch 9 makes offlined cpu use deepest stop state.

Changes in v3
=
 - Rebased on powerpc-next
 - Dropping patch 1 since we are not adding a new file for P9 idle support
 - Improved comments in multiple places
 - Moved GET_PACA from power7_restore_hyp_resource to System Reset
 - Instead of moving few functions from idle_power7 to idle_power_common,
   renaming idle_power7.S to idle_power_common.S
 - Moved HSTATE_HWTHREAD_STATE updation to power_powersave_common
 - Dropped earlier patch 5 which moved few macros from idle_power_common to
   asm/cpuidle.h. 
 - Added a patch to rename reusable power7_* idle functions to pnv_*
 - Added new patch that creates abstraction for saving SPRs before
   entering deep idle states
 - Instead of introducing new file idle_power_stop.S, P9 idle support
   is added to idle_power_common.S using CPU_FTR sections.
 - Fixed r4 reg clobbering in power_stop0

Changes in v2
=
 - Rebased on v4.6-rc6
 - Using CPU_FTR_ARCH_300 bit instead of CPU_FTR_STOP_INST

Cc: Rafael J. Wysocki 
Cc: Daniel Lezcano 
Cc: linux...@vger.kernel.org
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Michael Neuling 
Cc: linuxppc-dev@lists.ozlabs.org

Shreyas B. Prabhu (9):
  powerpc/powernv: Move CHECK_HMI_INTERRUPT to exception-64s header
  powerpc/kvm: make hypervisor state restore a function
  powerpc/powernv: Rename idle_power7.S to idle_power_common.S
  powerpc/powernv: Make power7_powersave_common more generic
  powerpc/powernv: abstraction for saving SPRs before entering deep idle
states
  powerpc/powernv: set power_save func after the idle states are
initialized
  powerpc/powernv: Add platform support for stop instruction
  cpuidle/powernv: Add support for POWER ISA v3 idle states
  powerpc/powernv: Use deepest stop state when cpu is offlined

 arch/powerpc/include/asm/cpuidle.h|   2 +
 arch/powerpc/include/asm/exception-64s.h  |  18 +
 arch/powerpc/include/asm/kvm_book3s_asm.h |   2 +-
 arch/powerpc/include/asm/machdep.h|   1 +
 arch/powerpc/include/asm/opal-api.h   |  11 +-
 arch/powerpc/include/asm/paca.h   |   2 +
 arch/powerpc/include/asm/ppc-opcode.h |   4 +
 arch/powerpc/include/asm/processor.h  |   1 +
 arch/powerpc/include/asm/reg.h|  11 +
 arch/powerpc/kernel/Makefile  |   2 +-
 arch/powerpc/kernel/asm-offsets.c |   2 +
 arch/powerpc/kernel/exceptions-64s.S  |  28 +-
 arch/powerpc/kernel/idle_power7.S | 515 
 arch/powerpc/kernel/idle_power_common.S   | 642 ++
 arch/powerpc/platforms/powernv/idle.c |  96 -
 arch/powerpc/platforms/powernv/powernv.h  |   1 +
 arch/powerpc/platforms/powernv/setup.c|   2 +-
 arch/powerpc/platforms/powernv/smp.c  |   4 +-
 drivers/cpuidle/cpuidle-powernv.c |  57 ++-
 19 files changed, 843 insertions(+), 558 deletions(-)
 delete mode 100644 arch/powerpc/kernel/idle_power7.S
 create mode 100644 arch/powerpc/kernel/idle_power_common.S

-- 
2.4.11

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 0/9] FP/VEC/VSX switching optimisations

[Cyril Bur]

Cover-letter for V1 of the series is at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-November/136350.html

Cover-letter for V2 of the series is at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-January/138054.html

Changes in V3:
Addressed review comments from Michael Neuling
 - Made commit message in 4/9 better reflect the patch
 - Removed overuse of #ifdef blocks and redundant condition in 5/9
 - Split 6/8 in two to better prepare for 7,8,9
 - Removed #ifdefs in 6/9


Cyril Bur (9):
  selftests/powerpc: Test the preservation of FPU and VMX regs across
syscall
  selftests/powerpc: Test preservation of FPU and VMX regs across
preemption
  selftests/powerpc: Test FPU and VMX regs in signal ucontext
  powerpc: Explicitly disable math features when copying thread
  powerpc: Restore FPU/VEC/VSX if previously used
  powerpc: Prepare for splitting giveup_{fpu,altivec,vsx} in two
  powerpc: Add the ability to save FPU without giving it up
  powerpc: Add the ability to save Altivec without giving it up
  powerpc: Add the ability to save VSX without giving it up

 arch/powerpc/include/asm/processor.h   |   2 +
 arch/powerpc/include/asm/switch_to.h   |  13 +-
 arch/powerpc/kernel/asm-offsets.c  |   2 +
 arch/powerpc/kernel/entry_64.S |  21 +-
 arch/powerpc/kernel/fpu.S  |  25 +--
 arch/powerpc/kernel/ppc_ksyms.c|   4 -
 arch/powerpc/kernel/process.c  | 172 ++--
 arch/powerpc/kernel/vector.S   |  45 +---
 tools/testing/selftests/powerpc/Makefile   |   3 +-
 tools/testing/selftests/powerpc/basic_asm.h|  26 +++
 tools/testing/selftests/powerpc/math/.gitignore|   6 +
 tools/testing/selftests/powerpc/math/Makefile  |  19 ++
 tools/testing/selftests/powerpc/math/fpu_asm.S | 195 ++
 tools/testing/selftests/powerpc/math/fpu_preempt.c | 113 ++
 tools/testing/selftests/powerpc/math/fpu_signal.c  | 135 
 tools/testing/selftests/powerpc/math/fpu_syscall.c |  90 
 tools/testing/selftests/powerpc/math/vmx_asm.S | 229 +
 tools/testing/selftests/powerpc/math/vmx_preempt.c | 113 ++
 tools/testing/selftests/powerpc/math/vmx_signal.c  | 138 +
 tools/testing/selftests/powerpc/math/vmx_syscall.c |  92 +
 20 files changed, 1360 insertions(+), 83 deletions(-)
 create mode 100644 tools/testing/selftests/powerpc/basic_asm.h
 create mode 100644 tools/testing/selftests/powerpc/math/.gitignore
 create mode 100644 tools/testing/selftests/powerpc/math/Makefile
 create mode 100644 tools/testing/selftests/powerpc/math/fpu_asm.S
 create mode 100644 tools/testing/selftests/powerpc/math/fpu_preempt.c
 create mode 100644 tools/testing/selftests/powerpc/math/fpu_signal.c
 create mode 100644 tools/testing/selftests/powerpc/math/fpu_syscall.c
 create mode 100644 tools/testing/selftests/powerpc/math/vmx_asm.S
 create mode 100644 tools/testing/selftests/powerpc/math/vmx_preempt.c
 create mode 100644 tools/testing/selftests/powerpc/math/vmx_signal.c
 create mode 100644 tools/testing/selftests/powerpc/math/vmx_syscall.c

-- 
2.7.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 0/9] KVM: PPC: Book3S HV: Optimize wakeup VCPU from H_IPI

[Suresh Warrier]

When the VCPU target of an H_IPI hypercall is not running
in the guest, we need to do a kick VCPU (wake the VCPU thread)
to make it runnable. The real-mode version of the H_IPI hypercall
cannot do this because it involves waking a sleeping thread.
Thus the hcall returns H_TOO_HARD which forces a switch back
to host so that the H_IPI call can be completed in virtual mode.
This has been found to cause a slowdown for many workloads like
YCSB MongoDB, small message networking, etc. 

One solution is to hand off this job of waking the VCPU to a CPU
that is running in the host by sending it a message through the 
IPI mechanism from the hypercall.

This patch set optimizes the wakeup of the target VCPU by posting
a free core already running in the host to do the wakeup, thus
avoiding the switch to host and back. It requires maintaining a
bitmask of all the available cores in the system to indicate if
they are in the host or running in some guest. It also requires
the H_IPI hypercall to search for a free host core and send it a
new IPI message PPC_MSG_RM_HOST_ACTION after stashing away some
parameters like the pointer to VCPU for the IPI handler. Locks
are avoided by using atomic operations to save core state, to
find and reserve a core in the host, etc.

Note that it is possible for a guest to be destroyed and its
VCPUs freed before the IPI handler gets to run. This case is
handled by ensuring that any pending PPC_MSG_RM_HOST_ACTION
IPIs are completed before proceeding with freeing the VCPUs.

Currently, powerpc only support 4 IPI messages and all 4 are 
already taken for other purposes. This patch also set increases
the number of supported IPI messages to 8. It also provides the
code to send an IPI from hypercall running in real-mode since
the existing cause_ipi functions cannot be executed in real-mode.

A tunable h_ipi_redirect is also included in the patch set to
disable the feature. 

v3:
* Updated/clarified commit logs.
* Fix build break when building without KVM.

v2:
* Complete patch set sent to both kvm and linuxppc mailing lists
  to avoid build-breaks.
* Broke up real mode IPI messaging function into two pieces - one
  to set the message and one to cause the IPI. New function
  icp_native_cause_ipi_rm added to arch/powerpc/sysdev/xics/icp-native.c


Suresh Warrier (9):
  powerpc/smp: Support more IPI messages
  powerpc/smp: Add smp_muxed_ipi_set_message
  powerpc/xics: Add icp_native_cause_ipi_rm
  KVM: PPC: Book3S HV: Host-side RM data structures
  KVM: PPC: Book3S HV: Manage core host state
  KVM: PPC: Book3S HV: kvmppc_host_rm_ops - handle offlining CPUs
  KVM: PPC: Book3S HV: Host side kick VCPU when poked by real-mode KVM
  KVM: PPC: Book3S HV: Send IPI to host core to wake VCPU
  KVM: PPC: Book3S HV: Add tunable to control H_IPI redirection

 arch/powerpc/include/asm/kvm_ppc.h|  33 +++
 arch/powerpc/include/asm/smp.h|   4 +
 arch/powerpc/include/asm/xics.h   |   1 +
 arch/powerpc/kernel/smp.c |  28 +-
 arch/powerpc/kvm/book3s_hv.c  | 166 ++
 arch/powerpc/kvm/book3s_hv_builtin.c  |   3 +
 arch/powerpc/kvm/book3s_hv_rm_xics.c  | 120 +++-
 arch/powerpc/kvm/powerpc.c|  10 ++
 arch/powerpc/sysdev/xics/icp-native.c |  21 +
 9 files changed, 378 insertions(+), 8 deletions(-)

-- 
1.8.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

[David Miller]

From: Florian Fainelli 
Date: Thu, 24 Sep 2015 18:39:56 -0700

> On 24/09/15 12:17, Russell King - ARM Linux wrote:
>> Hi,
>> 
>> The third version of this series fixes the build error which David
>> identified, and drops the broken changes for the Cavium Thunger BGX
>> ethernet driver as this driver requires some complex changes to
>> resolve the leakage - and this is best done by people who can test
>> the driver.
>> 
>> Compared to v2, the only patch which has changed is patch 6
>>   "net: fix phy refcounting in a bunch of drivers"
>> 
>> I _think_ I've been able to build-test all the drivers touched by
>> that patch to some degree now, though several of them needed the
>> Kconfig hacked to allow it (not all had || COMPILE_TEST clause on
>> their dependencies.)
> 
> Tested-by: Florian Fainelli 
> Reviewed-by: Florian Fainelli 
> 
> Thanks for fixing that.

Series applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Russell King - ARM Linux]

Hi,

The third version of this series fixes the build error which David
identified, and drops the broken changes for the Cavium Thunger BGX
ethernet driver as this driver requires some complex changes to
resolve the leakage - and this is best done by people who can test
the driver.

Compared to v2, the only patch which has changed is patch 6
  "net: fix phy refcounting in a bunch of drivers"

I _think_ I've been able to build-test all the drivers touched by
that patch to some degree now, though several of them needed the
Kconfig hacked to allow it (not all had || COMPILE_TEST clause on
their dependencies.)

Previous cover letters below:

This is the second version of the series, with the comments David had
on the first patch fixed up.  Original series description with updated
diffstat below.

While looking at the DSA code, I noticed we have a
of_find_net_device_by_node(), and it looks like users of that are
similarly buggy - it looks like net/dsa/dsa.c is the only user.  Fix
that too.

Hi,

While looking at the phy code, I identified a number of weaknesses
where refcounting on device structures was being leaked, where
modules could be removed while in-use, and where the fixed-phy could
end up having unintended consequences caused by incorrect calls to
fixed_phy_update_state().

This patch series resolves those issues, some of which were discovered
with testing on an Armada 388 board.  Not all patches are fully tested,
particularly the one which touches several network drivers.

When resolving the struct device refcounting problems, several different
solutions were considered before settling on the implementation here -
one of the considerations was to avoid touching many network drivers.
The solution here is:

phy_attach*() - takes a refcount
phy_detach*() - drops the phy_attach refcount

Provided drivers always attach and detach their phys, which they should
already be doing, this should change nothing, even if they leak a refcount.

of_phy_find_device() and of_* functions which use that take
a refcount.  Arrange for this refcount to be dropped once
the phy is attached.

This is the reason why the previous change is important - we can't drop
this refcount taken by of_phy_find_device() until something else holds
a reference on the device.  This resolves the leaked refcount caused by
using of_phy_connect() or of_phy_attach().

Even without the above changes, these drivers are leaking by calling
of_phy_find_device().  These drivers are addressed by adding the
appropriate release of that refcount.

The mdiobus code also suffered from the same kind of leak, but thankfully
this only happened in one place - the mdio-mux code.

I also found that the try_module_get() in the phy layer code was utterly
useless: phydev->dev.driver was guaranteed to always be NULL, so
try_module_get() was always being called with a NULL argument.  I proved
this with my SFP code, which declares its own MDIO bus - the module use
count was never incremented irrespective of how I set the MDIO bus up.
This allowed the MDIO bus code to be removed from the kernel while there
were still PHYs attached to it.

One other bug was discovered: while using in-band-status with mvneta, it
was found that if a real phy is attached with in-band-status enabled,
and another ethernet interface is using the fixed-phy infrastructure, the
interface using the fixed-phy infrastructure is configured according to
the other interface using the in-band-status - which is caused by the
fixed-phy code not verifying that the phy_device passed in is actually
a fixed-phy device, rather than a real MDIO phy.

Lastly, having mdio_bus reversing phy_device_register() internals seems
like a layering violation - it's trivial to move that code to the phy
device layer.

 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 24 ++
 drivers/net/ethernet/freescale/gianfar.c   |  6 ++-
 drivers/net/ethernet/freescale/ucc_geth.c  |  8 +++-
 drivers/net/ethernet/marvell/mvneta.c  |  2 +
 drivers/net/ethernet/xilinx/xilinx_emaclite.c  |  2 +
 drivers/net/phy/fixed_phy.c|  2 +-
 drivers/net/phy/mdio-mux.c | 19 +---
 drivers/net/phy/mdio_bus.c | 24 ++
 drivers/net/phy/phy_device.c   | 62 --
 drivers/of/of_mdio.c   | 27 +--
 include/linux/phy.h|  6 ++-
 net/core/net-sysfs.c   |  9 
 net/dsa/dsa.c  | 41 ++---
 13 files changed, 181 insertions(+), 51 deletions(-)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Andrew Lunn]

> Thanks for testing.  Please could you confirm whether the same behaviour
> is observed without the patches, just to make absolutely sure that isn't
> a regression.

So i tested this now.

I have two FEC interfaces. One i my main access interface, and the
second is used by DSA to access switches. With your patches, the
module Used by count is equal to the number of interfaces which are
up.

Without your patches, the count is always 0.

When i try to remove the fec module, without your patches, but DSA
still using the interface, i get the same

 kernel:unregister_netdevice: waiting for eth1 to become free. Usage count = 1

as with your patch. So this is not a regression.

   Andrew
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Russell King - ARM Linux]

On Thu, Sep 24, 2015 at 03:51:37PM -0700, David Miller wrote:
> From: Andrew Lunn 
> Date: Fri, 25 Sep 2015 00:26:54 +0200
> 
> > On Thu, Sep 24, 2015 at 03:15:54PM -0700, David Miller wrote:
> >> From: Andrew Lunn 
> >> Date: Thu, 24 Sep 2015 23:57:31 +0200
> >> 
> >> > I built the FEC driver as a module, and it won't unload:
> >> > 
> >> >  kernel:unregister_netdevice: waiting for eth1 to become free. Usage 
> >> > count = 1
> >> > unregister_netdevice: waiting for eth1 to become free. Usage count = 1
> >> > 
> >> > i assume because DSA holds a reference. I've not tried a fully module
> >> > build, DSA has issues with that.
> >> > 
> >> > Tested-by: Andrew Lunn 
> >> 
> >> So, is this a regression?
> > 
> > Sorry, worded that badly. Since DSA is still active, it should not be
> > possible to unload the FEC driver. DSA should have a reference to it,
> > and mdio-mux also should have a reference to the mdio bus of the FEC
> > driver.
> > 
> > As Russell requested, i will re-test without his patches, just to make
> > sure.
> 
> Something needs to hold into the underlying device refcount of a DSA
> blob so that an unload can't even be attempted in that state.

Holding a reference on a struct device does _not_ stop the device
being unbound or the module driving it being removed.  It merely
stops the struct device from being freed before all references have
been dropped.

Devices are always free to be unbound from their bound drivers
irrespective of the struct device refcount.  Even taking a reference
on the module (via try_module_get()) does not stop this.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Andrew Lunn]

...

> While looking at the DSA code, I noticed we have a
> of_find_net_device_by_node(), and it looks like users of that are
> similarly buggy - it looks like net/dsa/dsa.c is the only user.  Fix
> that too.

...
 
> The mdiobus code also suffered from the same kind of leak, but thankfully
> this only happened in one place - the mdio-mux code.

Hi Russell

I tested both of these with my board. It is a Freescale Vybrid, using
the FEC ethernet driver, and i have three switches attached, using
mdio-mux to give three mdio busses.

No obvious regressions, my board boots, the switches are all present
and correct. I built the FEC driver as a module, and it won't unload:

 kernel:unregister_netdevice: waiting for eth1 to become free. Usage count = 1
unregister_netdevice: waiting for eth1 to become free. Usage count = 1

i assume because DSA holds a reference. I've not tried a fully module
build, DSA has issues with that.

Tested-by: Andrew Lunn 

Thanks
Andrew
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

[David Miller]

From: Andrew Lunn 
Date: Thu, 24 Sep 2015 23:57:31 +0200

> I built the FEC driver as a module, and it won't unload:
> 
>  kernel:unregister_netdevice: waiting for eth1 to become free. Usage count = 1
> unregister_netdevice: waiting for eth1 to become free. Usage count = 1
> 
> i assume because DSA holds a reference. I've not tried a fully module
> build, DSA has issues with that.
> 
> Tested-by: Andrew Lunn 

So, is this a regression?

Please don't provide a "Tested-by: " tag is you encounter a new
problem which could have been introduced by the changes in question.
That _REALLY_ screws everything up for me.

Thank.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Andrew Lunn]

On Thu, Sep 24, 2015 at 03:15:54PM -0700, David Miller wrote:
> From: Andrew Lunn 
> Date: Thu, 24 Sep 2015 23:57:31 +0200
> 
> > I built the FEC driver as a module, and it won't unload:
> > 
> >  kernel:unregister_netdevice: waiting for eth1 to become free. Usage count 
> > = 1
> > unregister_netdevice: waiting for eth1 to become free. Usage count = 1
> > 
> > i assume because DSA holds a reference. I've not tried a fully module
> > build, DSA has issues with that.
> > 
> > Tested-by: Andrew Lunn 
> 
> So, is this a regression?

Sorry, worded that badly. Since DSA is still active, it should not be
possible to unload the FEC driver. DSA should have a reference to it,
and mdio-mux also should have a reference to the mdio bus of the FEC
driver.

As Russell requested, i will re-test without his patches, just to make
sure.

Andrew
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Russell King - ARM Linux]

On Fri, Sep 25, 2015 at 12:50:33AM +0200, Andrew Lunn wrote:
> > Thanks for testing.  Please could you confirm whether the same behaviour
> > is observed without the patches, just to make absolutely sure that isn't
> > a regression.
> 
> So i tested this now.
> 
> I have two FEC interfaces. One i my main access interface, and the
> second is used by DSA to access switches. With your patches, the
> module Used by count is equal to the number of interfaces which are
> up.
> 
> Without your patches, the count is always 0.

That will be as a result of the MDIO bus module refcounting patch -
"phy: fix mdiobus module safety".  The code prior to that patch was
totally useless and ineffectual - it might as well not even have
been present, because it would never have any effect.  bus_module
would always be NULL in phy_attach_direct().

While my change makes the code start to work as originally intended,
it's still unsafe: there's nothing to stop you manually unbinding the
driver providing the MDIO bus from the struct device.  The driver
will then free the resources it claimed in its probe function, which
may include the MMIO mapping for the MDIO bus accessor functions.

If the accessors are then called, despite keeping the mdio bus, phy,
etc data structures properly refcounted, the kernel will oops when
the (many) MDIO bus drivers hit the free'd MMIO mapping.  This is,
unfortunately, just another pre-existing bug in this code.

To stop that, we need some way to say "this MDIO bus has been removed,
prevent further access" and that needs to be done in a race free way.
Right now, that doesn't exist.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Florian Fainelli]

On 24/09/15 12:17, Russell King - ARM Linux wrote:
> Hi,
> 
> The third version of this series fixes the build error which David
> identified, and drops the broken changes for the Cavium Thunger BGX
> ethernet driver as this driver requires some complex changes to
> resolve the leakage - and this is best done by people who can test
> the driver.
> 
> Compared to v2, the only patch which has changed is patch 6
>   "net: fix phy refcounting in a bunch of drivers"
> 
> I _think_ I've been able to build-test all the drivers touched by
> that patch to some degree now, though several of them needed the
> Kconfig hacked to allow it (not all had || COMPILE_TEST clause on
> their dependencies.)

Tested-by: Florian Fainelli 
Reviewed-by: Florian Fainelli 

Thanks for fixing that.

> 
> Previous cover letters below:
> 
> This is the second version of the series, with the comments David had
> on the first patch fixed up.  Original series description with updated
> diffstat below.
> 
> While looking at the DSA code, I noticed we have a
> of_find_net_device_by_node(), and it looks like users of that are
> similarly buggy - it looks like net/dsa/dsa.c is the only user.  Fix
> that too.
> 
> Hi,
> 
> While looking at the phy code, I identified a number of weaknesses
> where refcounting on device structures was being leaked, where
> modules could be removed while in-use, and where the fixed-phy could
> end up having unintended consequences caused by incorrect calls to
> fixed_phy_update_state().
> 
> This patch series resolves those issues, some of which were discovered
> with testing on an Armada 388 board.  Not all patches are fully tested,
> particularly the one which touches several network drivers.
> 
> When resolving the struct device refcounting problems, several different
> solutions were considered before settling on the implementation here -
> one of the considerations was to avoid touching many network drivers.
> The solution here is:
> 
>   phy_attach*() - takes a refcount
>   phy_detach*() - drops the phy_attach refcount
> 
> Provided drivers always attach and detach their phys, which they should
> already be doing, this should change nothing, even if they leak a refcount.
> 
>   of_phy_find_device() and of_* functions which use that take
>   a refcount.  Arrange for this refcount to be dropped once
>   the phy is attached.
> 
> This is the reason why the previous change is important - we can't drop
> this refcount taken by of_phy_find_device() until something else holds
> a reference on the device.  This resolves the leaked refcount caused by
> using of_phy_connect() or of_phy_attach().
> 
> Even without the above changes, these drivers are leaking by calling
> of_phy_find_device().  These drivers are addressed by adding the
> appropriate release of that refcount.
> 
> The mdiobus code also suffered from the same kind of leak, but thankfully
> this only happened in one place - the mdio-mux code.
> 
> I also found that the try_module_get() in the phy layer code was utterly
> useless: phydev->dev.driver was guaranteed to always be NULL, so
> try_module_get() was always being called with a NULL argument.  I proved
> this with my SFP code, which declares its own MDIO bus - the module use
> count was never incremented irrespective of how I set the MDIO bus up.
> This allowed the MDIO bus code to be removed from the kernel while there
> were still PHYs attached to it.
> 
> One other bug was discovered: while using in-band-status with mvneta, it
> was found that if a real phy is attached with in-band-status enabled,
> and another ethernet interface is using the fixed-phy infrastructure, the
> interface using the fixed-phy infrastructure is configured according to
> the other interface using the in-band-status - which is caused by the
> fixed-phy code not verifying that the phy_device passed in is actually
> a fixed-phy device, rather than a real MDIO phy.
> 
> Lastly, having mdio_bus reversing phy_device_register() internals seems
> like a layering violation - it's trivial to move that code to the phy
> device layer.
> 
>  drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 24 ++
>  drivers/net/ethernet/freescale/gianfar.c   |  6 ++-
>  drivers/net/ethernet/freescale/ucc_geth.c  |  8 +++-
>  drivers/net/ethernet/marvell/mvneta.c  |  2 +
>  drivers/net/ethernet/xilinx/xilinx_emaclite.c  |  2 +
>  drivers/net/phy/fixed_phy.c|  2 +-
>  drivers/net/phy/mdio-mux.c | 19 +---
>  drivers/net/phy/mdio_bus.c | 24 ++
>  drivers/net/phy/phy_device.c   | 62 
> --
>  drivers/of/of_mdio.c   | 27 +--
>  include/linux/phy.h|  6 ++-
>  net/core/net-sysfs.c   |  9 
>  net/dsa/dsa.c  | 41 ++---
>  13 files 

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

[Russell King - ARM Linux]

On Thu, Sep 24, 2015 at 11:57:31PM +0200, Andrew Lunn wrote:
> Hi Russell
> 
> I tested both of these with my board. It is a Freescale Vybrid, using
> the FEC ethernet driver, and i have three switches attached, using
> mdio-mux to give three mdio busses.
> 
> No obvious regressions, my board boots, the switches are all present
> and correct. I built the FEC driver as a module, and it won't unload:
> 
>  kernel:unregister_netdevice: waiting for eth1 to become free. Usage count = 1
> unregister_netdevice: waiting for eth1 to become free. Usage count = 1
> 
> i assume because DSA holds a reference. I've not tried a fully module
> build, DSA has issues with that.
> 
> Tested-by: Andrew Lunn 

Thanks for testing.  Please could you confirm whether the same behaviour
is observed without the patches, just to make absolutely sure that isn't
a regression.

However, I think you are correct - I'm unable to locate where in the
DSA code:
- dst->master_dev's dev_hold() is undone (hence a reference left)
- dst is freed - dsa_probe() allocates it using kzalloc(), but
  dsa_remove() and it's children don't free this structure.

There's no notifier which detects whether the underlying device has
gone away - it registers a netdev notifier (dsa_slave_netdevice_event)
but this only deals with slave devices, not the master device.

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes

[David Miller]

From: Andrew Lunn 
Date: Fri, 25 Sep 2015 00:26:54 +0200

> On Thu, Sep 24, 2015 at 03:15:54PM -0700, David Miller wrote:
>> From: Andrew Lunn 
>> Date: Thu, 24 Sep 2015 23:57:31 +0200
>> 
>> > I built the FEC driver as a module, and it won't unload:
>> > 
>> >  kernel:unregister_netdevice: waiting for eth1 to become free. Usage count 
>> > = 1
>> > unregister_netdevice: waiting for eth1 to become free. Usage count = 1
>> > 
>> > i assume because DSA holds a reference. I've not tried a fully module
>> > build, DSA has issues with that.
>> > 
>> > Tested-by: Andrew Lunn 
>> 
>> So, is this a regression?
> 
> Sorry, worded that badly. Since DSA is still active, it should not be
> possible to unload the FEC driver. DSA should have a reference to it,
> and mdio-mux also should have a reference to the mdio bus of the FEC
> driver.
> 
> As Russell requested, i will re-test without his patches, just to make
> sure.

Something needs to hold into the underlying device refcount of a DSA
blob so that an unload can't even be attempted in that state.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [Xen-devel] [PATCH v3 0/9] Use correctly the Xen memory terminologies

[David Vrabel]

On 07/08/15 17:34, Julien Grall wrote:
 Hi all,
 
 This patch series aims to use the memory terminologies described in
 include/xen/mm.h [1] for Linux xen code.

Applied to for-linus-4.3, thanks.

David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 0/9] Use correctly the Xen memory terminologies

[Julien Grall]

Hi all,

This patch series aims to use the memory terminologies described in
include/xen/mm.h [1] for Linux xen code.

The differences from v2 is minor but I resent it because my 64K series depends
on this series.

Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
first support of Xen was for PV. This has brought some misimplementation
of memory helpers on ARM and make the developper confused about the expected
behavior.

For instance, with pfn_to_mfn, we expect to get a MFN based on the name.
Although, if we look at the implementation on x86, it's returning a GFN.
Most of the callers are also using it this way.

The first 2 patches of this series is ARM related in order to remove
PV specific helpers which should not be used and fixing the implementation of
pfn_to_mfn.

The rest of the series is here rename most of the usage in the common code
of MFN to GFN. I also took the opportunity to replace most of the call to
pfn_to_gfn in the common code by page_to_gfn avoid construction such
as pfn_to_gfn(page_to_pfn(...).

Note the one xen-blkfront will be dropped by 64K series [2], I can include
here if necessary.

Major changes in v3:
- More typoes
- Rename page_to_gfn to xen_page_to_gfn to avoid confusing with the
KVM function gfn_to_page

Major changes in v2:
- Use bfn rather than dfn for the DMA address
- Re-introduced pfn_to_mfn for PV guests only
- Typoes

For all the changes see in each patch.

This series is based on xentip for-linus-4.3 branch. A branch with all the
patches can be found here:
git://xenbits.xen.org/people/julieng/linux-arm.git branch page-renaming-v3

It has been boot tested on ARM64 and ARM32 and only built for x86.
I would be happy if someone can give a try on x86 as I don't have a x86
box setup with Xen.

Sincerely yours,

[1] 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e758ed14f390342513405dd766e874934573e6cb
[2] https://lkml.org/lkml/2015/7/9/628

Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: H. Peter Anvin h...@zytor.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ingo Molnar mi...@redhat.com
Cc: James E.J. Bottomley jbottom...@odin.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Jiri Slaby jsl...@suse.com
Cc: Juergen Gross jgr...@suse.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: Roger Pau Monné roger@citrix.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Wei Liu wei.l...@citrix.com
Cc: x...@kernel.org



Julien Grall (9):
  arm/xen: Remove helpers which are PV specific
  xen: Make clear that swiotlb and biomerge are dealing with DMA address
  arm/xen: implement correctly pfn_to_mfn
  xen: Use correctly the Xen memory terminologies
  xen/tmem: Use xen_page_to_gfn rather than pfn_to_gfn
  video/xen-fbfront: Further s/MFN/GFN clean-up
  hvc/xen: Further s/MFN/GFN clean-up
  xen/privcmd: Further s/MFN/GFN/ clean-up
  xen/xenbus: Rename the variable xen_store_mfn to xen_store_gfn

 arch/arm/include/asm/xen/page.h | 44 -
 arch/arm/xen/enlighten.c| 18 +++---
 arch/arm/xen/mm.c   |  4 +--
 arch/x86/include/asm/xen/page.h | 35 +-
 arch/x86/xen/mmu.c  | 32 
 arch/x86/xen/smp.c  |  2 +-
 drivers/block/xen-blkfront.c|  6 ++---
 drivers/input/misc/xen-kbdfront.c   |  4 +--
 drivers/net/xen-netback/netback.c   |  4 +--
 drivers/net/xen-netfront.c  | 12 +
 drivers/scsi/xen-scsifront.c| 10 
 drivers/tty/hvc/hvc_xen.c   | 18 ++
 drivers/video/fbdev/xen-fbfront.c   | 20 +++
 drivers/xen/balloon.c   |  2 +-
 drivers/xen/biomerge.c  |  6 ++---
 drivers/xen/events/events_base.c|  2 +-
 drivers/xen/events/events_fifo.c|  4 +--
 drivers/xen/gntalloc.c  |  3 ++-
 drivers/xen/manage.c|  2 +-
 drivers/xen/privcmd.c   | 44 -
 drivers/xen/swiotlb-xen.c   | 16 ++--
 drivers/xen/tmem.c  | 21 ++--
 drivers/xen/xenbus/xenbus_client.c  |  2 +-
 drivers/xen/xenbus/xenbus_dev_backend.c |  2 +-
 drivers/xen/xenbus/xenbus_probe.c   | 16 ++--
 drivers/xen/xlate_mmu.c | 18 +++---
 include/uapi/xen/privcmd.h  |  4 

[PATCH V3 0/9] VF EEH on Power8

[Wei Yang]

This patchset enables EEH on SRIOV VFs. The general idea is to create proper
VF edev and VF PE and handle them properly.

Different from the Bus PE, VF PE just contain one VF. This introduces the
difference of EEH error handling on a VF PE. Generally, it has several
differences.

First, the VF's removal and re-enumerate rely on its PF. VF has a tight
relationship between its PF. This is not proper to enumerate a VF by usual
scan procedure. That's why virtfn_add/virtfn_remove are exported in this patch
set.

Second, the reset/restore of a VF is done in kernel space. FW is not aware of
the VF, this means the usual reset function done in FW will not work. One of
the patch will imitate the reset/restore function in kernel space.

Third, the VF may be removed during the PF's error_detected function. In this
case, the original error_detected-slot_reset-resume sequence is not proper
to those removed VFs, since they are re-created by PF in a fresh state. A flag
in eeh_dev is introduce to mark the eeh_dev is in error state. By doing so, we
track whether this device needs to be reset or not.

This has been tested both on host and in guest on Power8 with latest kernel
version.

v3:
   * add back vf_index in pci_dn to track the VF's index
   * rename ppdev in eeh_dev to physfn for consistency
   * move edev-physfn assignment before dev-dev.archdata.edev is set
   * move pnv_pci_fixup_vf_eeh() and pnv_pci_fixup_vf_caps() to eeh-powernv.c
   * more clear and detail in commit log and comment in code
   * merge eeh_rmv_virt_device() with eeh_rmv_device()
   * move the cfg_blocked check logic from pnv_eeh_read/write_config() to
 pnv_eeh_cfg_blocked()
   * move the vf reset/restore logic into its own patch, two patches are
 created.
 powerpc/powernv: Support PCI config restore for VFs
 powerpc/powernv: Support EEH reset for VFs
   * simplify the vf reset logic
v2:
   * add prefix pci_iov_ to virtfn_add/virtfn_remove
   * use EEH_DEV_VF as a flag for a VF's eeh_dev
   * use eeh_dev instead of edev in change log
   * remove vf_index in eeh_dev, calculate it from pdn-busno and devfn
   * do eeh_add_device_late() and eeh_sysfs_add_device() both after pci_dev is
 well initialized
   * do FLR to reset a VF PE
   * imitate the restore function in FW for VF
   * remove the reverse order patch, since it is still under discussion

Wei Yang (9):
  pci/iov: rename and export virtfn_add/virtfn_remove
  powerpc/pci_dn: cache vf_index in pci_dn
  powerpc/pci: remove PCI devices in reverse order
  powerpc/eeh: cache address range just for normal device
  powerpc/eeh: create EEH_PE_VF for VF PE
  powerpc/powernv: create/release eeh_dev for VF
  powerpc/powernv: Support EEH reset for VFs
  powerpc/powernv: Support PCI config restore for VFs
  powerpc/eeh: handle VF PE properly

 arch/powerpc/include/asm/eeh.h   |   10 ++
 arch/powerpc/include/asm/pci-bridge.h|2 +
 arch/powerpc/kernel/eeh.c|5 +
 arch/powerpc/kernel/eeh_cache.c  |2 +-
 arch/powerpc/kernel/eeh_dev.c|   20 +++
 arch/powerpc/kernel/eeh_driver.c |  108 +++---
 arch/powerpc/kernel/eeh_pe.c |   15 +-
 arch/powerpc/kernel/pci-hotplug.c|2 +-
 arch/powerpc/kernel/pci_dn.c |   12 +-
 arch/powerpc/platforms/powernv/eeh-powernv.c |  200 +-
 drivers/pci/iov.c|   10 +-
 include/linux/pci.h  |2 +
 12 files changed, 352 insertions(+), 36 deletions(-)

-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 0/9] powerpc: kill PPC_OF

[Kevin Hao]

Hi Michael,

Finally I got all the acks for these patches. The following two patches in v2
were merged into next now.
213dce3c17a6 (tty: kconfig: remove the superfluous dependency on 
PPC_OF)
f4e074f20cad (mmc: kconfig: replace PPC_OF with PPC)

So we may have dependency issue if we put this series into 4.1.

v3: No codes change, just add the acks from Ben and Tomi.

Kevin Hao (9):
  sata_svw: remove the dependency on PPC_OF
  fbdev: aty128fb: replace PPC_OF with PPC
  fbdev: radeon: replace PPC_OF with PPC
  fbdev: imsttfb: remove the dependency on PPC_OF
  fbdev: nvidia: remove the dependency on PPC_OF
  fbdev: riva: remove the dependency on PPC_OF
  fbdev: remove the unnecessary includes of ppc specific header files
  fbdev: kconfig: replace PPC_OF with PPC
  powerpc: kill PPC_OF

 arch/powerpc/Kconfig |  3 ---
 arch/powerpc/Kconfig.debug   |  2 +-
 arch/powerpc/kernel/Makefile |  4 ++--
 drivers/ata/sata_svw.c   | 11 +--
 drivers/video/fbdev/Kconfig  |  4 ++--
 drivers/video/fbdev/aty/aty128fb.c   |  4 ++--
 drivers/video/fbdev/aty/radeon_base.c| 24 
 drivers/video/fbdev/aty/radeon_monitor.c | 20 ++--
 drivers/video/fbdev/aty/radeon_pm.c  | 16 
 drivers/video/fbdev/aty/radeonfb.h   |  4 ++--
 drivers/video/fbdev/core/fbmon.c |  4 
 drivers/video/fbdev/imsttfb.c|  6 +-
 drivers/video/fbdev/nvidia/Makefile  |  3 +--
 drivers/video/fbdev/nvidia/nv_of.c   |  3 ---
 drivers/video/fbdev/nvidia/nv_proto.h|  8 
 drivers/video/fbdev/nvidia/nvidia.c  |  4 
 drivers/video/fbdev/riva/fbdev.c | 17 +++--
 17 files changed, 49 insertions(+), 88 deletions(-)

-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 0/9] Fixes for common mistakes w/ for_each_process and task-mm

[Anton Vorontsov]

Hi all,

This is another resend of several task-mm fixes, the bugs I found
during LMK code audit. Architectures were traverse the tasklist
in an unsafe manner, plus there are a few cases of unsafe access to
task-mm in general.

There were no objections on the previous resend, and the final words
were somewhere along the patches are fine line.

In v3:
- Dropped a controversal 'Make find_lock_task_mm() sparse-aware' patch;
- Reword arm and sh commit messages, per Oleg Nesterov's suggestions;
- Added an optimization trick in clear_tasks_mm_cpumask(): take only
  the rcu read lock, no need for the whole tasklist_lock.
  Suggested by Peter Zijlstra.

In v2: 
- introduced a small helper in cpu.c: most arches duplicate the
  same [buggy] code snippet, so it's better to fix it and move the
  logic into a common function.

Thanks,

-- 
Anton Vorontsov
Email: cbouatmai...@gmail.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/9] fsldma: lockup fixes

[Felix Radensky]

Hi Ira,

I've successfully tested this version on P2020RDB,
with 10 threads per channel, 10 iterations per
thread.

Tested-by: Felix Radensky fe...@embedded-sol.com

Felix.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 0/9] fsldma: lockup fixes

[Ira W. Snyder]

Hello everyone,

I've been chasing random infrequent controller lockups in the fsldma driver
for a long time. I finally managed to find the problem and fix it. I'm not
quite sure about the exact sequence of events which causes the race
condition, but it is related to using the hardware registers to track the
controller state. See the patch changelogs for more detail.

The problems were quickly found by turning on DMAPOOL_DEBUG inside
mm/dmapool.c. This poisons memory allocated with the dmapool API.

With dmapool poisoning turned on, the dmatest driver would start producing
failures within a few seconds. After this patchset has been applied, I have
run several iterations of the 10 threads per channel, 10 iterations per
thread test without any problems. I have also tested it with the CARMA
drivers (posted at linuxppc-dev previously), which make use of the external
control features.

While making the previous changes, I noticed that the fsldma driver does
not respect the automatic DMA unmapping of src and dst buffers. I have
added support for this feature. This also required a fix to dmatest, which
was sending incorrect flags.

The support async_tx dependencies patch could be split apart from the
automatic unmapping patch if it is desirable. They both touch the same
piece of code, so I thought it was ok to combine them. Let me know.

I would really like to see this go into 2.6.39. I think we can get it
reviewed before then. :)

Much thanks goes to Felix Radensky for testing on a P2020 (85xx DMA IP core).
I wouldn't have been able to track down the problems on 85xx without his
dilligent testing.

v2 - v3:
- use chan_dbg() and chan_err() macros for channel printk

v1 - v2:
- reordered patches (dmatest change is first now)
- fix problems on 85xx controller
- only set correct bits for 83xx in dma_halt()

Ira W. Snyder (9):
  dmatest: fix automatic buffer unmap type
  fsldma: move related helper functions near each other
  fsldma: use channel name in printk output
  fsldma: improve link descriptor debugging
  fsldma: minor codingstyle and consistency fixes
  fsldma: fix controller lockups
  fsldma: support async_tx dependencies and automatic unmapping
  fsldma: reduce locking during descriptor cleanup
  fsldma: make halt behave nicely on all supported controllers

 drivers/dma/dmatest.c |7 +-
 drivers/dma/fsldma.c  |  551 +++--
 drivers/dma/fsldma.h  |6 +-
 3 files changed, 311 insertions(+), 253 deletions(-)

-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 0/9] wireless: Use macros from wireless.h

[Joe Perches]

Create a IW_HANDLER macro for iw_handler array entries in wireless.h
Use the wireless.h macros in various wireless files
Use starting index define SIOCIWFIRST where appropriate 
Remove local #defines of IW_IOCTL
Remove STD_IW_HANDLER macro in orinoco, use IW_HANDLER instead

Joe Perches (9):
  include/linux/wireless.h: Add IW_HANDLER macro to initialize array entry
  wireless.h: Use SIOCIWFIRST not SIOCSIWCOMMIT for range check
  include/net/iw_handler.h: Use SIOCIWFIRST not SIOCSIWCOMMIT in comment
  net/wireless/wext_core.c: Use IW_IOCTL_IDX macro
  net/wireless/wext-core.c: Use IW_EVENT_IDX macro
  drivers/net/wireless: Use IW_HANDLER macro
  drivers/net: Remove local #define IW_IOCTL, use IW_HANDLER
  orinoco/wext.c: Remove local #define STD_IW_HANDLER
  drivers/net/wireless/ray_cs.c: Use iw_handler function prototypes

 drivers/net/ps3_gelic_wireless.c   |   35 +++---
 drivers/net/wireless/ipw2x00/ipw2200.c |   83 ++---
 drivers/net/wireless/orinoco/wext.c|   94 +++---
 drivers/net/wireless/ray_cs.c  |  212 +++-
 drivers/net/wireless/wl3501_cs.c   |   52 
 include/linux/wireless.h   |4 +-
 include/net/iw_handler.h   |2 +-
 net/wireless/wext-core.c   |  134 ++--
 8 files changed, 298 insertions(+), 318 deletions(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 0/9] Add MPC837x generic support and MPC837xE MDS support

[Li Yang]

The patch series has been re-built to apply on the latest Linus' HEAD after
pulling Paul's for-2.6.24.  All comments on list are addressed.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev