From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Madhavan Srinivasan <maddy@linux.ibm.com>, mpe@ellerman.id.au
Cc: atrajeev@linux.vnet.ibm.com, kjain@linux.ibm.com,
npiggin@gmail.com, Madhavan Srinivasan <maddy@linux.ibm.com>,
christophe.leroy@csgroup.eu, naveen.n.rao@linux.ibm.com,
disgoel@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/3] powerpc/pseries: Export hardware trace macro dump via debugfs
Date: Sat, 22 Jun 2024 13:10:18 +0530 [thread overview]
Message-ID: <87msnd5st9.fsf@gmail.com> (raw)
In-Reply-To: <20240620174614.53751-2-maddy@linux.ibm.com>
This is a generic review and I haven't looked into the PAPR spec for
htmdump hcall and it's interface.
Madhavan Srinivasan <maddy@linux.ibm.com> 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 <maddy@linux.ibm.com>
> ---
> 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 000000000000..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 <linux/bitops.h>
> +#include <linux/string.h>
> +#include <linux/init.h>
> +#include <linux/moduleparam.h>
> +#include <linux/fs.h>
> +#include <linux/debugfs.h>
> +#include <linux/slab.h>
> +#include <linux/memory.h>
> +#include <linux/memory_hotplug.h>
> +#include <linux/numa.h>
> +#include <linux/memblock.h>
> +#include <asm/machdep.h>
> +#include <asm/plpar_wrappers.h>
Do we need all of the above?
e.g. slab, memory_hotplug etc are not needed IMO.
Maybe only?
#include <asm/hvcall.h>
#include <asm/io.h>
#include <asm/machdep.h>
#include <asm/plpar_wrappers.h>
#include <linux/debugfs.h>
#include <linux/module.h>
(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:
> + case H_PARAMETER:
> + case H_P2:
> + case H_P3:
> + case H_P4:
> + case H_P5:
> + case H_P6:
> + case H_STATE:
> + case H_AUTHORITY:
> + return -EINVAL;
> + }
> +
> + available = BUFFER_SIZE - offset;
> + read_size = min(count, available);
> + *ppos += read_size;
> + return simple_read_from_buffer(ubuf, count, &offset, ent->buf, available);
> +}
> +
> +static const struct file_operations htmdump_fops = {
> + .llseek = default_llseek,
> + .read = htmdump_read,
> + .open = simple_open,
> +};
> +
> +static struct dentry *htmdump_debugfs_dir;
> +
> +static int htmdump_init_debugfs(void)
> +{
> + struct htmdump_entry *ent;
> +
> + ent = kcalloc(1, sizeof(struct htmdump_entry), GFP_KERNEL);
> + if (!ent) {
> + pr_err("Failed to allocate ent\n");
> + return -EINVAL;
> + }
> +
> + ent->buf = kmalloc(BUFFER_SIZE, GFP_KERNEL);
> + if (!ent->buf) {
> + pr_err("Failed to allocate htmdump buf\n");
> + return -ENOMEM;
> + }
> +
> + pr_debug("%s: ent:%lx buf:%lx\n",
> + __func__, (long unsigned int)ent, (long unsigned int)ent->buf);
> +
> + htmdump_debugfs_dir = debugfs_create_dir("htmdump",
> + arch_debugfs_dir);
> +
> + debugfs_create_u32("nodeindex", 0600,
> + htmdump_debugfs_dir, &nodeindex);
> + debugfs_create_u32("nodalchipindex", 0600,
> + htmdump_debugfs_dir, &nodalchipindex);
> + debugfs_create_u32("coreindexonchip", 0600,
> + htmdump_debugfs_dir, &coreindexonchip);
> + debugfs_create_u32("htmtype", 0600,
> + htmdump_debugfs_dir, &htmtype);
minor nit: For all of the above. S_IRUSR | S_IWUSR instead of 0600.
> + debugfs_create_file("trace", 0400, htmdump_debugfs_dir, ent, &htmdump_fops);
maybe S_IRUSR instead of 0400.
(makes it more readable).
> +
> + return 0;
> +}
> +
> +static int htmdump_init(void)
maybe put it into __init section?
> +{
> + if (htmdump_init_debugfs())
> + return -EINVAL;
> +
> + return 0;
> +}
> +machine_device_initcall(pseries, htmdump_init);
> --
> 2.45.2
next prev parent reply other threads:[~2024-06-22 8:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 17:46 [PATCH 1/3] powerpc/pseries: Macros and wrapper functions for H_HTM call Madhavan Srinivasan
2024-06-20 17:46 ` [PATCH 2/3] powerpc/pseries: Export hardware trace macro dump via debugfs Madhavan Srinivasan
2024-06-22 7:40 ` Ritesh Harjani [this message]
2024-06-26 3:51 ` Madhavan Srinivasan
2024-06-26 8:12 ` Michael Ellerman
2024-06-26 0:58 ` kernel test robot
2024-06-26 0:58 ` kernel test robot
2024-06-20 17:46 ` [PATCH 3/3] powerpc: Document details on H_HTM hcall Madhavan Srinivasan
2024-06-22 8:27 ` Ritesh Harjani
2024-06-26 3:55 ` Madhavan Srinivasan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87msnd5st9.fsf@gmail.com \
--to=ritesh.list@gmail.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=disgoel@linux.vnet.ibm.com \
--cc=kjain@linux.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=naveen.n.rao@linux.ibm.com \
--cc=npiggin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.