2009-11-24 21:10:49 +00:00
|
|
|
/*
|
|
|
|
* Support for dynamic reconfiguration for PCI, Memory, and CPU
|
|
|
|
* Hotplug and Dynamic Logical Partitioning on RPA platforms.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2009 Nathan Fontenot
|
|
|
|
* Copyright (C) 2009 IBM Corporation
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License version
|
|
|
|
* 2 as published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
#define pr_fmt(fmt) "dlpar: " fmt
|
|
|
|
|
2009-11-24 21:10:49 +00:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/notifier.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/cpu.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 08:04:11 +00:00
|
|
|
#include <linux/slab.h>
|
2012-10-02 16:57:57 +00:00
|
|
|
#include <linux/of.h>
|
2015-10-01 09:46:10 +00:00
|
|
|
|
|
|
|
#include "of_helpers.h"
|
2014-08-19 22:55:19 +00:00
|
|
|
#include "pseries.h"
|
2009-11-24 21:10:49 +00:00
|
|
|
|
|
|
|
#include <asm/prom.h>
|
|
|
|
#include <asm/machdep.h>
|
2016-12-24 19:46:01 +00:00
|
|
|
#include <linux/uaccess.h>
|
2009-11-24 21:10:49 +00:00
|
|
|
#include <asm/rtas.h>
|
|
|
|
|
2016-09-06 05:32:40 +00:00
|
|
|
static struct workqueue_struct *pseries_hp_wq;
|
2016-07-07 15:00:34 +00:00
|
|
|
|
|
|
|
struct pseries_hp_work {
|
|
|
|
struct work_struct work;
|
|
|
|
struct pseries_hp_errorlog *errlog;
|
|
|
|
struct completion *hp_completion;
|
|
|
|
int *rc;
|
|
|
|
};
|
|
|
|
|
2009-11-24 21:10:49 +00:00
|
|
|
struct cc_workarea {
|
2014-09-16 20:15:45 +00:00
|
|
|
__be32 drc_index;
|
|
|
|
__be32 zero;
|
|
|
|
__be32 name_offset;
|
|
|
|
__be32 prop_length;
|
|
|
|
__be32 prop_offset;
|
2009-11-24 21:10:49 +00:00
|
|
|
};
|
|
|
|
|
2010-09-10 09:40:32 +00:00
|
|
|
void dlpar_free_cc_property(struct property *prop)
|
2009-11-24 21:10:49 +00:00
|
|
|
{
|
|
|
|
kfree(prop->name);
|
|
|
|
kfree(prop->value);
|
|
|
|
kfree(prop);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct property *dlpar_parse_cc_property(struct cc_workarea *ccwa)
|
|
|
|
{
|
|
|
|
struct property *prop;
|
|
|
|
char *name;
|
|
|
|
char *value;
|
|
|
|
|
|
|
|
prop = kzalloc(sizeof(*prop), GFP_KERNEL);
|
|
|
|
if (!prop)
|
|
|
|
return NULL;
|
|
|
|
|
2014-09-16 20:15:45 +00:00
|
|
|
name = (char *)ccwa + be32_to_cpu(ccwa->name_offset);
|
2009-11-24 21:10:49 +00:00
|
|
|
prop->name = kstrdup(name, GFP_KERNEL);
|
|
|
|
|
2014-09-16 20:15:45 +00:00
|
|
|
prop->length = be32_to_cpu(ccwa->prop_length);
|
|
|
|
value = (char *)ccwa + be32_to_cpu(ccwa->prop_offset);
|
2010-09-15 08:05:49 +00:00
|
|
|
prop->value = kmemdup(value, prop->length, GFP_KERNEL);
|
2009-11-24 21:10:49 +00:00
|
|
|
if (!prop->value) {
|
|
|
|
dlpar_free_cc_property(prop);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return prop;
|
|
|
|
}
|
|
|
|
|
2013-08-15 05:23:50 +00:00
|
|
|
static struct device_node *dlpar_parse_cc_node(struct cc_workarea *ccwa,
|
|
|
|
const char *path)
|
2009-11-24 21:10:49 +00:00
|
|
|
{
|
|
|
|
struct device_node *dn;
|
|
|
|
char *name;
|
|
|
|
|
2013-08-15 05:23:50 +00:00
|
|
|
/* If parent node path is "/" advance path to NULL terminator to
|
|
|
|
* prevent double leading slashs in full_name.
|
|
|
|
*/
|
|
|
|
if (!path[1])
|
|
|
|
path++;
|
|
|
|
|
2009-11-24 21:10:49 +00:00
|
|
|
dn = kzalloc(sizeof(*dn), GFP_KERNEL);
|
|
|
|
if (!dn)
|
|
|
|
return NULL;
|
|
|
|
|
2014-09-16 20:15:45 +00:00
|
|
|
name = (char *)ccwa + be32_to_cpu(ccwa->name_offset);
|
2013-08-15 05:23:50 +00:00
|
|
|
dn->full_name = kasprintf(GFP_KERNEL, "%s/%s", path, name);
|
2009-11-24 21:10:49 +00:00
|
|
|
if (!dn->full_name) {
|
|
|
|
kfree(dn);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-08-15 05:23:49 +00:00
|
|
|
of_node_set_flag(dn, OF_DYNAMIC);
|
2014-07-10 18:50:57 +00:00
|
|
|
of_node_init(dn);
|
2013-08-15 05:23:49 +00:00
|
|
|
|
2009-11-24 21:10:49 +00:00
|
|
|
return dn;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dlpar_free_one_cc_node(struct device_node *dn)
|
|
|
|
{
|
|
|
|
struct property *prop;
|
|
|
|
|
|
|
|
while (dn->properties) {
|
|
|
|
prop = dn->properties;
|
|
|
|
dn->properties = prop->next;
|
|
|
|
dlpar_free_cc_property(prop);
|
|
|
|
}
|
|
|
|
|
|
|
|
kfree(dn->full_name);
|
|
|
|
kfree(dn);
|
|
|
|
}
|
|
|
|
|
2010-09-10 09:40:32 +00:00
|
|
|
void dlpar_free_cc_nodes(struct device_node *dn)
|
2009-11-24 21:10:49 +00:00
|
|
|
{
|
|
|
|
if (dn->child)
|
|
|
|
dlpar_free_cc_nodes(dn->child);
|
|
|
|
|
|
|
|
if (dn->sibling)
|
|
|
|
dlpar_free_cc_nodes(dn->sibling);
|
|
|
|
|
|
|
|
dlpar_free_one_cc_node(dn);
|
|
|
|
}
|
|
|
|
|
2011-08-14 14:30:30 +00:00
|
|
|
#define COMPLETE 0
|
2009-11-24 21:10:49 +00:00
|
|
|
#define NEXT_SIBLING 1
|
|
|
|
#define NEXT_CHILD 2
|
|
|
|
#define NEXT_PROPERTY 3
|
|
|
|
#define PREV_PARENT 4
|
|
|
|
#define MORE_MEMORY 5
|
|
|
|
#define CALL_AGAIN -2
|
|
|
|
#define ERR_CFG_USE -9003
|
|
|
|
|
2014-09-16 20:15:45 +00:00
|
|
|
struct device_node *dlpar_configure_connector(__be32 drc_index,
|
2013-08-15 05:23:50 +00:00
|
|
|
struct device_node *parent)
|
2009-11-24 21:10:49 +00:00
|
|
|
{
|
|
|
|
struct device_node *dn;
|
|
|
|
struct device_node *first_dn = NULL;
|
|
|
|
struct device_node *last_dn = NULL;
|
|
|
|
struct property *property;
|
|
|
|
struct property *last_property = NULL;
|
|
|
|
struct cc_workarea *ccwa;
|
2010-08-18 09:58:46 +00:00
|
|
|
char *data_buf;
|
2013-08-15 05:23:50 +00:00
|
|
|
const char *parent_path = parent->full_name;
|
2009-11-24 21:10:49 +00:00
|
|
|
int cc_token;
|
2010-08-18 09:58:46 +00:00
|
|
|
int rc = -1;
|
2009-11-24 21:10:49 +00:00
|
|
|
|
|
|
|
cc_token = rtas_token("ibm,configure-connector");
|
|
|
|
if (cc_token == RTAS_UNKNOWN_SERVICE)
|
|
|
|
return NULL;
|
|
|
|
|
2010-08-18 09:58:46 +00:00
|
|
|
data_buf = kzalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
|
|
|
|
if (!data_buf)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
ccwa = (struct cc_workarea *)&data_buf[0];
|
2009-11-24 21:10:49 +00:00
|
|
|
ccwa->drc_index = drc_index;
|
|
|
|
ccwa->zero = 0;
|
|
|
|
|
2010-08-18 09:58:46 +00:00
|
|
|
do {
|
|
|
|
/* Since we release the rtas_data_buf lock between configure
|
|
|
|
* connector calls we want to re-populate the rtas_data_buffer
|
|
|
|
* with the contents of the previous call.
|
|
|
|
*/
|
|
|
|
spin_lock(&rtas_data_buf_lock);
|
|
|
|
|
|
|
|
memcpy(rtas_data_buf, data_buf, RTAS_DATA_BUF_SIZE);
|
|
|
|
rc = rtas_call(cc_token, 2, 1, NULL, rtas_data_buf, NULL);
|
|
|
|
memcpy(data_buf, rtas_data_buf, RTAS_DATA_BUF_SIZE);
|
|
|
|
|
|
|
|
spin_unlock(&rtas_data_buf_lock);
|
|
|
|
|
2009-11-24 21:10:49 +00:00
|
|
|
switch (rc) {
|
2011-08-14 14:30:30 +00:00
|
|
|
case COMPLETE:
|
|
|
|
break;
|
|
|
|
|
2009-11-24 21:10:49 +00:00
|
|
|
case NEXT_SIBLING:
|
2013-08-15 05:23:50 +00:00
|
|
|
dn = dlpar_parse_cc_node(ccwa, parent_path);
|
2009-11-24 21:10:49 +00:00
|
|
|
if (!dn)
|
|
|
|
goto cc_error;
|
|
|
|
|
|
|
|
dn->parent = last_dn->parent;
|
|
|
|
last_dn->sibling = dn;
|
|
|
|
last_dn = dn;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case NEXT_CHILD:
|
2013-08-15 05:23:50 +00:00
|
|
|
if (first_dn)
|
|
|
|
parent_path = last_dn->full_name;
|
|
|
|
|
|
|
|
dn = dlpar_parse_cc_node(ccwa, parent_path);
|
2009-11-24 21:10:49 +00:00
|
|
|
if (!dn)
|
|
|
|
goto cc_error;
|
|
|
|
|
2013-08-15 05:23:50 +00:00
|
|
|
if (!first_dn) {
|
|
|
|
dn->parent = parent;
|
2009-11-24 21:10:49 +00:00
|
|
|
first_dn = dn;
|
2013-08-15 05:23:50 +00:00
|
|
|
} else {
|
2009-11-24 21:10:49 +00:00
|
|
|
dn->parent = last_dn;
|
|
|
|
if (last_dn)
|
|
|
|
last_dn->child = dn;
|
|
|
|
}
|
|
|
|
|
|
|
|
last_dn = dn;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case NEXT_PROPERTY:
|
|
|
|
property = dlpar_parse_cc_property(ccwa);
|
|
|
|
if (!property)
|
|
|
|
goto cc_error;
|
|
|
|
|
|
|
|
if (!last_dn->properties)
|
|
|
|
last_dn->properties = property;
|
|
|
|
else
|
|
|
|
last_property->next = property;
|
|
|
|
|
|
|
|
last_property = property;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case PREV_PARENT:
|
|
|
|
last_dn = last_dn->parent;
|
2013-08-15 05:23:50 +00:00
|
|
|
parent_path = last_dn->parent->full_name;
|
2009-11-24 21:10:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case CALL_AGAIN:
|
|
|
|
break;
|
|
|
|
|
|
|
|
case MORE_MEMORY:
|
|
|
|
case ERR_CFG_USE:
|
|
|
|
default:
|
|
|
|
printk(KERN_ERR "Unexpected Error (%d) "
|
|
|
|
"returned from configure-connector\n", rc);
|
|
|
|
goto cc_error;
|
|
|
|
}
|
2010-08-18 09:58:46 +00:00
|
|
|
} while (rc);
|
2009-11-24 21:10:49 +00:00
|
|
|
|
2010-08-18 09:58:46 +00:00
|
|
|
cc_error:
|
|
|
|
kfree(data_buf);
|
|
|
|
|
|
|
|
if (rc) {
|
|
|
|
if (first_dn)
|
|
|
|
dlpar_free_cc_nodes(first_dn);
|
|
|
|
|
|
|
|
return NULL;
|
2009-11-24 21:10:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return first_dn;
|
|
|
|
}
|
|
|
|
|
|
|
|
int dlpar_attach_node(struct device_node *dn)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
2015-10-01 09:46:10 +00:00
|
|
|
dn->parent = pseries_of_derive_parent(dn->full_name);
|
|
|
|
if (IS_ERR(dn->parent))
|
|
|
|
return PTR_ERR(dn->parent);
|
2009-11-24 21:10:49 +00:00
|
|
|
|
2012-10-02 16:57:57 +00:00
|
|
|
rc = of_attach_node(dn);
|
2011-06-21 03:35:55 +00:00
|
|
|
if (rc) {
|
2009-11-24 21:10:49 +00:00
|
|
|
printk(KERN_ERR "Failed to add device node %s\n",
|
|
|
|
dn->full_name);
|
2011-06-21 03:35:55 +00:00
|
|
|
return rc;
|
2009-11-24 21:10:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
of_node_put(dn->parent);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int dlpar_detach_node(struct device_node *dn)
|
|
|
|
{
|
2013-08-15 05:23:52 +00:00
|
|
|
struct device_node *child;
|
2012-10-02 16:57:57 +00:00
|
|
|
int rc;
|
2009-11-24 21:10:49 +00:00
|
|
|
|
2013-08-15 05:23:52 +00:00
|
|
|
child = of_get_next_child(dn, NULL);
|
|
|
|
while (child) {
|
|
|
|
dlpar_detach_node(child);
|
|
|
|
child = of_get_next_child(dn, child);
|
|
|
|
}
|
|
|
|
|
2012-10-02 16:57:57 +00:00
|
|
|
rc = of_detach_node(dn);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
of_node_put(dn); /* Must decrement the refcount */
|
2009-11-24 21:10:49 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define DR_ENTITY_SENSE 9003
|
|
|
|
#define DR_ENTITY_PRESENT 1
|
|
|
|
#define DR_ENTITY_UNUSABLE 2
|
|
|
|
#define ALLOCATION_STATE 9003
|
|
|
|
#define ALLOC_UNUSABLE 0
|
|
|
|
#define ALLOC_USABLE 1
|
|
|
|
#define ISOLATION_STATE 9001
|
|
|
|
#define ISOLATE 0
|
|
|
|
#define UNISOLATE 1
|
|
|
|
|
|
|
|
int dlpar_acquire_drc(u32 drc_index)
|
|
|
|
{
|
|
|
|
int dr_status, rc;
|
|
|
|
|
|
|
|
rc = rtas_call(rtas_token("get-sensor-state"), 2, 2, &dr_status,
|
|
|
|
DR_ENTITY_SENSE, drc_index);
|
|
|
|
if (rc || dr_status != DR_ENTITY_UNUSABLE)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
rc = rtas_set_indicator(ALLOCATION_STATE, drc_index, ALLOC_USABLE);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
rc = rtas_set_indicator(ISOLATION_STATE, drc_index, UNISOLATE);
|
|
|
|
if (rc) {
|
|
|
|
rtas_set_indicator(ALLOCATION_STATE, drc_index, ALLOC_UNUSABLE);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int dlpar_release_drc(u32 drc_index)
|
|
|
|
{
|
|
|
|
int dr_status, rc;
|
|
|
|
|
|
|
|
rc = rtas_call(rtas_token("get-sensor-state"), 2, 2, &dr_status,
|
|
|
|
DR_ENTITY_SENSE, drc_index);
|
|
|
|
if (rc || dr_status != DR_ENTITY_PRESENT)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
rc = rtas_set_indicator(ISOLATION_STATE, drc_index, ISOLATE);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
rc = rtas_set_indicator(ALLOCATION_STATE, drc_index, ALLOC_UNUSABLE);
|
|
|
|
if (rc) {
|
|
|
|
rtas_set_indicator(ISOLATION_STATE, drc_index, UNISOLATE);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
static int handle_dlpar_errorlog(struct pseries_hp_errorlog *hp_elog)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
/* pseries error logs are in BE format, convert to cpu type */
|
|
|
|
switch (hp_elog->id_type) {
|
|
|
|
case PSERIES_HP_ELOG_ID_DRC_COUNT:
|
|
|
|
hp_elog->_drc_u.drc_count =
|
|
|
|
be32_to_cpu(hp_elog->_drc_u.drc_count);
|
|
|
|
break;
|
|
|
|
case PSERIES_HP_ELOG_ID_DRC_INDEX:
|
|
|
|
hp_elog->_drc_u.drc_index =
|
|
|
|
be32_to_cpu(hp_elog->_drc_u.drc_index);
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (hp_elog->resource) {
|
|
|
|
case PSERIES_HP_ELOG_RESOURCE_MEM:
|
|
|
|
rc = dlpar_memory(hp_elog);
|
|
|
|
break;
|
2015-12-16 20:56:02 +00:00
|
|
|
case PSERIES_HP_ELOG_RESOURCE_CPU:
|
|
|
|
rc = dlpar_cpu(hp_elog);
|
|
|
|
break;
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
default:
|
|
|
|
pr_warn_ratelimited("Invalid resource (%d) specified\n",
|
|
|
|
hp_elog->resource);
|
|
|
|
rc = -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2016-09-06 05:32:40 +00:00
|
|
|
static void pseries_hp_work_fn(struct work_struct *work)
|
2016-07-07 15:00:34 +00:00
|
|
|
{
|
|
|
|
struct pseries_hp_work *hp_work =
|
|
|
|
container_of(work, struct pseries_hp_work, work);
|
|
|
|
|
|
|
|
if (hp_work->rc)
|
|
|
|
*(hp_work->rc) = handle_dlpar_errorlog(hp_work->errlog);
|
|
|
|
else
|
|
|
|
handle_dlpar_errorlog(hp_work->errlog);
|
|
|
|
|
|
|
|
if (hp_work->hp_completion)
|
|
|
|
complete(hp_work->hp_completion);
|
|
|
|
|
|
|
|
kfree(hp_work->errlog);
|
|
|
|
kfree((void *)work);
|
|
|
|
}
|
|
|
|
|
|
|
|
void queue_hotplug_event(struct pseries_hp_errorlog *hp_errlog,
|
|
|
|
struct completion *hotplug_done, int *rc)
|
|
|
|
{
|
|
|
|
struct pseries_hp_work *work;
|
|
|
|
struct pseries_hp_errorlog *hp_errlog_copy;
|
|
|
|
|
|
|
|
hp_errlog_copy = kmalloc(sizeof(struct pseries_hp_errorlog),
|
|
|
|
GFP_KERNEL);
|
|
|
|
memcpy(hp_errlog_copy, hp_errlog, sizeof(struct pseries_hp_errorlog));
|
|
|
|
|
|
|
|
work = kmalloc(sizeof(struct pseries_hp_work), GFP_KERNEL);
|
|
|
|
if (work) {
|
|
|
|
INIT_WORK((struct work_struct *)work, pseries_hp_work_fn);
|
|
|
|
work->errlog = hp_errlog_copy;
|
|
|
|
work->hp_completion = hotplug_done;
|
|
|
|
work->rc = rc;
|
|
|
|
queue_work(pseries_hp_wq, (struct work_struct *)work);
|
|
|
|
} else {
|
|
|
|
*rc = -ENOMEM;
|
2016-09-19 06:41:32 +00:00
|
|
|
kfree(hp_errlog_copy);
|
2016-07-07 15:00:34 +00:00
|
|
|
complete(hotplug_done);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-17 16:38:10 +00:00
|
|
|
static int dlpar_parse_resource(char **cmd, struct pseries_hp_errorlog *hp_elog)
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
{
|
2016-11-17 16:38:10 +00:00
|
|
|
char *arg;
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
|
2016-11-17 16:38:10 +00:00
|
|
|
arg = strsep(cmd, " ");
|
|
|
|
if (!arg)
|
|
|
|
return -EINVAL;
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
|
2016-11-17 16:38:10 +00:00
|
|
|
if (sysfs_streq(arg, "memory")) {
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
hp_elog->resource = PSERIES_HP_ELOG_RESOURCE_MEM;
|
2016-11-17 16:38:10 +00:00
|
|
|
} else if (sysfs_streq(arg, "cpu")) {
|
2015-12-16 20:56:02 +00:00
|
|
|
hp_elog->resource = PSERIES_HP_ELOG_RESOURCE_CPU;
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
} else {
|
2016-11-17 16:38:10 +00:00
|
|
|
pr_err("Invalid resource specified.\n");
|
|
|
|
return -EINVAL;
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
}
|
|
|
|
|
2016-11-17 16:38:10 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dlpar_parse_action(char **cmd, struct pseries_hp_errorlog *hp_elog)
|
|
|
|
{
|
|
|
|
char *arg;
|
|
|
|
|
|
|
|
arg = strsep(cmd, " ");
|
|
|
|
if (!arg)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (sysfs_streq(arg, "add")) {
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
hp_elog->action = PSERIES_HP_ELOG_ACTION_ADD;
|
2016-11-17 16:38:10 +00:00
|
|
|
} else if (sysfs_streq(arg, "remove")) {
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
hp_elog->action = PSERIES_HP_ELOG_ACTION_REMOVE;
|
|
|
|
} else {
|
2016-11-17 16:38:10 +00:00
|
|
|
pr_err("Invalid action specified.\n");
|
|
|
|
return -EINVAL;
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
}
|
|
|
|
|
2016-11-17 16:38:10 +00:00
|
|
|
return 0;
|
|
|
|
}
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
|
2016-11-17 16:38:10 +00:00
|
|
|
static int dlpar_parse_id_type(char **cmd, struct pseries_hp_errorlog *hp_elog)
|
|
|
|
{
|
|
|
|
char *arg;
|
|
|
|
u32 count, index;
|
|
|
|
|
|
|
|
arg = strsep(cmd, " ");
|
|
|
|
if (!arg)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (sysfs_streq(arg, "index")) {
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
hp_elog->id_type = PSERIES_HP_ELOG_ID_DRC_INDEX;
|
2016-11-17 16:38:10 +00:00
|
|
|
arg = strsep(cmd, " ");
|
|
|
|
if (!arg) {
|
|
|
|
pr_err("No DRC Index specified.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
if (kstrtou32(arg, 0, &index)) {
|
2016-11-17 16:38:10 +00:00
|
|
|
pr_err("Invalid DRC Index specified.\n");
|
|
|
|
return -EINVAL;
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
hp_elog->_drc_u.drc_index = cpu_to_be32(index);
|
2016-11-17 16:38:10 +00:00
|
|
|
} else if (sysfs_streq(arg, "count")) {
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
hp_elog->id_type = PSERIES_HP_ELOG_ID_DRC_COUNT;
|
2016-11-17 16:38:10 +00:00
|
|
|
arg = strsep(cmd, " ");
|
|
|
|
if (!arg) {
|
|
|
|
pr_err("No DRC count specified.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
if (kstrtou32(arg, 0, &count)) {
|
2016-11-17 16:38:10 +00:00
|
|
|
pr_err("Invalid DRC count specified.\n");
|
|
|
|
return -EINVAL;
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
hp_elog->_drc_u.drc_count = cpu_to_be32(count);
|
|
|
|
} else {
|
2016-11-17 16:38:10 +00:00
|
|
|
pr_err("Invalid id_type specified.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t dlpar_store(struct class *class, struct class_attribute *attr,
|
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
struct pseries_hp_errorlog *hp_elog;
|
|
|
|
struct completion hotplug_done;
|
|
|
|
char *argbuf;
|
|
|
|
char *args;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
args = argbuf = kstrdup(buf, GFP_KERNEL);
|
|
|
|
hp_elog = kzalloc(sizeof(*hp_elog), GFP_KERNEL);
|
|
|
|
if (!hp_elog || !argbuf) {
|
|
|
|
pr_info("Could not allocate resources for DLPAR operation\n");
|
|
|
|
kfree(argbuf);
|
|
|
|
kfree(hp_elog);
|
|
|
|
return -ENOMEM;
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
}
|
|
|
|
|
2016-11-17 16:38:10 +00:00
|
|
|
/*
|
|
|
|
* Parse out the request from the user, this will be in the form:
|
|
|
|
* <resource> <action> <id_type> <id>
|
|
|
|
*/
|
|
|
|
rc = dlpar_parse_resource(&args, hp_elog);
|
|
|
|
if (rc)
|
|
|
|
goto dlpar_store_out;
|
|
|
|
|
|
|
|
rc = dlpar_parse_action(&args, hp_elog);
|
|
|
|
if (rc)
|
|
|
|
goto dlpar_store_out;
|
|
|
|
|
|
|
|
rc = dlpar_parse_id_type(&args, hp_elog);
|
|
|
|
if (rc)
|
|
|
|
goto dlpar_store_out;
|
|
|
|
|
2016-07-07 15:05:52 +00:00
|
|
|
init_completion(&hotplug_done);
|
|
|
|
queue_hotplug_event(hp_elog, &hotplug_done, &rc);
|
|
|
|
wait_for_completion(&hotplug_done);
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
|
|
|
|
dlpar_store_out:
|
2016-11-17 16:38:10 +00:00
|
|
|
kfree(argbuf);
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
kfree(hp_elog);
|
2016-11-17 16:38:10 +00:00
|
|
|
|
|
|
|
if (rc)
|
|
|
|
pr_err("Could not handle DLPAR request \"%s\"\n", buf);
|
|
|
|
|
powerpc/pseries: Create new device hotplug entry point
The current hotplug (or dlpar) of devices (the process is generally the
same for memory, cpu, and pci) on PowerVM systems is initiated
from the HMC, which communicates the request to the partitions through
the RSCT framework. The RSCT framework then invokes the drmgr command.
The drmgr command performs the hotplug operation by doing some pieces,
such as most of the rtas calls and device tree parsing, in userspace
and make requests to the kernel to online/offline the device, update the
device tree and add/remove the device.
For PowerKVM the approach for device hotplug is to follow what is currently
being done for pci hotplug. A hotplug request is initiated from the host.
QEMU then generates an EPOW interrupt to the guest which causes the guest
to make the rtas,check-exception call. In QEMU, the rtas,check-exception call
returns a rtas hotplug event to the guest.
Please note that the current pci hotplug path for PowerKVM involves the
kernel receiving the rtas hotplug event, passing it to rtas_errd in
userspace, and having rtas_errd invoke drmgr. The drmgr command then
handles the request as described above for PowerVM systems.
There is no need for this circuitous route, we should just handle the entire
hotplug of devices in the kernel. What I am planning is to enable this
by moving the code to handle hotplug from drmgr into the kernel to
provide a single path for handling device hotplug for both PowerVM and
PowerKVM systems. This patch provides the common iframework and entry point.
For PowerKVM a future update to the kernel rtas code will recognize rtas
hotplug events returned from rtas,check-exception calls and use the common
entry point to handle hotplug of the device.
For PowerVM systems, This patch creates /sys/kernel/dlpar that can be
used by the drmgr command to initiate hotplug requests. In order to do
this a string of the format "<resource> <action> <id_type> <id>" is
written to this file. The string consists of a resource (cpu, memory, pci,
phb), an action (add or remove), an id_type (count, drc index, drc name),
and the corresponding id. The kernel will parse the string and create a
rtas hotplug section that can be passed to the common entry point for
handling hotplug requests.
It should be noted that there is no chance of updating how we receive
hotplug (dlpar) requests from the HMC on PowerVM systems.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2015-02-10 19:47:02 +00:00
|
|
|
return rc ? rc : count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static CLASS_ATTR(dlpar, S_IWUSR, NULL, dlpar_store);
|
|
|
|
|
2009-11-24 21:13:32 +00:00
|
|
|
static int __init pseries_dlpar_init(void)
|
|
|
|
{
|
2016-07-07 15:00:34 +00:00
|
|
|
pseries_hp_wq = alloc_workqueue("pseries hotplug workqueue",
|
|
|
|
WQ_UNBOUND, 1);
|
2015-12-16 20:50:21 +00:00
|
|
|
return sysfs_create_file(kernel_kobj, &class_attr_dlpar.attr);
|
2009-11-24 21:13:32 +00:00
|
|
|
}
|
|
|
|
machine_device_initcall(pseries, pseries_dlpar_init);
|
|
|
|
|