2019-06-04 10:11:33 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
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
|
|
|
|
*/
|
|
|
|
|
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 13:47:02 -06: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 17:04:11 +09:00
|
|
|
#include <linux/slab.h>
|
2012-10-02 16:57:57 +00:00
|
|
|
#include <linux/of.h>
|
2015-10-01 12:46:10 +03:00
|
|
|
|
|
|
|
#include "of_helpers.h"
|
2014-08-20 08:55:19 +10:00
|
|
|
#include "pseries.h"
|
2009-11-24 21:10:49 +00:00
|
|
|
|
|
|
|
#include <asm/machdep.h>
|
2016-12-24 11:46:01 -08:00
|
|
|
#include <linux/uaccess.h>
|
2009-11-24 21:10:49 +00:00
|
|
|
#include <asm/rtas.h>
|
2023-02-10 12:42:01 -06:00
|
|
|
#include <asm/rtas-work-area.h>
|
2024-08-21 19:50:28 -07:00
|
|
|
#include <asm/prom.h>
|
2009-11-24 21:10:49 +00:00
|
|
|
|
2016-09-06 15:32:40 +10:00
|
|
|
static struct workqueue_struct *pseries_hp_wq;
|
2016-07-07 10:00:34 -05:00
|
|
|
|
|
|
|
struct pseries_hp_work {
|
|
|
|
struct work_struct work;
|
|
|
|
struct pseries_hp_errorlog *errlog;
|
|
|
|
};
|
|
|
|
|
2009-11-24 21:10:49 +00:00
|
|
|
struct cc_workarea {
|
2014-09-16 15:15:45 -05: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 15:15:45 -05:00
|
|
|
name = (char *)ccwa + be32_to_cpu(ccwa->name_offset);
|
2009-11-24 21:10:49 +00:00
|
|
|
prop->name = kstrdup(name, GFP_KERNEL);
|
2019-05-26 10:42:40 +08:00
|
|
|
if (!prop->name) {
|
|
|
|
dlpar_free_cc_property(prop);
|
|
|
|
return NULL;
|
|
|
|
}
|
2009-11-24 21:10:49 +00:00
|
|
|
|
2014-09-16 15:15:45 -05: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;
|
|
|
|
}
|
|
|
|
|
2017-07-25 16:10:06 -05:00
|
|
|
static struct device_node *dlpar_parse_cc_node(struct cc_workarea *ccwa)
|
2009-11-24 21:10:49 +00:00
|
|
|
{
|
|
|
|
struct device_node *dn;
|
2017-07-25 16:10:06 -05:00
|
|
|
const char *name;
|
2013-08-14 22:23:50 -07:00
|
|
|
|
2009-11-24 21:10:49 +00:00
|
|
|
dn = kzalloc(sizeof(*dn), GFP_KERNEL);
|
|
|
|
if (!dn)
|
|
|
|
return NULL;
|
|
|
|
|
2017-07-25 16:10:06 -05:00
|
|
|
name = (const char *)ccwa + be32_to_cpu(ccwa->name_offset);
|
|
|
|
dn->full_name = kstrdup(name, GFP_KERNEL);
|
2009-11-24 21:10:49 +00:00
|
|
|
if (!dn->full_name) {
|
|
|
|
kfree(dn);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-08-14 22:23:49 -07:00
|
|
|
of_node_set_flag(dn, OF_DYNAMIC);
|
2014-07-10 14:50:57 -04:00
|
|
|
of_node_init(dn);
|
2013-08-14 22:23:49 -07: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 ERR_CFG_USE -9003
|
|
|
|
|
2014-09-16 15:15:45 -05:00
|
|
|
struct device_node *dlpar_configure_connector(__be32 drc_index,
|
2013-08-14 22:23:50 -07: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;
|
2023-02-10 12:42:01 -06:00
|
|
|
struct rtas_work_area *work_area;
|
2010-08-18 09:58:46 +00:00
|
|
|
char *data_buf;
|
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
|
|
|
|
2023-02-10 12:42:08 -06:00
|
|
|
cc_token = rtas_function_token(RTAS_FN_IBM_CONFIGURE_CONNECTOR);
|
2009-11-24 21:10:49 +00:00
|
|
|
if (cc_token == RTAS_UNKNOWN_SERVICE)
|
|
|
|
return NULL;
|
|
|
|
|
2023-02-10 12:42:01 -06:00
|
|
|
work_area = rtas_work_area_alloc(SZ_4K);
|
|
|
|
data_buf = rtas_work_area_raw_buf(work_area);
|
2010-08-18 09:58:46 +00:00
|
|
|
|
|
|
|
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 {
|
2023-02-10 12:42:01 -06:00
|
|
|
do {
|
|
|
|
rc = rtas_call(cc_token, 2, 1, NULL,
|
|
|
|
rtas_work_area_phys(work_area), NULL);
|
|
|
|
} while (rtas_busy_delay(rc));
|
2021-01-06 20:59:00 -06:00
|
|
|
|
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:
|
2017-07-25 16:10:06 -05:00
|
|
|
dn = dlpar_parse_cc_node(ccwa);
|
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:
|
2017-07-25 16:10:06 -05:00
|
|
|
dn = dlpar_parse_cc_node(ccwa);
|
2009-11-24 21:10:49 +00:00
|
|
|
if (!dn)
|
|
|
|
goto cc_error;
|
|
|
|
|
2013-08-14 22:23:50 -07:00
|
|
|
if (!first_dn) {
|
|
|
|
dn->parent = parent;
|
2009-11-24 21:10:49 +00:00
|
|
|
first_dn = dn;
|
2013-08-14 22:23:50 -07: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;
|
|
|
|
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:
|
2023-02-10 12:42:01 -06:00
|
|
|
rtas_work_area_free(work_area);
|
2010-08-18 09:58:46 +00:00
|
|
|
|
|
|
|
if (rc) {
|
|
|
|
if (first_dn)
|
|
|
|
dlpar_free_cc_nodes(first_dn);
|
|
|
|
|
|
|
|
return NULL;
|
2009-11-24 21:10:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return first_dn;
|
|
|
|
}
|
|
|
|
|
2017-08-21 10:16:49 -05:00
|
|
|
int dlpar_attach_node(struct device_node *dn, struct device_node *parent)
|
2009-11-24 21:10:49 +00:00
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
2017-08-21 10:16:49 -05:00
|
|
|
dn->parent = 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) {
|
2017-08-21 10:16:47 -05:00
|
|
|
printk(KERN_ERR "Failed to add device node %pOF\n", dn);
|
2011-06-21 03:35:55 +00:00
|
|
|
return rc;
|
2009-11-24 21:10:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int dlpar_detach_node(struct device_node *dn)
|
|
|
|
{
|
2013-08-14 22:23:52 -07:00
|
|
|
struct device_node *child;
|
2012-10-02 16:57:57 +00:00
|
|
|
int rc;
|
2009-11-24 21:10:49 +00:00
|
|
|
|
2024-08-22 16:54:30 +08:00
|
|
|
for_each_child_of_node(dn, child)
|
2013-08-14 22:23:52 -07:00
|
|
|
dlpar_detach_node(child);
|
|
|
|
|
2012-10-02 16:57:57 +00:00
|
|
|
rc = of_detach_node(dn);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
2018-10-04 20:27:16 -07:00
|
|
|
of_node_put(dn);
|
|
|
|
|
2009-11-24 21:10:49 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2024-08-21 19:50:28 -07:00
|
|
|
static int dlpar_changeset_attach_cc_nodes(struct of_changeset *ocs,
|
|
|
|
struct device_node *dn)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = of_changeset_attach_node(ocs, dn);
|
|
|
|
|
|
|
|
if (!rc && dn->child)
|
|
|
|
rc = dlpar_changeset_attach_cc_nodes(ocs, dn->child);
|
|
|
|
if (!rc && dn->sibling)
|
|
|
|
rc = dlpar_changeset_attach_cc_nodes(ocs, dn->sibling);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
2009-11-24 21:10:49 +00:00
|
|
|
|
|
|
|
#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;
|
|
|
|
|
2021-05-03 21:53:29 -05:00
|
|
|
rc = rtas_get_sensor(DR_ENTITY_SENSE, drc_index, &dr_status);
|
2009-11-24 21:10:49 +00:00
|
|
|
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;
|
|
|
|
|
2021-05-03 21:53:29 -05:00
|
|
|
rc = rtas_get_sensor(DR_ENTITY_SENSE, drc_index, &dr_status);
|
2009-11-24 21:10:49 +00:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2021-04-16 18:02:15 -03:00
|
|
|
int dlpar_unisolate_drc(u32 drc_index)
|
|
|
|
{
|
|
|
|
int dr_status, rc;
|
|
|
|
|
2021-05-03 21:53:29 -05:00
|
|
|
rc = rtas_get_sensor(DR_ENTITY_SENSE, drc_index, &dr_status);
|
2021-04-16 18:02:15 -03:00
|
|
|
if (rc || dr_status != DR_ENTITY_PRESENT)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
rtas_set_indicator(ISOLATION_STATE, drc_index, UNISOLATE);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-08-21 19:50:28 -07:00
|
|
|
static struct device_node *
|
|
|
|
get_device_node_with_drc_index(u32 index)
|
|
|
|
{
|
|
|
|
struct device_node *np = NULL;
|
|
|
|
u32 node_index;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
for_each_node_with_property(np, "ibm,my-drc-index") {
|
|
|
|
rc = of_property_read_u32(np, "ibm,my-drc-index",
|
|
|
|
&node_index);
|
|
|
|
if (rc) {
|
|
|
|
pr_err("%s: %pOF: of_property_read_u32 %s: %d\n",
|
|
|
|
__func__, np, "ibm,my-drc-index", rc);
|
|
|
|
of_node_put(np);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (index == node_index)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return np;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct device_node *
|
|
|
|
get_device_node_with_drc_info(u32 index)
|
|
|
|
{
|
|
|
|
struct device_node *np = NULL;
|
|
|
|
struct of_drc_info drc;
|
|
|
|
struct property *info;
|
|
|
|
const __be32 *value;
|
|
|
|
u32 node_index;
|
|
|
|
int i, j, count;
|
|
|
|
|
|
|
|
for_each_node_with_property(np, "ibm,drc-info") {
|
|
|
|
info = of_find_property(np, "ibm,drc-info", NULL);
|
|
|
|
if (info == NULL) {
|
|
|
|
/* XXX can this happen? */
|
|
|
|
of_node_put(np);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
value = of_prop_next_u32(info, NULL, &count);
|
|
|
|
if (value == NULL)
|
|
|
|
continue;
|
|
|
|
value++;
|
|
|
|
for (i = 0; i < count; i++) {
|
|
|
|
if (of_read_drc_info_cell(&info, &value, &drc))
|
|
|
|
break;
|
|
|
|
if (index > drc.last_drc_index)
|
|
|
|
continue;
|
|
|
|
node_index = drc.drc_index_start;
|
|
|
|
for (j = 0; j < drc.num_sequential_elems; j++) {
|
|
|
|
if (index == node_index)
|
|
|
|
return np;
|
|
|
|
node_index += drc.sequential_inc;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2025-05-31 16:50:02 -07:00
|
|
|
static struct device_node *
|
|
|
|
get_device_node_with_drc_indexes(u32 drc_index)
|
|
|
|
{
|
|
|
|
struct device_node *np = NULL;
|
|
|
|
u32 nr_indexes, index;
|
|
|
|
int i, rc;
|
|
|
|
|
|
|
|
for_each_node_with_property(np, "ibm,drc-indexes") {
|
|
|
|
/*
|
|
|
|
* First element in the array is the total number of
|
|
|
|
* DRC indexes returned.
|
|
|
|
*/
|
|
|
|
rc = of_property_read_u32_index(np, "ibm,drc-indexes",
|
|
|
|
0, &nr_indexes);
|
|
|
|
if (rc)
|
|
|
|
goto out_put_np;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Retrieve DRC index from the list and return the
|
|
|
|
* device node if matched with the specified index.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < nr_indexes; i++) {
|
|
|
|
rc = of_property_read_u32_index(np, "ibm,drc-indexes",
|
|
|
|
i+1, &index);
|
|
|
|
if (rc)
|
|
|
|
goto out_put_np;
|
|
|
|
|
|
|
|
if (drc_index == index)
|
|
|
|
return np;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
out_put_np:
|
|
|
|
of_node_put(np);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2024-08-21 19:50:28 -07:00
|
|
|
static int dlpar_hp_dt_add(u32 index)
|
|
|
|
{
|
|
|
|
struct device_node *np, *nodes;
|
|
|
|
struct of_changeset ocs;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Do not add device node(s) if already exists in the
|
|
|
|
* device tree.
|
|
|
|
*/
|
|
|
|
np = get_device_node_with_drc_index(index);
|
|
|
|
if (np) {
|
|
|
|
pr_err("%s: Adding device node for index (%d), but "
|
|
|
|
"already exists in the device tree\n",
|
|
|
|
__func__, index);
|
|
|
|
rc = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2025-05-31 16:50:02 -07:00
|
|
|
/*
|
|
|
|
* Recent FW provides ibm,drc-info property. So search
|
|
|
|
* for the user specified DRC index from ibm,drc-info
|
|
|
|
* property. If this property is not available, search
|
|
|
|
* in the indexes array from ibm,drc-indexes property.
|
|
|
|
*/
|
2024-08-21 19:50:28 -07:00
|
|
|
np = get_device_node_with_drc_info(index);
|
|
|
|
|
2025-05-31 16:50:02 -07:00
|
|
|
if (!np) {
|
|
|
|
np = get_device_node_with_drc_indexes(index);
|
|
|
|
if (!np)
|
|
|
|
return -EIO;
|
|
|
|
}
|
2024-08-21 19:50:28 -07:00
|
|
|
|
|
|
|
/* Next, configure the connector. */
|
|
|
|
nodes = dlpar_configure_connector(cpu_to_be32(index), np);
|
|
|
|
if (!nodes) {
|
|
|
|
rc = -EIO;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add the new nodes from dlpar_configure_connector() onto
|
|
|
|
* the device-tree.
|
|
|
|
*/
|
|
|
|
of_changeset_init(&ocs);
|
|
|
|
rc = dlpar_changeset_attach_cc_nodes(&ocs, nodes);
|
|
|
|
|
|
|
|
if (!rc)
|
|
|
|
rc = of_changeset_apply(&ocs);
|
|
|
|
else
|
|
|
|
dlpar_free_cc_nodes(nodes);
|
|
|
|
|
|
|
|
of_changeset_destroy(&ocs);
|
|
|
|
|
|
|
|
out:
|
|
|
|
of_node_put(np);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2024-08-21 19:50:27 -07:00
|
|
|
static int changeset_detach_node_recursive(struct of_changeset *ocs,
|
|
|
|
struct device_node *node)
|
|
|
|
{
|
|
|
|
struct device_node *child;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
for_each_child_of_node(node, child) {
|
|
|
|
rc = changeset_detach_node_recursive(ocs, child);
|
|
|
|
if (rc) {
|
|
|
|
of_node_put(child);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return of_changeset_detach_node(ocs, node);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dlpar_hp_dt_remove(u32 drc_index)
|
|
|
|
{
|
|
|
|
struct device_node *np;
|
|
|
|
struct of_changeset ocs;
|
|
|
|
u32 index;
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prune all nodes with a matching index.
|
|
|
|
*/
|
|
|
|
of_changeset_init(&ocs);
|
|
|
|
|
|
|
|
for_each_node_with_property(np, "ibm,my-drc-index") {
|
|
|
|
rc = of_property_read_u32(np, "ibm,my-drc-index", &index);
|
|
|
|
if (rc) {
|
|
|
|
pr_err("%s: %pOF: of_property_read_u32 %s: %d\n",
|
|
|
|
__func__, np, "ibm,my-drc-index", rc);
|
|
|
|
of_node_put(np);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (index == drc_index) {
|
|
|
|
rc = changeset_detach_node_recursive(&ocs, np);
|
|
|
|
if (rc) {
|
|
|
|
of_node_put(np);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
rc = of_changeset_apply(&ocs);
|
|
|
|
|
|
|
|
out:
|
|
|
|
of_changeset_destroy(&ocs);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dlpar_hp_dt(struct pseries_hp_errorlog *phpe)
|
|
|
|
{
|
|
|
|
u32 drc_index;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
if (phpe->id_type != PSERIES_HP_ELOG_ID_DRC_INDEX)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
drc_index = be32_to_cpu(phpe->_drc_u.drc_index);
|
|
|
|
|
|
|
|
lock_device_hotplug();
|
|
|
|
|
|
|
|
switch (phpe->action) {
|
2024-08-21 19:50:28 -07:00
|
|
|
case PSERIES_HP_ELOG_ACTION_ADD:
|
|
|
|
rc = dlpar_hp_dt_add(drc_index);
|
|
|
|
break;
|
2024-08-21 19:50:27 -07:00
|
|
|
case PSERIES_HP_ELOG_ACTION_REMOVE:
|
|
|
|
rc = dlpar_hp_dt_remove(drc_index);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
pr_err("Invalid action (%d) specified\n", phpe->action);
|
|
|
|
rc = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
unlock_device_hotplug();
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2018-09-10 09:57:07 -05:00
|
|
|
int handle_dlpar_errorlog(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 13:47:02 -06:00
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
switch (hp_elog->resource) {
|
|
|
|
case PSERIES_HP_ELOG_RESOURCE_MEM:
|
|
|
|
rc = dlpar_memory(hp_elog);
|
|
|
|
break;
|
2015-12-16 14:56:02 -06:00
|
|
|
case PSERIES_HP_ELOG_RESOURCE_CPU:
|
|
|
|
rc = dlpar_cpu(hp_elog);
|
|
|
|
break;
|
2018-10-15 10:18:27 +11:00
|
|
|
case PSERIES_HP_ELOG_RESOURCE_PMEM:
|
|
|
|
rc = dlpar_hp_pmem(hp_elog);
|
|
|
|
break;
|
2024-08-21 19:50:27 -07:00
|
|
|
case PSERIES_HP_ELOG_RESOURCE_DT:
|
|
|
|
rc = dlpar_hp_dt(hp_elog);
|
|
|
|
break;
|
2018-10-15 10:18:27 +11:00
|
|
|
|
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 13:47:02 -06:00
|
|
|
default:
|
|
|
|
pr_warn_ratelimited("Invalid resource (%d) specified\n",
|
|
|
|
hp_elog->resource);
|
|
|
|
rc = -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2016-09-06 15:32:40 +10:00
|
|
|
static void pseries_hp_work_fn(struct work_struct *work)
|
2016-07-07 10:00:34 -05:00
|
|
|
{
|
|
|
|
struct pseries_hp_work *hp_work =
|
|
|
|
container_of(work, struct pseries_hp_work, work);
|
|
|
|
|
2018-09-10 09:57:07 -05:00
|
|
|
handle_dlpar_errorlog(hp_work->errlog);
|
2016-07-07 10:00:34 -05:00
|
|
|
|
|
|
|
kfree(hp_work->errlog);
|
2020-07-08 07:22:28 +00:00
|
|
|
kfree(work);
|
2016-07-07 10:00:34 -05:00
|
|
|
}
|
|
|
|
|
2018-09-10 09:57:07 -05:00
|
|
|
void queue_hotplug_event(struct pseries_hp_errorlog *hp_errlog)
|
2016-07-07 10:00:34 -05:00
|
|
|
{
|
|
|
|
struct pseries_hp_work *work;
|
|
|
|
struct pseries_hp_errorlog *hp_errlog_copy;
|
|
|
|
|
2019-05-28 18:28:01 -05:00
|
|
|
hp_errlog_copy = kmemdup(hp_errlog, sizeof(*hp_errlog), GFP_ATOMIC);
|
|
|
|
if (!hp_errlog_copy)
|
|
|
|
return;
|
2016-07-07 10:00:34 -05:00
|
|
|
|
2019-05-28 18:28:01 -05:00
|
|
|
work = kmalloc(sizeof(struct pseries_hp_work), GFP_ATOMIC);
|
2016-07-07 10:00:34 -05:00
|
|
|
if (work) {
|
|
|
|
INIT_WORK((struct work_struct *)work, pseries_hp_work_fn);
|
|
|
|
work->errlog = hp_errlog_copy;
|
|
|
|
queue_work(pseries_hp_wq, (struct work_struct *)work);
|
|
|
|
} else {
|
2016-09-19 16:41:32 +10:00
|
|
|
kfree(hp_errlog_copy);
|
2016-07-07 10:00:34 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
{
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
hp_elog->resource = PSERIES_HP_ELOG_RESOURCE_MEM;
|
2016-11-17 11:38:10 -05:00
|
|
|
} else if (sysfs_streq(arg, "cpu")) {
|
2015-12-16 14:56:02 -06:00
|
|
|
hp_elog->resource = PSERIES_HP_ELOG_RESOURCE_CPU;
|
2024-08-21 19:50:27 -07:00
|
|
|
} else if (sysfs_streq(arg, "dt")) {
|
|
|
|
hp_elog->resource = PSERIES_HP_ELOG_RESOURCE_DT;
|
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 13:47:02 -06:00
|
|
|
} else {
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
}
|
|
|
|
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
hp_elog->action = PSERIES_HP_ELOG_ACTION_ADD;
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
hp_elog->action = PSERIES_HP_ELOG_ACTION_REMOVE;
|
|
|
|
} else {
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
}
|
|
|
|
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
|
2016-11-17 11:38:10 -05: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;
|
|
|
|
|
2017-02-15 13:45:56 -05:00
|
|
|
if (sysfs_streq(arg, "indexed-count")) {
|
|
|
|
hp_elog->id_type = PSERIES_HP_ELOG_ID_DRC_IC;
|
|
|
|
arg = strsep(cmd, " ");
|
|
|
|
if (!arg) {
|
|
|
|
pr_err("No DRC count specified.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (kstrtou32(arg, 0, &count)) {
|
|
|
|
pr_err("Invalid DRC count specified.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
arg = strsep(cmd, " ");
|
|
|
|
if (!arg) {
|
|
|
|
pr_err("No DRC Index specified.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (kstrtou32(arg, 0, &index)) {
|
|
|
|
pr_err("Invalid DRC Index specified.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
hp_elog->_drc_u.ic.count = cpu_to_be32(count);
|
|
|
|
hp_elog->_drc_u.ic.index = cpu_to_be32(index);
|
|
|
|
} else 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 13:47:02 -06:00
|
|
|
hp_elog->id_type = PSERIES_HP_ELOG_ID_DRC_INDEX;
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
if (kstrtou32(arg, 0, &index)) {
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
hp_elog->_drc_u.drc_index = cpu_to_be32(index);
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
hp_elog->id_type = PSERIES_HP_ELOG_ID_DRC_COUNT;
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
if (kstrtou32(arg, 0, &count)) {
|
2016-11-17 11:38:10 -05: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 13:47:02 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
hp_elog->_drc_u.drc_count = cpu_to_be32(count);
|
|
|
|
} else {
|
2016-11-17 11:38:10 -05:00
|
|
|
pr_err("Invalid id_type specified.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-03-25 09:45:37 +01:00
|
|
|
static ssize_t dlpar_store(const struct class *class, const struct class_attribute *attr,
|
2016-11-17 11:38:10 -05:00
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
2018-09-10 09:57:07 -05:00
|
|
|
struct pseries_hp_errorlog hp_elog;
|
2016-11-17 11:38:10 -05:00
|
|
|
char *argbuf;
|
|
|
|
char *args;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
args = argbuf = kstrdup(buf, GFP_KERNEL);
|
2019-08-27 13:37:56 +02:00
|
|
|
if (!argbuf)
|
2016-11-17 11:38:10 -05:00
|
|
|
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 13:47:02 -06:00
|
|
|
|
2016-11-17 11:38:10 -05:00
|
|
|
/*
|
|
|
|
* Parse out the request from the user, this will be in the form:
|
|
|
|
* <resource> <action> <id_type> <id>
|
|
|
|
*/
|
2018-09-10 09:57:07 -05:00
|
|
|
rc = dlpar_parse_resource(&args, &hp_elog);
|
2016-11-17 11:38:10 -05:00
|
|
|
if (rc)
|
|
|
|
goto dlpar_store_out;
|
|
|
|
|
2018-09-10 09:57:07 -05:00
|
|
|
rc = dlpar_parse_action(&args, &hp_elog);
|
2016-11-17 11:38:10 -05:00
|
|
|
if (rc)
|
|
|
|
goto dlpar_store_out;
|
|
|
|
|
2018-09-10 09:57:07 -05:00
|
|
|
rc = dlpar_parse_id_type(&args, &hp_elog);
|
2016-11-17 11:38:10 -05:00
|
|
|
if (rc)
|
|
|
|
goto dlpar_store_out;
|
|
|
|
|
2018-09-10 09:57:07 -05:00
|
|
|
rc = handle_dlpar_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 13:47:02 -06:00
|
|
|
|
|
|
|
dlpar_store_out:
|
2016-11-17 11:38:10 -05:00
|
|
|
kfree(argbuf);
|
|
|
|
|
|
|
|
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 13:47:02 -06:00
|
|
|
return rc ? rc : count;
|
|
|
|
}
|
|
|
|
|
2023-03-25 09:45:37 +01:00
|
|
|
static ssize_t dlpar_show(const struct class *class, const struct class_attribute *attr,
|
2017-01-11 12:00:58 -05:00
|
|
|
char *buf)
|
|
|
|
{
|
2024-08-21 19:50:27 -07:00
|
|
|
return sprintf(buf, "%s\n", "memory,cpu,dt");
|
2017-01-11 12:00:58 -05:00
|
|
|
}
|
|
|
|
|
2017-06-06 15:32:03 +02:00
|
|
|
static CLASS_ATTR_RW(dlpar);
|
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 13:47:02 -06:00
|
|
|
|
powerpc/pseries: Make RAS IRQ explicitly dependent on DLPAR WQ
The hotplug code uses its own workqueue to handle IRQ requests
(pseries_hp_wq), however that workqueue is initialized after
init_ras_IRQ(). That can lead to a kernel panic if any hotplug
interrupts fire after init_ras_IRQ() but before pseries_hp_wq is
initialised. eg:
UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes)
NET: Registered protocol family 1
Unpacking initramfs...
(qemu) object_add memory-backend-ram,id=mem1,size=10G
(qemu) device_add pc-dimm,id=dimm1,memdev=mem1
Unable to handle kernel paging request for data at address 0xf94d03007c421378
Faulting instruction address: 0xc00000000012d744
Oops: Kernel access of bad area, sig: 11 [#1]
LE SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-ziviani+ #26
task: (ptrval) task.stack: (ptrval)
NIP: c00000000012d744 LR: c00000000012d744 CTR: 0000000000000000
REGS: (ptrval) TRAP: 0380 Not tainted (4.15.0-rc2-ziviani+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28088042 XER: 20040000
CFAR: c00000000012d3c4 SOFTE: 0
...
NIP [c00000000012d744] __queue_work+0xd4/0x5c0
LR [c00000000012d744] __queue_work+0xd4/0x5c0
Call Trace:
[c0000000fffefb90] [c00000000012d744] __queue_work+0xd4/0x5c0 (unreliable)
[c0000000fffefc70] [c00000000012dce4] queue_work_on+0xb4/0xf0
This commit makes the RAS IRQ registration explicitly dependent on the
creation of the pseries_hp_wq.
Reported-by: Min Deng <mdeng@redhat.com>
Reported-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Tested-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-08 14:54:32 +11:00
|
|
|
int __init dlpar_workqueue_init(void)
|
2009-11-24 21:13:32 +00:00
|
|
|
{
|
powerpc/pseries: Make RAS IRQ explicitly dependent on DLPAR WQ
The hotplug code uses its own workqueue to handle IRQ requests
(pseries_hp_wq), however that workqueue is initialized after
init_ras_IRQ(). That can lead to a kernel panic if any hotplug
interrupts fire after init_ras_IRQ() but before pseries_hp_wq is
initialised. eg:
UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes)
NET: Registered protocol family 1
Unpacking initramfs...
(qemu) object_add memory-backend-ram,id=mem1,size=10G
(qemu) device_add pc-dimm,id=dimm1,memdev=mem1
Unable to handle kernel paging request for data at address 0xf94d03007c421378
Faulting instruction address: 0xc00000000012d744
Oops: Kernel access of bad area, sig: 11 [#1]
LE SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-ziviani+ #26
task: (ptrval) task.stack: (ptrval)
NIP: c00000000012d744 LR: c00000000012d744 CTR: 0000000000000000
REGS: (ptrval) TRAP: 0380 Not tainted (4.15.0-rc2-ziviani+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28088042 XER: 20040000
CFAR: c00000000012d3c4 SOFTE: 0
...
NIP [c00000000012d744] __queue_work+0xd4/0x5c0
LR [c00000000012d744] __queue_work+0xd4/0x5c0
Call Trace:
[c0000000fffefb90] [c00000000012d744] __queue_work+0xd4/0x5c0 (unreliable)
[c0000000fffefc70] [c00000000012dce4] queue_work_on+0xb4/0xf0
This commit makes the RAS IRQ registration explicitly dependent on the
creation of the pseries_hp_wq.
Reported-by: Min Deng <mdeng@redhat.com>
Reported-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Tested-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-08 14:54:32 +11:00
|
|
|
if (pseries_hp_wq)
|
|
|
|
return 0;
|
|
|
|
|
powerpc, workqueue: Use alloc_ordered_workqueue() to create ordered workqueues
BACKGROUND
==========
When multiple work items are queued to a workqueue, their execution order
doesn't match the queueing order. They may get executed in any order and
simultaneously. When fully serialized execution - one by one in the queueing
order - is needed, an ordered workqueue should be used which can be created
with alloc_ordered_workqueue().
However, alloc_ordered_workqueue() was a later addition. Before it, an
ordered workqueue could be obtained by creating an UNBOUND workqueue with
@max_active==1. This originally was an implementation side-effect which was
broken by 4c16bd327c74 ("workqueue: restore WQ_UNBOUND/max_active==1 to be
ordered"). Because there were users that depended on the ordered execution,
5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered")
made workqueue allocation path to implicitly promote UNBOUND workqueues w/
@max_active==1 to ordered workqueues.
While this has worked okay, overloading the UNBOUND allocation interface
this way creates other issues. It's difficult to tell whether a given
workqueue actually needs to be ordered and users that legitimately want a
min concurrency level wq unexpectedly gets an ordered one instead. With
planned UNBOUND workqueue updates to improve execution locality and more
prevalence of chiplet designs which can benefit from such improvements, this
isn't a state we wanna be in forever.
This patch series audits all callsites that create an UNBOUND workqueue w/
@max_active==1 and converts them to alloc_ordered_workqueue() as necessary.
WHAT TO LOOK FOR
================
The conversions are from
alloc_workqueue(WQ_UNBOUND | flags, 1, args..)
to
alloc_ordered_workqueue(flags, args...)
which don't cause any functional changes. If you know that fully ordered
execution is not ncessary, please let me know. I'll drop the conversion and
instead add a comment noting the fact to reduce confusion while conversion
is in progress.
If you aren't fully sure, it's completely fine to let the conversion
through. The behavior will stay exactly the same and we can always
reconsider later.
As there are follow-up workqueue core changes, I'd really appreciate if the
patch can be routed through the workqueue tree w/ your acks. Thanks.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
2023-05-08 13:52:27 -10:00
|
|
|
pseries_hp_wq = alloc_ordered_workqueue("pseries hotplug workqueue", 0);
|
powerpc/pseries: Make RAS IRQ explicitly dependent on DLPAR WQ
The hotplug code uses its own workqueue to handle IRQ requests
(pseries_hp_wq), however that workqueue is initialized after
init_ras_IRQ(). That can lead to a kernel panic if any hotplug
interrupts fire after init_ras_IRQ() but before pseries_hp_wq is
initialised. eg:
UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes)
NET: Registered protocol family 1
Unpacking initramfs...
(qemu) object_add memory-backend-ram,id=mem1,size=10G
(qemu) device_add pc-dimm,id=dimm1,memdev=mem1
Unable to handle kernel paging request for data at address 0xf94d03007c421378
Faulting instruction address: 0xc00000000012d744
Oops: Kernel access of bad area, sig: 11 [#1]
LE SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-ziviani+ #26
task: (ptrval) task.stack: (ptrval)
NIP: c00000000012d744 LR: c00000000012d744 CTR: 0000000000000000
REGS: (ptrval) TRAP: 0380 Not tainted (4.15.0-rc2-ziviani+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28088042 XER: 20040000
CFAR: c00000000012d3c4 SOFTE: 0
...
NIP [c00000000012d744] __queue_work+0xd4/0x5c0
LR [c00000000012d744] __queue_work+0xd4/0x5c0
Call Trace:
[c0000000fffefb90] [c00000000012d744] __queue_work+0xd4/0x5c0 (unreliable)
[c0000000fffefc70] [c00000000012dce4] queue_work_on+0xb4/0xf0
This commit makes the RAS IRQ registration explicitly dependent on the
creation of the pseries_hp_wq.
Reported-by: Min Deng <mdeng@redhat.com>
Reported-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Tested-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-08 14:54:32 +11:00
|
|
|
|
|
|
|
return pseries_hp_wq ? 0 : -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __init dlpar_sysfs_init(void)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = dlpar_workqueue_init();
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
2015-12-16 14:50:21 -06:00
|
|
|
return sysfs_create_file(kernel_kobj, &class_attr_dlpar.attr);
|
2009-11-24 21:13:32 +00:00
|
|
|
}
|
powerpc/pseries: Make RAS IRQ explicitly dependent on DLPAR WQ
The hotplug code uses its own workqueue to handle IRQ requests
(pseries_hp_wq), however that workqueue is initialized after
init_ras_IRQ(). That can lead to a kernel panic if any hotplug
interrupts fire after init_ras_IRQ() but before pseries_hp_wq is
initialised. eg:
UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes)
NET: Registered protocol family 1
Unpacking initramfs...
(qemu) object_add memory-backend-ram,id=mem1,size=10G
(qemu) device_add pc-dimm,id=dimm1,memdev=mem1
Unable to handle kernel paging request for data at address 0xf94d03007c421378
Faulting instruction address: 0xc00000000012d744
Oops: Kernel access of bad area, sig: 11 [#1]
LE SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-ziviani+ #26
task: (ptrval) task.stack: (ptrval)
NIP: c00000000012d744 LR: c00000000012d744 CTR: 0000000000000000
REGS: (ptrval) TRAP: 0380 Not tainted (4.15.0-rc2-ziviani+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28088042 XER: 20040000
CFAR: c00000000012d3c4 SOFTE: 0
...
NIP [c00000000012d744] __queue_work+0xd4/0x5c0
LR [c00000000012d744] __queue_work+0xd4/0x5c0
Call Trace:
[c0000000fffefb90] [c00000000012d744] __queue_work+0xd4/0x5c0 (unreliable)
[c0000000fffefc70] [c00000000012dce4] queue_work_on+0xb4/0xf0
This commit makes the RAS IRQ registration explicitly dependent on the
creation of the pseries_hp_wq.
Reported-by: Min Deng <mdeng@redhat.com>
Reported-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Tested-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2018-01-08 14:54:32 +11:00
|
|
|
machine_device_initcall(pseries, dlpar_sysfs_init);
|
2009-11-24 21:13:32 +00:00
|
|
|
|