[GIT PULL] Please pull powerpc/linux.git powerpc-6.10-3 tag

2024-06-22 Thread Michael Ellerman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Linus,

Please pull some more powerpc fixes for 6.10:

The following changes since commit c3f38fa61af77b49866b006939479069cd451173:

  Linux 6.10-rc2 (2024-06-02 15:44:56 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-6.10-3

for you to fetch changes up to a986fa57fd81a1430e00b3c6cf8a325d6f894a63:

  KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group() 
(2024-06-16 10:20:11 +1000)

- --
powerpc fixes for 6.10 #3

 - Prevent use-after-free in 64-bit KVM VFIO

 - Add generated Power8 crypto asm to .gitignore

Thanks to: Al Viro, Nathan Lynch.

- --
Michael Ellerman (1):
  KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()

Nathan Lynch (1):
  powerpc/crypto: Add generated P8 asm to .gitignore


 arch/powerpc/crypto/.gitignore   |  2 ++
 arch/powerpc/kvm/book3s_64_vio.c | 18 +-
 2 files changed, 15 insertions(+), 5 deletions(-)
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmZ3gucACgkQUevqPMjh
pYC25xAAsSnTIzbZpHdg3Bdb0vqdgzQimS9TbXGm5Qnea6rZawXYcSEoLuUABWZY
ZkNDoezJoL9nks7JGO1lbTICUNFKleFSlBLye4WgRn7NQBlgFP2GYiH1hXJIlE0C
qNyqY8k9uhJQor6CYt4eygskVwjpdX6oeIcHcUNWQy7/p1jID48DFS7QHib0WWm+
wwuiPhdqBwlbJCQUO0zBmDgg8rAhPmeGSR1iHWJxk69CIcEOoXK8sxv1ZTKuE0YN
clOKeAPrlZ3dz2jDojcMUzckFxg9J/Wlozk+m4LVl4XVj5hV7TqBpT4BVJNoMk1i
qWV00bVg7sEWXQ9CGR71NKpdeE4pIeiN4EAEkW+nSmlJ0x9htadNychode+9cakb
E0U/fb/rB6T32UJsEUAFF2Dq8dG5wWXHPqn0rHh9v63tPvnteUisSFM9DN7Be9a4
UziItFANSmt3AK0uvBMgoYk8HM2USLb4WvigWdqtW9j6AGmO5NYPl1PgrLCDkFBA
Feevx5TAIs6GeGKrzbE5s9QHMAwtVhsN1g8lJgbCPZJfh9wcynIyrPI4K/Vu5J9A
tpNbRXGsfk/MCsNF6kgm+pAoseavXUwjsSNteFwq7eMSqZUgeG5a1hx/36b5mHdW
+YANpMmzS3Ae2HscZ6E8xTGxzfmmWmr6SczN0i0lBCR5cjUo7Cw=
=oWyE
-END PGP SIGNATURE-


Re: [PATCH 3/3] powerpc: Document details on H_HTM hcall

2024-06-22 Thread IBM
Madhavan Srinivasan  writes:

> Add documentation to 'papr_hcalls.rst' describing the
> input, output and return values of the H_HTM hcall as
> per the internal specification.
>
> Signed-off-by: Madhavan Srinivasan 
> ---
>  Documentation/arch/powerpc/papr_hcalls.rst | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/arch/powerpc/papr_hcalls.rst 
> b/Documentation/arch/powerpc/papr_hcalls.rst
> index 80d2c0aadab5..805e1cb9bab9 100644
> --- a/Documentation/arch/powerpc/papr_hcalls.rst
> +++ b/Documentation/arch/powerpc/papr_hcalls.rst
> @@ -289,6 +289,17 @@ to be issued multiple times in order to be completely 
> serviced. The
>  subsequent hcalls to the hypervisor until the hcall is completely serviced
>  at which point H_SUCCESS or other error is returned by the hypervisor.
>  
> +**H_HTM**
> +
> +| Input: flags, target, operation (op), op-param1, op-param2, op-param3
> +| Out: *dumphtmbufferdata*
> +| Return Value: *H_Success,H_Busy,H_LongBusyOrder,H_Partial,H_Parameter,
> +  H_P2,H_P3,H_P4,H_P5,H_P6,H_State,H_Not_Available,H_Authority*
> +
> +H_HTM supports setup, configuration, control and dumping of Hardware Trace
> +Macro (HTM) function and its data. HTM buffer stores tracing data for 
> functions
> +like core instruction, core LLAT and nest.
> +

Minor nit: Maybe the set of debugfs cmds to collect the trace and some
example trace log? If it is not confidential?

>  References
>  ==
>  .. [1] "Power Architecture Platform Reference"
> -- 
> 2.45.2


Re: [PATCH 2/3] powerpc/pseries: Export hardware trace macro dump via debugfs

2024-06-22 Thread IBM


This is a generic review and I haven't looked into the PAPR spec for
htmdump hcall and it's interface.

Madhavan Srinivasan  writes:

> This patch adds debugfs interface to export Hardware Trace Macro (HTM)
> function data in a LPAR. New hypervisor call "H_HTM" has been
> defined to setup, configure, control and dump the HTM data.
> This patch supports only dumping of HTM data in a LPAR.
> New debugfs folder called "htmdump" has been added under
> /sys/kernel/debug/arch path which contains files need to
> pass required parameters for the H_HTM dump function. New Kconfig
> option called "CONFIG_HTMDUMP" has been in platform/pseries for the same.
>
> With patch series applied and booted, list of files in debugfs path
>
> # pwd
> /sys/kernel/debug/powerpc/htmdump
> # ls
> coreindexonchip  htmtype  nodalchipindex  nodeindex  trace
>
> Signed-off-by: Madhavan Srinivasan 
> ---
>  arch/powerpc/platforms/pseries/Kconfig   |   8 ++
>  arch/powerpc/platforms/pseries/Makefile  |   1 +
>  arch/powerpc/platforms/pseries/htmdump.c | 130 +++
>  3 files changed, 139 insertions(+)
>  create mode 100644 arch/powerpc/platforms/pseries/htmdump.c
>
> diff --git a/arch/powerpc/platforms/pseries/Kconfig 
> b/arch/powerpc/platforms/pseries/Kconfig
> index afc0f6a61337..46c0ea605e33 100644
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -128,6 +128,14 @@ config CMM
> will be reused for other LPARs. The interface allows firmware to
> balance memory across many LPARs.
>
> +config HTMDUMP
> + tristate "PHYP HTM data dumper"

Not sure if we can make machine_device_initcall() as a tristate?
Did we try compiling it as a module?

It we would like to keep this as a module - then why not use module_init
call and then make it depend upon...

depends on PPC_PSERIES && DEBUG_FS (??)

> + default y

and then since this is mostly a debug trace facility, then we need not enable
it by default right?

> + help
> +   Select this option, if you want to enable the kernel debugfs
> +   interface to dump the Hardware Trace Macro (HTM) function data
> +   in the LPAR.
> +
>  config HV_PERF_CTRS
>   bool "Hypervisor supplied PMU events (24x7 & GPCI)"
>   default y
> diff --git a/arch/powerpc/platforms/pseries/Makefile 
> b/arch/powerpc/platforms/pseries/Makefile
> index 7bf506f6b8c8..3f3e3492e436 100644
> --- a/arch/powerpc/platforms/pseries/Makefile
> +++ b/arch/powerpc/platforms/pseries/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_HVC_CONSOLE)   += hvconsole.o
>  obj-$(CONFIG_HVCS)   += hvcserver.o
>  obj-$(CONFIG_HCALL_STATS)+= hvCall_inst.o
>  obj-$(CONFIG_CMM)+= cmm.o
> +obj-$(CONFIG_HTMDUMP)+= htmdump.o
>  obj-$(CONFIG_IO_EVENT_IRQ)   += io_event_irq.o
>  obj-$(CONFIG_LPARCFG)+= lparcfg.o
>  obj-$(CONFIG_IBMVIO) += vio.o
> diff --git a/arch/powerpc/platforms/pseries/htmdump.c 
> b/arch/powerpc/platforms/pseries/htmdump.c
> new file mode 100644
> index ..540cdb7e069c
> --- /dev/null
> +++ b/arch/powerpc/platforms/pseries/htmdump.c
> @@ -0,0 +1,130 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) IBM Corporation, 2024
> + */
> +
> +#define pr_fmt(fmt) "htmdump: " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Do we need all of the above?
e.g. slab, memory_hotplug etc are not needed IMO.

