In order to better support device hotplug (cpu, memory, and pci) in the
PowerVM and PowerKVM environments, the handling of device hotplug
could be updated so that the act of hotplugging a device occurs entirely
in the kernel. This patch set begins to address this by moving
memory hotplug to the kernel. Patches to follow will do the same
for cpu and pci devices.
To provide background, the current handling of memory hotplug is
handled by the drmgr command. This command is invoked when memory
add/remove requests are made at the HMC and conveyed to a partition
through the RSCT framework. The drmgr command then performs parts
of the hotplug in user-space and makes requests to the kernel to perform
other pieces. This is not really ideal, we can do everything in the
kernel and do it faster.
In this patchset, hotplug events will now be communicated to the kernel
in the form of rtas hotplug events. For PowerKVM systems this is done
by qemu using the ras epow interrupt. For PowerVM systems the drmgr
command will be updated to create a rtas hotplug event and send it to
the kernel via a new /proc/powerpc/dlpar interface. Both of these
entry points for hotplug rtas events then call a common routine
for handling rtas hotplug events.
-Nathan
Patch 1/5
- Add definition of hotplug rtas event sections.
Patch 2/5
- export the dlpar_[acquire|release]drc() routines.
Patch 3/5
- Create the new /proc/powerpc/dlpar interface
Patch 4/5
- Implement memory hotplug add in the kernel.
Patch 5/5
- Implement memory hotplug remove in the kernel.
include/asm/rtas.h | 26 ++
platforms/pseries/dlpar.c | 63 ++++++-
platforms/pseries/hotplug-memory.c | 332 ++++++++++++++++++++++++++++++++++++-
platforms/pseries/pseries.h | 12 +
4 files changed, 431 insertions(+), 2 deletions(-)
In order to handle device hotplug in the kernel on pseries the hotplug
notification will be communicated to the kernel in the form of a
rtas hotplug event. This patch adds the definition of rtas hotplug event
sections.
Signed-off-by: Nathan Fontenot <redacted>
---
arch/powerpc/include/asm/rtas.h | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
For pseries system the kernel will be notified of hotplug requests in
the form of rtas hotplug events. This patch creates a common routine that
can handle these requests in both the PowerVM anbd PowerKVM environments,
handle_dlpar_errorlog(). This also creates the initial memory hotplug
request handling stub.
For PowerVM this patch also creates a new /proc file that the drmgr
command will use to write rtas hotplug events to.
For future PowerKVM handling the rtas check-exception code can pass
any rtas hotplug events received to handle_dlpar_errorlog().
Signed-off-by: Nathan Fontenot <redacted>
---
arch/powerpc/platforms/pseries/dlpar.c | 63 +++++++++++++++++++++++
arch/powerpc/platforms/pseries/hotplug-memory.c | 22 ++++++++
arch/powerpc/platforms/pseries/pseries.h | 10 ++++
3 files changed, 94 insertions(+), 1 deletion(-)
This patch adds the ability to do memory hotplug adding in the kernel.
Currently the hotplug add/remove of memory is handled by the drmgr
command. The drmgr command performs the add/remove by performing
some work in user-space and making requests to the kernel to handle
other pieces. By moving all of the work to the kernel we can do the
add and remove faster, and provide a common place to do memory hotplug
for both the PowerVM and PowerKVM environments.
Signed-off-by: Nathan Fontenot <redacted>
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 170 +++++++++++++++++++++++
1 file changed, 170 insertions(+)
@@ -69,6 +72,53 @@ unsigned long pseries_memory_block_size(void)returnmemblock_size;}+staticvoiddlpar_free_drconf_property(structproperty*prop)+{+kfree(prop->name);+kfree(prop->value);+kfree(prop);+}++staticstructproperty*dlpar_clone_drconf_property(structdevice_node*dn)+{+structproperty*prop,*new_prop;++prop=of_find_property(dn,"ibm,dynamic-memory",NULL);+if(!prop)+returnNULL;++new_prop=kzalloc(sizeof(*new_prop),GFP_KERNEL);+if(!new_prop)+returnNULL;++new_prop->name=kstrdup(prop->name,GFP_KERNEL);+new_prop->value=kmalloc(prop->length+1,GFP_KERNEL);+if(!new_prop->name||!new_prop->value){+dlpar_free_drconf_property(new_prop);+returnNULL;+}++memcpy(new_prop->value,prop->value,prop->length);+new_prop->length=prop->length;+*(((char*)new_prop->value)+new_prop->length)=0;++returnnew_prop;+}++staticstructmemory_block*lmb_to_memblock(structof_drconf_cell*lmb)+{+unsignedlongsection_nr;+structmem_section*mem_sect;+structmemory_block*mem_block;+u64phys_addr=be64_to_cpu(lmb->base_addr);++section_nr=pfn_to_section_nr(PFN_DOWN(phys_addr));+mem_sect=__nr_to_section(section_nr);++mem_block=find_memory_block(mem_sect);+returnmem_block;+}+#ifdef CONFIG_MEMORY_HOTREMOVEstaticintpseries_remove_memory(u64start,u64size){
@@ -155,13 +205,133 @@ static inline int pseries_remove_mem_node(struct device_node *np)}#endif /* CONFIG_MEMORY_HOTREMOVE */+staticintdlpar_add_one_lmb(structof_drconf_cell*lmb)+{+structmemory_block*mem_block;+u64phys_addr;+unsignedlongpages_per_block;+unsignedlongblock_sz;+intnid,sections_per_block;+intrc;++phys_addr=be64_to_cpu(lmb->base_addr);+block_sz=memory_block_size_bytes();+sections_per_block=block_sz/MIN_MEMORY_BLOCK_SIZE;+pages_per_block=PAGES_PER_SECTION*sections_per_block;++if(phys_addr&((pages_per_block<<PAGE_SHIFT)-1))+return-EINVAL;++nid=memory_add_physaddr_to_nid(phys_addr);+rc=add_memory(nid,phys_addr,block_sz);+if(rc)+returnrc;++rc=memblock_add(phys_addr,block_sz);+if(rc){+remove_memory(nid,phys_addr,block_sz);+returnrc;+}++mem_block=lmb_to_memblock(lmb);+if(!mem_block){+remove_memory(nid,phys_addr,block_sz);+return-EINVAL;+}++rc=device_online(&mem_block->dev);+put_device(&mem_block->dev);+if(rc)+remove_memory(nid,phys_addr,block_sz);++returnrc;+}++staticintdlpar_memory_add(structpseries_hp_errorlog*hp_elog)+{+structof_drconf_cell*lmb;+structdevice_node*dn;+structproperty*prop;+uint32_tentries,*p;+inti,lmbs_to_add;+intlmbs_added=0;+intrc=-EINVAL;++if(hp_elog->id_type==PSERIES_HP_ELOG_ID_DRC_COUNT){+lmbs_to_add=be32_to_cpu(hp_elog->_drc_u.drc_count);+pr_info("Attempting to hot-add %d LMB(s)\n",lmbs_to_add);+}else{+lmbs_to_add=1;+pr_info("Attempting to hot-add LMB, drc index %x\n",+be32_to_cpu(hp_elog->_drc_u.drc_index));+}++dn=of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");+if(!dn)+return-EINVAL;++prop=dlpar_clone_drconf_property(dn);+if(!prop){+of_node_put(dn);+return-EINVAL;+}++p=prop->value;+entries=be32_to_cpu(*p++);+lmb=(structof_drconf_cell*)p;++for(i=0;i<entries;i++,lmb++){+u32drc_index=be32_to_cpu(lmb->drc_index);++if(lmbs_to_add==lmbs_added)+break;++if(be32_to_cpu(lmb->flags)&DRCONF_MEM_ASSIGNED)+continue;++if(hp_elog->id_type==PSERIES_HP_ELOG_ID_DRC_INDEX+&&lmb->drc_index!=hp_elog->_drc_u.drc_index)+continue;++rc=dlpar_acquire_drc(drc_index);+if(rc)+continue;++rc=dlpar_add_one_lmb(lmb);+if(rc){+dlpar_release_drc(drc_index);+continue;+}++lmb->flags|=cpu_to_be32(DRCONF_MEM_ASSIGNED);+lmbs_added++;+pr_info("Memory at %llx (drc index %x) has been hot-added\n",+be64_to_cpu(lmb->base_addr),drc_index);+}++if(lmbs_added)+rc=of_update_property(dn,prop);+else+dlpar_free_drconf_property(prop);++of_node_put(dn);+returnrc?rc:lmbs_added;+}+intdlpar_memory(structpseries_hp_errorlog*hp_elog){intrc=0;+if(hp_elog->id_type!=PSERIES_HP_ELOG_ID_DRC_COUNT+&&hp_elog->id_type!=PSERIES_HP_ELOG_ID_DRC_INDEX)+return-EINVAL;+mutex_lock(&dlpar_mem_mutex);switch(hp_elog->action){+casePSERIES_HP_ELOG_ACTION_ADD:+rc=dlpar_memory_add(hp_elog);+break;default:pr_err("Invalid action (%d) specified\n",hp_elog->action);rc=-EINVAL;
This patch adds the ability to do memory hotplug remove in the kernel.
Currently the hotplug add/remove of memory is handled by the drmgr
command. The drmgr command performs the add/remove by performing
some work in user-space and making requests to the kernel to handle
other pieces. By moving all of the work to the kernel we can do the
add and remove faster, and provide a common place to do memory hotplug
for both the PowerVM and PowerKVM environments.
Signed-off-by: Nathan Fontenot <redacted>
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 140 +++++++++++++++++++++++
1 file changed, 139 insertions(+), 1 deletion(-)
@@ -193,7 +193,137 @@ static int pseries_remove_mem_node(struct device_node *np)pseries_remove_memblock(base,lmb_size);return0;}++staticintlmb_is_removable(structof_drconf_cell*lmb)+{+inti,scns_per_block;+intrc=1;+unsignedlongpfn,block_sz;+u64phys_addr;++phys_addr=be64_to_cpu(lmb->base_addr);+block_sz=memory_block_size_bytes();+scns_per_block=block_sz/MIN_MEMORY_BLOCK_SIZE;++for(i=0;i<scns_per_block;i++){+pfn=PFN_DOWN(phys_addr);+if(!pfn_present(pfn))+continue;++rc&=is_mem_section_removable(pfn,PAGES_PER_SECTION);+phys_addr+=MIN_MEMORY_BLOCK_SIZE;+}++returnrc;+}++staticintdlpar_add_one_lmb(structof_drconf_cell*);++staticintdlpar_remove_one_lmb(structof_drconf_cell*lmb)+{+structmemory_block*mem_block;+unsignedlongblock_sz;+u64phys_addr;+intnid,rc;++block_sz=memory_block_size_bytes();+phys_addr=be64_to_cpu(lmb->base_addr);+nid=memory_add_physaddr_to_nid(phys_addr);++if(!pfn_valid(phys_addr>>PAGE_SHIFT)){+memblock_remove(phys_addr,block_sz);+return0;+}++mem_block=lmb_to_memblock(lmb);+if(!mem_block)+return-EINVAL;++rc=device_offline(&mem_block->dev);+put_device(&mem_block->dev);+if(rc)+returnrc;++remove_memory(nid,phys_addr,block_sz);+memblock_remove(phys_addr,block_sz);++return0;+}++staticintdlpar_memory_remove(structpseries_hp_errorlog*hp_elog)+{+structof_drconf_cell*lmb;+structdevice_node*dn;+structproperty*prop;+intlmbs_to_remove,lmbs_removed=0;+inti,entries;+intrc=-EINVAL;+uint32_t*p;++if(hp_elog->id_type==PSERIES_HP_ELOG_ID_DRC_COUNT){+lmbs_to_remove=be32_to_cpu(hp_elog->_drc_u.drc_count);+pr_info("Attempting to hot-remove %d LMB(s)\n",lmbs_to_remove);+}else{+lmbs_to_remove=1;+pr_info("Attempting to hot-remove LMB, drc index %x\n",+be32_to_cpu(hp_elog->_drc_u.drc_index));+}++dn=of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");+if(!dn)+return-EINVAL;++prop=dlpar_clone_drconf_property(dn);+if(!prop){+of_node_put(dn);+return-EINVAL;+}++p=prop->value;+entries=be32_to_cpu(*p++);+lmb=(structof_drconf_cell*)p;++for(i=0;i<entries;i++,lmb++){+u32drc_index=be32_to_cpu(lmb->drc_index);++if(lmbs_to_remove==lmbs_removed)+break;++if(hp_elog->id_type==PSERIES_HP_ELOG_ID_DRC_INDEX+&&lmb->drc_index!=hp_elog->_drc_u.drc_index)+continue;++if(!(be32_to_cpu(lmb->flags)&DRCONF_MEM_ASSIGNED)+||!lmb_is_removable(lmb))+continue;++rc=dlpar_remove_one_lmb(lmb);+if(rc)+continue;++rc=dlpar_release_drc(drc_index);+if(rc){+dlpar_add_one_lmb(lmb);+continue;+}++lmb->flags&=cpu_to_be32(~DRCONF_MEM_ASSIGNED);+lmbs_removed++;+pr_info("Memory at %llx (drc index %x) has been hot-removed\n",+be64_to_cpu(lmb->base_addr),drc_index);+}++if(lmbs_removed)+rc=of_update_property(dn,prop);+else+dlpar_free_drconf_property(prop);++of_node_put(dn);+returnrc?rc:lmbs_removed;+}+#else+staticinlineintpseries_remove_memblock(unsignedlongbase,unsignedintmemblock_size){
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2014-09-17 07:07:13
On Mon, 2014-09-15 at 15:31 -0500, Nathan Fontenot wrote:
For pseries system the kernel will be notified of hotplug requests in
the form of rtas hotplug events.
Can you flesh that design out a bit for me, I don't entirely get how it's going
to work.
The kernel gets the rtas hotplug events (in rtasd.c) and spits them out to
userspace, which then writes them back in ?
This patch creates a common routine that can handle these requests in both
the PowerVM anbd PowerKVM environments, handle_dlpar_errorlog(). This also
^
creates the initial memory hotplug request handling stub.
For PowerVM this patch also creates a new /proc file that the drmgr
command will use to write rtas hotplug events to.
Why is this different between phyp and KVM?
For future PowerKVM handling the rtas check-exception code can pass
any rtas hotplug events received to handle_dlpar_errorlog().
I don't see how that can happen?
struct pseries_errorlog {
__be16 id; /* 0x00 2-byte ASCII section ID */
__be16 length; /* 0x02 Section length in bytes */
uint8_t version; /* 0x04 Section version */
uint8_t subtype; /* 0x05 Section subtype */
__be16 creator_component; /* 0x06 Creator component ID */
uint8_t data[]; /* 0x08 Start of section data */
};
Should you be checking for length == 0 instead ?
Also I think the code will probably end up cleaner if you do the endian
conversions immediately when you read the hp_elog, rather than passing it
around in BE and having to remember to convert at all the usages.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2014-09-17 07:07:20
On Mon, 2014-09-15 at 15:32 -0500, Nathan Fontenot wrote:
quoted hunk
This patch adds the ability to do memory hotplug adding in the kernel.
Currently the hotplug add/remove of memory is handled by the drmgr
command. The drmgr command performs the add/remove by performing
some work in user-space and making requests to the kernel to handle
other pieces. By moving all of the work to the kernel we can do the
add and remove faster, and provide a common place to do memory hotplug
for both the PowerVM and PowerKVM environments.
Signed-off-by: Nathan Fontenot <redacted>
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 170 +++++++++++++++++++++++
1 file changed, 170 insertions(+)
So if I'm reading this right the hp_elog either contains an index or a count of
LMBs to add. But it doesn't contain anything about which address ranges to add
or any of those details. That is all in the ibm,dynamic-memory property - but
how did it get in there?
+
+ for (i = 0; i < entries; i++, lmb++) {
+ u32 drc_index = be32_to_cpu(lmb->drc_index);
+
+ if (lmbs_to_add == lmbs_added)
+ break;
+
+ if (be32_to_cpu(lmb->flags) & DRCONF_MEM_ASSIGNED)
+ continue;
+
+ if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_INDEX
+ && lmb->drc_index != hp_elog->_drc_u.drc_index)
+ continue;
+
+ rc = dlpar_acquire_drc(drc_index);
+ if (rc)
+ continue;
+
+ rc = dlpar_add_one_lmb(lmb);
+ if (rc) {
+ dlpar_release_drc(drc_index);
+ continue;
+ }
In both the above error cases you just move along. That means we potentially
hotplugged some memory but not everything that we were asked to. That seems
like a bad idea, we should either do everything or nothing.
+
+ lmb->flags |= cpu_to_be32(DRCONF_MEM_ASSIGNED);
+ lmbs_added++;
+ pr_info("Memory at %llx (drc index %x) has been hot-added\n",
+ be64_to_cpu(lmb->base_addr), drc_index);
+ }
+
+ if (lmbs_added)
+ rc = of_update_property(dn, prop);
+ else
+ dlpar_free_drconf_property(prop);
The value of rc here is not clear. It could be EINVAL or it could be the result
of the last dlpar_add_one_lmb(lmb). gcc would have told you that if you hadn't
initialised it.
This looks wrong.
Doesn't the rc eventually go back to dlpar_write(), which expects 0 for success?
That should show up as the write failing in userspace.
int dlpar_memory(struct pseries_hp_errorlog *hp_elog)
{
int rc = 0;
Don't initialise to zero, that way gcc can tell you if there's a path where you
forget to initialise it. It also means you can't accidentally return success.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2014-09-17 07:07:30
On Mon, 2014-09-15 at 15:33 -0500, Nathan Fontenot wrote:
quoted hunk
This patch adds the ability to do memory hotplug remove in the kernel.
Currently the hotplug add/remove of memory is handled by the drmgr
command. The drmgr command performs the add/remove by performing
some work in user-space and making requests to the kernel to handle
other pieces. By moving all of the work to the kernel we can do the
add and remove faster, and provide a common place to do memory hotplug
for both the PowerVM and PowerKVM environments.
Signed-off-by: Nathan Fontenot <redacted>
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 140 +++++++++++++++++++++++
1 file changed, 139 insertions(+), 1 deletion(-)
I don't use drc_name in this patch set but the drc_name piece is
part of the rtas hotplug section definition and I wanted to provide
a complete definition of the section.
-Nathan
On Mon, 2014-09-15 at 15:31 -0500, Nathan Fontenot wrote:
quoted
For pseries system the kernel will be notified of hotplug requests in
the form of rtas hotplug events.
Can you flesh that design out a bit for me, I don't entirely get how it's going
to work.
The kernel gets the rtas hotplug events (in rtasd.c) and spits them out to
userspace, which then writes them back in ?
quoted
This patch creates a common routine that can handle these requests in both
the PowerVM anbd PowerKVM environments, handle_dlpar_errorlog(). This also
^
quoted
creates the initial memory hotplug request handling stub.
For PowerVM this patch also creates a new /proc file that the drmgr
command will use to write rtas hotplug events to.
Why is this different between phyp and KVM?
quoted
For future PowerKVM handling the rtas check-exception code can pass
any rtas hotplug events received to handle_dlpar_errorlog().
Internally to the kernel you mean?
Perhaps a better explanation of how things work today and where I see
them going is needed. I was trying to avoid a long explanation and I
don't think my shortened explanation worked. I'll include this in v2
of the patchset too.
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 is to follow what is currently being done for
pci hotplug. A hotplug request is initiated from the host. QEMU then
sends 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. I was using this same framework
to also enable memory (and next cpu) hotplug.
You are correct that the current pci hotplug path for PowerKVM involves
the kernel receiving the rtas 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 hoping to do is to enable this
by moving the code to handle hotplug from drmgr into the kernel and
provide a single path for handling hotplug for PowerVM and PowerKVM. To
make this work for PowerKVM we will update the kernel rtas code to
recognize rtas hotplug events returned from rtas,check-exception calls
and call handle_dlpar_errorlog(). The hotplug rtas event is never sent out
to userspace.
For PowerVM systems, I created the /proc/powerpc/dlpar file that a rtas
hotplug event can be written to and passed to handle_dlpar_errorlog().
There is no chance of updating how we receive hotplug requests on PowerVM
systems.
Hopefully that explains the design better.
I don't see how that can happen?
struct pseries_errorlog {
__be16 id; /* 0x00 2-byte ASCII section ID */
__be16 length; /* 0x02 Section length in bytes */
uint8_t version; /* 0x04 Section version */
uint8_t subtype; /* 0x05 Section subtype */
__be16 creator_component; /* 0x06 Creator component ID */
uint8_t data[]; /* 0x08 Start of section data */
};
Should you be checking for length == 0 instead ?
You are correct.
Also I think the code will probably end up cleaner if you do the endian
conversions immediately when you read the hp_elog, rather than passing it
around in BE and having to remember to convert at all the usages.
On Mon, 2014-09-15 at 15:32 -0500, Nathan Fontenot wrote:
quoted
This patch adds the ability to do memory hotplug adding in the kernel.
Currently the hotplug add/remove of memory is handled by the drmgr
command. The drmgr command performs the add/remove by performing
some work in user-space and making requests to the kernel to handle
other pieces. By moving all of the work to the kernel we can do the
add and remove faster, and provide a common place to do memory hotplug
for both the PowerVM and PowerKVM environments.
Signed-off-by: Nathan Fontenot <redacted>
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 170 +++++++++++++++++++++++
1 file changed, 170 insertions(+)
That could all use a lot of comments. ie. why do we have to add it twice?
We don't actually add it twice, though I can see how one could think
that based on the names of the routines called. I'll add comments to
clarify this in v2 of the patch.
memory_add_physaddr_to_nid(), this doesn't add anything despite its naming.
The routine finds the node id for the specified physical address.
add_memory(), this actually adds the memory.
memblock_add(), this informs the memory block information tracking about the
newly added memory. Why this is not done as part of add_memory I don't know.
+ int i, lmbs_to_add;
+ int lmbs_added = 0;
+ int rc = -EINVAL;
Don't pre-initialise your rc variables.
I did this here for a reason. When asking to add memory by drc_index it
is possible to fall out of the for() loop traversing the lmb entries
and not find the requested drc_index.
Adding a check for this situation after the loop would do the same thing
and probably make this situation more clear.
So if I'm reading this right the hp_elog either contains an index or a count of
LMBs to add. But it doesn't contain anything about which address ranges to add
or any of those details. That is all in the ibm,dynamic-memory property - but
how did it get in there?
The ibm,dynamic-memory property of the device tree is passed to the kernel
by phyp/qemu. The property is an array that associates each LMB with a
starting physical address and associativity.
quoted
+
+ for (i = 0; i < entries; i++, lmb++) {
+ u32 drc_index = be32_to_cpu(lmb->drc_index);
+
+ if (lmbs_to_add == lmbs_added)
+ break;
+
+ if (be32_to_cpu(lmb->flags) & DRCONF_MEM_ASSIGNED)
+ continue;
+
+ if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_INDEX
+ && lmb->drc_index != hp_elog->_drc_u.drc_index)
+ continue;
+
+ rc = dlpar_acquire_drc(drc_index);
+ if (rc)
+ continue;
+
+ rc = dlpar_add_one_lmb(lmb);
+ if (rc) {
+ dlpar_release_drc(drc_index);
+ continue;
+ }
In both the above error cases you just move along. That means we potentially
hotplugged some memory but not everything that we were asked to. That seems
like a bad idea, we should either do everything or nothing.
That can be done, though will require some additional tracking.
The current hotplug handling for PowerVM make a best effort and tries to
add/remove as much of the requested memory as possible. I was going with
that same approach here, but have no problem moving to an all or nothing
approach.
We will need to keep track of the LMBs added/removed during a request so
we can return to the original state if the request cannot be satisfied.
quoted
+
+ lmb->flags |= cpu_to_be32(DRCONF_MEM_ASSIGNED);
+ lmbs_added++;
+ pr_info("Memory at %llx (drc index %x) has been hot-added\n",
+ be64_to_cpu(lmb->base_addr), drc_index);
+ }
+
+ if (lmbs_added)
+ rc = of_update_property(dn, prop);
+ else
+ dlpar_free_drconf_property(prop);
The value of rc here is not clear. It could be EINVAL or it could be the result
of the last dlpar_add_one_lmb(lmb). gcc would have told you that if you hadn't
initialised it.
This looks wrong.
Doesn't the rc eventually go back to dlpar_write(), which expects 0 for success?
That should show up as the write failing in userspace.
Based on previous comments I think the handling of rc will be updated so
we either return success or failure.
quoted
int dlpar_memory(struct pseries_hp_errorlog *hp_elog)
{
int rc = 0;
Don't initialise to zero, that way gcc can tell you if there's a path where you
forget to initialise it. It also means you can't accidentally return success.
On Mon, 2014-09-15 at 15:33 -0500, Nathan Fontenot wrote:
quoted
This patch adds the ability to do memory hotplug remove in the kernel.
Currently the hotplug add/remove of memory is handled by the drmgr
command. The drmgr command performs the add/remove by performing
some work in user-space and making requests to the kernel to handle
other pieces. By moving all of the work to the kernel we can do the
add and remove faster, and provide a common place to do memory hotplug
for both the PowerVM and PowerKVM environments.
Signed-off-by: Nathan Fontenot <redacted>
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 140 +++++++++++++++++++++++
1 file changed, 139 insertions(+), 1 deletion(-)
@@ -193,7 +193,137 @@ static int pseries_remove_mem_node(struct device_node *np)pseries_remove_memblock(base,lmb_size);return0;}++staticintlmb_is_removable(structof_drconf_cell*lmb)+{
Do we not already have something like this?
No. Perhaps your thinking of the code in drivers/base/memory.c that
handles the sysfs removable file. That code just calls the same
is_mem_section_removable() routine.
quoted
+ int i, scns_per_block;
+ int rc = 1;
I can see this makes the &= work below.
But what if block_sz / MIN_MEMORY_BLOCK_SIZE = 0 ?
If that happens, something else is really wrong. Most
likely a malformed device tree.
For pseries MIN_MEMORY_BLOCK_SIZE is defined to be the smallest
LMB size we suppport, 16MB.
I can add a pr_warn() statement here and bail if that happens.
On Mon, 2014-09-15 at 15:31 -0500, Nathan Fontenot wrote:
quoted
For pseries system the kernel will be notified of hotplug requests in
the form of rtas hotplug events.
Can you flesh that design out a bit for me, I don't entirely get how it's going
to work.
The kernel gets the rtas hotplug events (in rtasd.c) and spits them out to
userspace, which then writes them back in ?
quoted
This patch creates a common routine that can handle these requests in both
the PowerVM anbd PowerKVM environments, handle_dlpar_errorlog(). This also
^
quoted
creates the initial memory hotplug request handling stub.
For PowerVM this patch also creates a new /proc file that the drmgr
command will use to write rtas hotplug events to.
Why is this different between phyp and KVM?
quoted
For future PowerKVM handling the rtas check-exception code can pass
any rtas hotplug events received to handle_dlpar_errorlog().
Internally to the kernel you mean?
Perhaps a better explanation of how things work today and where I see
them going is needed. I was trying to avoid a long explanation and I
don't think my shortened explanation worked. I'll include this in v2
of the patchset too.
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 is to follow what is currently being done for
pci hotplug. A hotplug request is initiated from the host. QEMU then
sends 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. I was using this same framework
to also enable memory (and next cpu) hotplug.
You are correct that the current pci hotplug path for PowerKVM involves
the kernel receiving the rtas 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 hoping to do is to enable this
by moving the code to handle hotplug from drmgr into the kernel and
provide a single path for handling hotplug for PowerVM and PowerKVM. To
make this work for PowerKVM we will update the kernel rtas code to
recognize rtas hotplug events returned from rtas,check-exception calls
and call handle_dlpar_errorlog(). The hotplug rtas event is never sent out
to userspace.
Wouldn't we still want the event surfaced to userspace so that it can at
least be logged?
-Tyrel
For PowerVM systems, I created the /proc/powerpc/dlpar file that a rtas
hotplug event can be written to and passed to handle_dlpar_errorlog().
There is no chance of updating how we receive hotplug requests on PowerVM
systems.
Hopefully that explains the design better.
I don't see how that can happen?
struct pseries_errorlog {
__be16 id; /* 0x00 2-byte ASCII section ID */
__be16 length; /* 0x02 Section length in bytes */
uint8_t version; /* 0x04 Section version */
uint8_t subtype; /* 0x05 Section subtype */
__be16 creator_component; /* 0x06 Creator component ID */
uint8_t data[]; /* 0x08 Start of section data */
};
Should you be checking for length == 0 instead ?
You are correct.
quoted
Also I think the code will probably end up cleaner if you do the endian
conversions immediately when you read the hp_elog, rather than passing it
around in BE and having to remember to convert at all the usages.
@@ -62,6 +63,15 @@ extern int dlpar_detach_node(struct device_node *);externintdlpar_acquire_drc(u32);externintdlpar_release_drc(u32);+#ifdef CONFIG_MEMORY_HOTPLUG+externintdlpar_memory(structpseries_hp_errorlog*);+#else+staticinlineintdlpar_memory(structpseries_hp_errorlog*hp_elog)+{+return-ENOTSUPP;
EOPNOTSUPP is a bit more standard.
ok.
Thanks for all the feedback.
-Nathan
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Mon, 2014-09-15 at 15:31 -0500, Nathan Fontenot wrote:
quoted
For pseries system the kernel will be notified of hotplug requests in
the form of rtas hotplug events.
Can you flesh that design out a bit for me, I don't entirely get how it's going
to work.
The kernel gets the rtas hotplug events (in rtasd.c) and spits them out to
userspace, which then writes them back in ?
quoted
This patch creates a common routine that can handle these requests in both
the PowerVM anbd PowerKVM environments, handle_dlpar_errorlog(). This also
^
quoted
creates the initial memory hotplug request handling stub.
For PowerVM this patch also creates a new /proc file that the drmgr
command will use to write rtas hotplug events to.
Why is this different between phyp and KVM?
quoted
For future PowerKVM handling the rtas check-exception code can pass
any rtas hotplug events received to handle_dlpar_errorlog().
Internally to the kernel you mean?
Perhaps a better explanation of how things work today and where I see
them going is needed. I was trying to avoid a long explanation and I
don't think my shortened explanation worked. I'll include this in v2
of the patchset too.
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 is to follow what is currently being done for
pci hotplug. A hotplug request is initiated from the host. QEMU then
sends 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. I was using this same framework
to also enable memory (and next cpu) hotplug.
You are correct that the current pci hotplug path for PowerKVM involves
the kernel receiving the rtas 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 hoping to do is to enable this
by moving the code to handle hotplug from drmgr into the kernel and
provide a single path for handling hotplug for PowerVM and PowerKVM. To
make this work for PowerKVM we will update the kernel rtas code to
recognize rtas hotplug events returned from rtas,check-exception calls
and call handle_dlpar_errorlog(). The hotplug rtas event is never sent out
to userspace.
Wouldn't we still want the event surfaced to userspace so that it can at
least be logged?
The only logging of hotplug/dlpar events we do is putting a notification
iv /var/log/messages. This is done today by the drmgr command.
I can add a pr_info message to log the hotplug/dlpar request and it's
success/failure.
Also, I believe one of the longer term goals is to not require the rtas_errd
daemon for PowerKVM.
-Nathan
On Mon, 2014-09-15 at 15:32 -0500, Nathan Fontenot wrote:
quoted
This patch adds the ability to do memory hotplug adding in the kernel.
Currently the hotplug add/remove of memory is handled by the drmgr
command. The drmgr command performs the add/remove by performing
some work in user-space and making requests to the kernel to handle
other pieces. By moving all of the work to the kernel we can do the
add and remove faster, and provide a common place to do memory hotplug
for both the PowerVM and PowerKVM environments.
Signed-off-by: Nathan Fontenot <redacted>
---
quoted
+ for (i = 0; i < entries; i++, lmb++) {
+ u32 drc_index = be32_to_cpu(lmb->drc_index);
+
+ if (lmbs_to_add == lmbs_added)
+ break;
+
+ if (be32_to_cpu(lmb->flags) & DRCONF_MEM_ASSIGNED)
+ continue;
+
+ if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_INDEX
+ && lmb->drc_index != hp_elog->_drc_u.drc_index)
+ continue;
+
+ rc = dlpar_acquire_drc(drc_index);
+ if (rc)
+ continue;
+
+ rc = dlpar_add_one_lmb(lmb);
+ if (rc) {
+ dlpar_release_drc(drc_index);
+ continue;
+ }
In both the above error cases you just move along. That means we potentially
hotplugged some memory but not everything that we were asked to. That seems
like a bad idea, we should either do everything or nothing.
Michael, how set are you on the all or nothing approach?
Note that I think the all or nothing approach is best but I think it will
present some problems. We do memory add (and remove) on a LMB basis, so it
is possible to hit a scenario in which we cannot revert back to the original
state. For example, a request to add 5 LMBs only succeeds in adding 4 LMBs.
There is no guarantee that we then remove the 4 MLBs that were added. That
memory could be in use somewhere that it cannot be moved.
I would suggest we continue with the current approach in that we try to
satisfy the request but not try to roll-back the changes if the entire
request cannot be satisfied.
-Nathan