From: Michael Ellerman <mpe@ellerman.id.au>
To: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [3/5] pseries: Create device hotplug entry point
Date: Wed, 17 Sep 2014 17:07:12 +1000 [thread overview]
Message-ID: <1410937632.27681.11.camel@concordia> (raw)
In-Reply-To: <54174CB7.2080704@linux.vnet.ibm.com>
On Mon, 2014-09-15 at 15:31 -0500, Nathan Fontenot wrote:
> For pseries system the kernel will be notified of hotplug requests in
> the form of rtas hotplug events.
Can you flesh that design out a bit for me, I don't entirely get how it's going
to work.
The kernel gets the rtas hotplug events (in rtasd.c) and spits them out to
userspace, which then writes them back in ?
> This patch creates a common routine that can handle these requests in both
> the PowerVM anbd PowerKVM environments, handle_dlpar_errorlog(). This also
^
> creates the initial memory hotplug request handling stub.
>
> For PowerVM this patch also creates a new /proc file that the drmgr
> command will use to write rtas hotplug events to.
Why is this different between phyp and KVM?
> For future PowerKVM handling the rtas check-exception code can pass
> any rtas hotplug events received to handle_dlpar_errorlog().
Internally to the kernel you mean?
> diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
> index a2450b8..574ec73 100644
> --- a/arch/powerpc/platforms/pseries/dlpar.c
> +++ b/arch/powerpc/platforms/pseries/dlpar.c
> @@ -16,7 +16,9 @@
> #include <linux/cpu.h>
> #include <linux/slab.h>
> #include <linux/of.h>
> +#include <linux/proc_fs.h>
> #include "offline_states.h"
> +#include "pseries.h"
>
> #include <asm/prom.h>
> #include <asm/machdep.h>
> @@ -530,13 +532,72 @@ static ssize_t dlpar_cpu_release(const char *buf, size_t count)
> return count;
> }
>
> +#endif /* CONFIG_ARCH_CPU_PROBE_RELEASE */
That is really confusing, but I think it's just a diff artifact?
> +static int handle_dlpar_errorlog(struct rtas_error_log *error_log)
> +{
> + struct pseries_errorlog *pseries_log;
> + struct pseries_hp_errorlog *hp_elog;
> + int rc = -EINVAL;
> +
> + pseries_log = get_pseries_errorlog(error_log,
> + PSERIES_ELOG_SECT_ID_HOTPLUG);
> + if (!pseries_log)
> + return rc;
> +
> + hp_elog = (struct pseries_hp_errorlog *)pseries_log->data;
> + if (!hp_elog)
> + return rc;
I don't see how that can happen?
struct pseries_errorlog {
__be16 id; /* 0x00 2-byte ASCII section ID */
__be16 length; /* 0x02 Section length in bytes */
uint8_t version; /* 0x04 Section version */
uint8_t subtype; /* 0x05 Section subtype */
__be16 creator_component; /* 0x06 Creator component ID */
uint8_t data[]; /* 0x08 Start of section data */
};
Should you be checking for length == 0 instead ?
Also I think the code will probably end up cleaner if you do the endian
conversions immediately when you read the hp_elog, rather than passing it
around in BE and having to remember to convert at all the usages.
> + switch (hp_elog->resource) {
> + case PSERIES_HP_ELOG_RESOURCE_MEM:
> + rc = dlpar_memory(hp_elog);
> + break;
Please add:
default:
pr_warn_ratelimited("Unknown resource ..")
Or something.
> + }
> +
> + return rc;
> +}
> +
> +static ssize_t dlpar_write(struct file *file, const char __user *buf,
> + size_t count, loff_t *offset)
> +{
> + char *event_buf;
> + int rc;
> +
> + event_buf = kmalloc(count + 1, GFP_KERNEL);
Why + 1 ? It's not null-terminated AFAICS.
> + if (!event_buf)
> + return -ENOMEM;
> +
> + rc = copy_from_user(event_buf, buf, count);
> + if (rc) {
> + kfree(event_buf);
> + return rc;
> + }
> +
> + rc = handle_dlpar_errorlog((struct rtas_error_log *)event_buf);
If you start with a struct rtas_error_log * you shouldn't need any casts.
> + kfree(event_buf);
> + return rc ? rc : count;
> +}
> +
> +static const struct file_operations dlpar_fops = {
> + .write = dlpar_write,
> + .llseek = noop_llseek,
> +};
> +
> static int __init pseries_dlpar_init(void)
> {
> + struct proc_dir_entry *proc_ent;
> +
> + proc_ent = proc_create("powerpc/dlpar", S_IWUSR, NULL, &dlpar_fops);
> + if (proc_ent)
> + proc_set_size(proc_ent, 0);
else
error message at least please
Why are we putting it in /proc, can't it go in /sys/kernel like the mobility
stuff?
> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 24abc5c..0e60e15 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -20,6 +22,9 @@
> #include <asm/machdep.h>
> #include <asm/prom.h>
> #include <asm/sparsemem.h>
> +#include <asm/rtas.h>
> +
> +DEFINE_MUTEX(dlpar_mem_mutex);
static ?
> diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h
> index b94516b..28bd994 100644
> --- a/arch/powerpc/platforms/pseries/pseries.h
> +++ b/arch/powerpc/platforms/pseries/pseries.h
> @@ -62,6 +63,15 @@ extern int dlpar_detach_node(struct device_node *);
> extern int dlpar_acquire_drc(u32);
> extern int dlpar_release_drc(u32);
>
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +extern int dlpar_memory(struct pseries_hp_errorlog *);
> +#else
> +static inline int dlpar_memory(struct pseries_hp_errorlog *hp_elog)
> +{
> + return -ENOTSUPP;
EOPNOTSUPP is a bit more standard.
cheers
next prev parent reply other threads:[~2014-09-17 7:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-15 20:26 [PATCH 0/5] pseries: Move memory hotplug to the kernel Nathan Fontenot
2014-09-15 20:29 ` [PATCH 1/5] pseries: Define rtas hotplug event sections Nathan Fontenot
2014-09-17 7:06 ` [1/5] " Michael Ellerman
2014-09-17 16:49 ` Nathan Fontenot
2014-09-15 20:30 ` [PATCH 2/5] pseries: Export drc_[acquire|release]_drc() routines Nathan Fontenot
2014-09-17 7:07 ` [2/5] " Michael Ellerman
2014-09-17 16:50 ` Nathan Fontenot
2014-09-15 20:31 ` [PATCH 3/5] pseries: Create device hotplug entry point Nathan Fontenot
2014-09-17 7:07 ` Michael Ellerman [this message]
2014-09-17 19:15 ` [3/5] " Nathan Fontenot
2014-09-23 1:15 ` Tyrel Datwyler
2014-09-23 14:43 ` Nathan Fontenot
2014-09-15 20:32 ` [PATCH 4/5] pseries: Implement memory hotplug add in the kernel Nathan Fontenot
2014-09-17 7:07 ` [4/5] " Michael Ellerman
2014-09-17 19:45 ` Nathan Fontenot
2014-09-24 20:57 ` Nathan Fontenot
2014-09-15 20:33 ` [PATCH 5/5] pseries: Implement memory hotplug remove " Nathan Fontenot
2014-09-17 7:07 ` [5/5] " Michael Ellerman
2014-09-17 19:58 ` Nathan Fontenot
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=1410937632.27681.11.camel@concordia \
--to=mpe@ellerman.id.au \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=nfont@linux.vnet.ibm.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).