linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2024-06-22  8:28 UTC|newest]

Thread overview: 9+ 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).