Maybe only?

#include 
#include 
#include 
#include 

#include 
#include 

(module.h depending upon if we make it module_init())


> +
> +/* This enables us to keep track of the memory removed from each node. */
> +struct htmdump_entry {
> + void *buf;
> + struct dentry *dir;
> + char name[16];
> +};
> +
> +static u32 nodeindex = 0;
> +static u32 nodalchipindex = 0;
> +static u32 coreindexonchip = 0;
> +static u32 htmtype = 0;
> +
> +#define BUFFER_SIZE PAGE_SIZE
> +
> +static ssize_t htmdump_read(struct file *filp, char __user *ubuf,
> +  size_t count, loff_t *ppos)
> +{
> + struct htmdump_entry *ent = filp->private_data;
> + unsigned long page, read_size, available;
> + loff_t offset;
> + long rc;
> +
> + page = ALIGN_DOWN(*ppos, BUFFER_SIZE);
> + offset = (*ppos) % BUFFER_SIZE;
> +
> + rc = htm_get_dump_hardware(nodeindex, nodalchipindex, coreindexonchip,
> +htmtype, virt_to_phys(ent->buf), 
> BUFFER_SIZE, page);
> +
> + switch(rc) {
> + case H_SUCCESS:
> + case H_PARTIAL:
> + break;
> + case H_NOT_AVAILABLE:
> + return 0;
> + case H_BUSY:
> + case H_LONG_BUSY_ORDER_1_MSEC:
> + case H_LONG_BUSY_ORDER_10_MSEC:
> + case H_LONG_BUSY_ORDER_100_MSEC:
> + case H_LONG_BUSY_ORDER_1_SEC:
> + case H_LONG_BUSY_ORDER_10_SEC:
> + case H_LONG_BUSY_ORDER_100_SEC:
> +