| Message ID | 1340981479-6521-1-git-send-email-toshi.kani@hp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Toshi, 2012/06/29 23:51, Toshi Kani wrote: > Added CPU hot-remove support through an ACPI eject notification. > It calls acpi_bus_hot_remove_device(), which shares the same code > path with the sysfs eject operation. acpi_os_hotplug_execute() > serializes hot-remove operations between ACPI hot-remove and sysfs > eject requests. > > Signed-off-by: Toshi Kani <toshi.kani@hp.com> Looks good to me. Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> > > --- > This patch applies on top of the patchset below. > > [PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug > http://marc.info/?l=linux-acpi&m=134074381322973&w=2 > > --- > drivers/acpi/processor_driver.c | 27 +++++++++++++++++---------- > 1 files changed, 17 insertions(+), 10 deletions(-) > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c > index f9fa1b2..a6f6bde 100644 > --- a/drivers/acpi/processor_driver.c > +++ b/drivers/acpi/processor_driver.c > @@ -699,8 +699,8 @@ int acpi_processor_device_add(acpi_handle handle, struct acpi_device **device) > static void acpi_processor_hotplug_notify(acpi_handle handle, > u32 event, void *data) > { > - struct acpi_processor *pr; > struct acpi_device *device = NULL; > + struct acpi_eject_event *ej_event = NULL; > u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */ > int result; > > @@ -732,20 +732,27 @@ static void acpi_processor_hotplug_notify(acpi_handle handle, > "received ACPI_NOTIFY_EJECT_REQUEST\n")); > > if (acpi_bus_get_device(handle, &device)) { > - printk(KERN_ERR PREFIX > - "Device don't exist, dropping EJECT\n"); > + pr_err(PREFIX "Device don't exist, dropping EJECT\n"); > break; > } > - pr = acpi_driver_data(device); > - if (!pr) { > - printk(KERN_ERR PREFIX > - "Driver data is NULL, dropping EJECT\n"); > + if (!acpi_driver_data(device)) { > + pr_err(PREFIX "Driver data is NULL, dropping EJECT\n"); > break; > } > > - /* REVISIT: update when eject is supported */ > - ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED; > - break; > + ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL); > + if (!ej_event) { > + pr_err(PREFIX "No memory, dropping EJECT\n"); > + break; > + } > + > + ej_event->handle = handle; > + ej_event->event = ACPI_NOTIFY_EJECT_REQUEST; > + acpi_os_hotplug_execute(acpi_bus_hot_remove_device, > + (void *)ej_event); > + > + /* eject is performed asynchronously */ > + return; > > default: > ACPI_DEBUG_PRINT((ACPI_DB_INFO, > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2012-07-06 at 12:02 +0900, Yasuaki Ishimatsu wrote: > Hi Toshi, > > 2012/06/29 23:51, Toshi Kani wrote: > > Added CPU hot-remove support through an ACPI eject notification. > > It calls acpi_bus_hot_remove_device(), which shares the same code > > path with the sysfs eject operation. acpi_os_hotplug_execute() > > serializes hot-remove operations between ACPI hot-remove and sysfs > > eject requests. > > > > Signed-off-by: Toshi Kani <toshi.kani@hp.com> > > Looks good to me. > > Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Great! Thanks Yasuaki for reviewing! -Toshi > > > > --- > > This patch applies on top of the patchset below. > > > > [PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug > > http://marc.info/?l=linux-acpi&m=134074381322973&w=2 > > > > --- > > drivers/acpi/processor_driver.c | 27 +++++++++++++++++---------- > > 1 files changed, 17 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c > > index f9fa1b2..a6f6bde 100644 > > --- a/drivers/acpi/processor_driver.c > > +++ b/drivers/acpi/processor_driver.c > > @@ -699,8 +699,8 @@ int acpi_processor_device_add(acpi_handle handle, struct acpi_device **device) > > static void acpi_processor_hotplug_notify(acpi_handle handle, > > u32 event, void *data) > > { > > - struct acpi_processor *pr; > > struct acpi_device *device = NULL; > > + struct acpi_eject_event *ej_event = NULL; > > u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */ > > int result; > > > > @@ -732,20 +732,27 @@ static void acpi_processor_hotplug_notify(acpi_handle handle, > > "received ACPI_NOTIFY_EJECT_REQUEST\n")); > > > > if (acpi_bus_get_device(handle, &device)) { > > - printk(KERN_ERR PREFIX > > - "Device don't exist, dropping EJECT\n"); > > + pr_err(PREFIX "Device don't exist, dropping EJECT\n"); > > break; > > } > > - pr = acpi_driver_data(device); > > - if (!pr) { > > - printk(KERN_ERR PREFIX > > - "Driver data is NULL, dropping EJECT\n"); > > + if (!acpi_driver_data(device)) { > > + pr_err(PREFIX "Driver data is NULL, dropping EJECT\n"); > > break; > > } > > > > - /* REVISIT: update when eject is supported */ > > - ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED; > > - break; > > + ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL); > > + if (!ej_event) { > > + pr_err(PREFIX "No memory, dropping EJECT\n"); > > + break; > > + } > > + > > + ej_event->handle = handle; > > + ej_event->event = ACPI_NOTIFY_EJECT_REQUEST; > > + acpi_os_hotplug_execute(acpi_bus_hot_remove_device, > > + (void *)ej_event); > > + > > + /* eject is performed asynchronously */ > > + return; > > > > default: > > ACPI_DEBUG_PRINT((ACPI_DB_INFO, > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Toshi, I think a better solution here is to send a notification to acpid daemon instead of directly ejecting the physical processor in kernel by apci hotplug work thread. The daemon should do: 1) check whether user policy allows to remove the physical processor 2) resolve any dependency issues, such as some memory/IOHs may have dependency on the processor. 3) Remove all devices on the physical processor through sysfs. 4) Power off the physical processor through sysfs. If we rely on the acpi hotplug work thread to do the hard work, it may block the work thread for a very long time and it won't respond to other hotplug events. Thanks! Gerry On 06/29/2012 10:51 PM, Toshi Kani wrote: > Added CPU hot-remove support through an ACPI eject notification. > It calls acpi_bus_hot_remove_device(), which shares the same code > path with the sysfs eject operation. acpi_os_hotplug_execute() > serializes hot-remove operations between ACPI hot-remove and sysfs > eject requests. > > Signed-off-by: Toshi Kani <toshi.kani@hp.com> > > --- > This patch applies on top of the patchset below. > > [PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug > http://marc.info/?l=linux-acpi&m=134074381322973&w=2 > > --- > drivers/acpi/processor_driver.c | 27 +++++++++++++++++---------- > 1 files changed, 17 insertions(+), 10 deletions(-) > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c > index f9fa1b2..a6f6bde 100644 > --- a/drivers/acpi/processor_driver.c > +++ b/drivers/acpi/processor_driver.c > @@ -699,8 +699,8 @@ int acpi_processor_device_add(acpi_handle handle, struct acpi_device **device) > static void acpi_processor_hotplug_notify(acpi_handle handle, > u32 event, void *data) > { > - struct acpi_processor *pr; > struct acpi_device *device = NULL; > + struct acpi_eject_event *ej_event = NULL; > u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */ > int result; > > @@ -732,20 +732,27 @@ static void acpi_processor_hotplug_notify(acpi_handle handle, > "received ACPI_NOTIFY_EJECT_REQUEST\n")); > > if (acpi_bus_get_device(handle, &device)) { > - printk(KERN_ERR PREFIX > - "Device don't exist, dropping EJECT\n"); > + pr_err(PREFIX "Device don't exist, dropping EJECT\n"); > break; > } > - pr = acpi_driver_data(device); > - if (!pr) { > - printk(KERN_ERR PREFIX > - "Driver data is NULL, dropping EJECT\n"); > + if (!acpi_driver_data(device)) { > + pr_err(PREFIX "Driver data is NULL, dropping EJECT\n"); > break; > } > > - /* REVISIT: update when eject is supported */ > - ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED; > - break; > + ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL); > + if (!ej_event) { > + pr_err(PREFIX "No memory, dropping EJECT\n"); > + break; > + } > + > + ej_event->handle = handle; > + ej_event->event = ACPI_NOTIFY_EJECT_REQUEST; > + acpi_os_hotplug_execute(acpi_bus_hot_remove_device, > + (void *)ej_event); > + > + /* eject is performed asynchronously */ > + return; > > default: > ACPI_DEBUG_PRINT((ACPI_DB_INFO, > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 2012-07-07 at 00:27 +0800, Jiang Liu wrote: > Hi Toshi, > I think a better solution here is to send a notification to acpid > daemon instead of directly ejecting the physical processor in kernel by > apci hotplug work thread. The daemon should do: > 1) check whether user policy allows to remove the physical processor > 2) resolve any dependency issues, such as some memory/IOHs may have > dependency on the processor. > 3) Remove all devices on the physical processor through sysfs. > 4) Power off the physical processor through sysfs. > > If we rely on the acpi hotplug work thread to do the hard work, it > may block the work thread for a very long time and it won't respond to other > hotplug events. > Thanks! > Gerry Hi Gerry, Good points. I agree with your concerns in general. For step 2) and 4), I am wondering if they are relevant to CPU hotplug these days. In ACPI namespace, a processor object represents a logical processor (or a core when hyper-threading is disabled). A physical processor (i.e. a socket) usually has multiple cores, and memory controller and bus interface are part of the socket functionality. Hence, I think step 2) and 4) belong to socket-level hot-removal operation, which can be implemented as container hot-remove when a socket is represented with a container object. I agree that step 1) needs to be concerned for CPU hotplug. Other approach (which has been implemented in other OS) is that such user policy can be managed by management console or hypervisor, which becomes a single place to manage the policy for multiple OS instances, i.e. if hot-remove is disallowed on a target, it fails a request and does not send a GPE. Asking customers to setup the policy to each OS instance can be problematic, esp. when there are many OS instances on virtualized environment. Other issue is that when a hot-remove request is failed or ignored in user space, we do not have a way to fail the request with _OST at this point. Therefore, from the management console / hypervisor, where a hot-remove request was made from, this case can be seen as a hang in the hot-remove request. Thanks, -Toshi > On 06/29/2012 10:51 PM, Toshi Kani wrote: > > Added CPU hot-remove support through an ACPI eject notification. > > It calls acpi_bus_hot_remove_device(), which shares the same code > > path with the sysfs eject operation. acpi_os_hotplug_execute() > > serializes hot-remove operations between ACPI hot-remove and sysfs > > eject requests. > > > > Signed-off-by: Toshi Kani <toshi.kani@hp.com> > > > > --- > > This patch applies on top of the patchset below. > > > > [PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug > > http://marc.info/?l=linux-acpi&m=134074381322973&w=2 > > > > --- > > drivers/acpi/processor_driver.c | 27 +++++++++++++++++---------- > > 1 files changed, 17 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c > > index f9fa1b2..a6f6bde 100644 > > --- a/drivers/acpi/processor_driver.c > > +++ b/drivers/acpi/processor_driver.c > > @@ -699,8 +699,8 @@ int acpi_processor_device_add(acpi_handle handle, struct acpi_device **device) > > static void acpi_processor_hotplug_notify(acpi_handle handle, > > u32 event, void *data) > > { > > - struct acpi_processor *pr; > > struct acpi_device *device = NULL; > > + struct acpi_eject_event *ej_event = NULL; > > u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */ > > int result; > > > > @@ -732,20 +732,27 @@ static void acpi_processor_hotplug_notify(acpi_handle handle, > > "received ACPI_NOTIFY_EJECT_REQUEST\n")); > > > > if (acpi_bus_get_device(handle, &device)) { > > - printk(KERN_ERR PREFIX > > - "Device don't exist, dropping EJECT\n"); > > + pr_err(PREFIX "Device don't exist, dropping EJECT\n"); > > break; > > } > > - pr = acpi_driver_data(device); > > - if (!pr) { > > - printk(KERN_ERR PREFIX > > - "Driver data is NULL, dropping EJECT\n"); > > + if (!acpi_driver_data(device)) { > > + pr_err(PREFIX "Driver data is NULL, dropping EJECT\n"); > > break; > > } > > > > - /* REVISIT: update when eject is supported */ > > - ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED; > > - break; > > + ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL); > > + if (!ej_event) { > > + pr_err(PREFIX "No memory, dropping EJECT\n"); > > + break; > > + } > > + > > + ej_event->handle = handle; > > + ej_event->event = ACPI_NOTIFY_EJECT_REQUEST; > > + acpi_os_hotplug_execute(acpi_bus_hot_remove_device, > > + (void *)ej_event); > > + > > + /* eject is performed asynchronously */ > > + return; > > > > default: > > ACPI_DEBUG_PRINT((ACPI_DB_INFO, > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/06/2012 01:13 PM, Toshi Kani wrote: > > For step 2) and 4), I am wondering if they are relevant to CPU hotplug > these days. In ACPI namespace, a processor object represents a logical > processor (or a core when hyper-threading is disabled). A physical > processor (i.e. a socket) usually has multiple cores, and memory > controller and bus interface are part of the socket functionality. > Hence, I think step 2) and 4) belong to socket-level hot-removal > operation, which can be implemented as container hot-remove when a > socket is represented with a container object. What does it mean to eject just a core in that case? If there are seven other cores in the physical processor and you get a request to eject one core, what would you expect kernel to do - simply move all processes and interrupts off of that core, take it out of scheduling consideration and simply idle the core? If yes, how is that any different from simply offlining a core? If you are ejecting individual cores at a time, do you keep track of how many you have ejected and then eject the entire physical CPU along with memory and IOH associated with the socket when the last core is ejected?
On Fri, 2012-07-06 at 14:09 -0600, Khalid Aziz wrote: > On 07/06/2012 01:13 PM, Toshi Kani wrote: > > > > > For step 2) and 4), I am wondering if they are relevant to CPU hotplug > > these days. In ACPI namespace, a processor object represents a logical > > processor (or a core when hyper-threading is disabled). A physical > > processor (i.e. a socket) usually has multiple cores, and memory > > controller and bus interface are part of the socket functionality. > > Hence, I think step 2) and 4) belong to socket-level hot-removal > > operation, which can be implemented as container hot-remove when a > > socket is represented with a container object. > > What does it mean to eject just a core in that case? If there are seven > other cores in the physical processor and you get a request to eject > one core, what would you expect kernel to do - simply move all processes > and interrupts off of that core, take it out of scheduling consideration > and simply idle the core? If yes, how is that any different from simply > offlining a core? Yes, offlining and eject are similar operations to a core as it alone cannot be removed physically. Ejecting a core is a logical eject operation, which updates the status (_STA) of the object in ACPI after offlining. The difference from the offlining is that the ejected core is no longer assigned to the partition. Here is one example. Say, a core is assigned to a guest partition as a dedicated resource (ex. 100% of its CPU time is bound to the partition). Offlining this core saves the power-consumption, but this core is still bound to the partition. Ejecting the core removes it from the partition (logically), and allows it to be assigned to other partition as a dedicated resource with hot-add. > If you are ejecting individual cores at a time, do you > keep track of how many you have ejected and then eject the entire physical > CPU along with memory and IOH associated with the socket when the last > core is ejected? It depends on the firmware implementation, but typically the answer is no. _EJ0 of a core object only removes the associated core object. It will require a separate socket hot-remove request to eject the socket-level resources. That is, the OS may not call _EJ0 of a socket object from the core hot-remove operation just because all children cores are removed. Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2012-07-06 at 15:00 -0600, Toshi Kani wrote: > Yes, offlining and eject are similar operations to a core as it alone > cannot be removed physically. Ejecting a core is a logical eject > operation, which updates the status (_STA) of the object in ACPI after > offlining. The difference from the offlining is that the ejected core > is no longer assigned to the partition. Here is one example. Say, a > core is assigned to a guest partition as a dedicated resource (ex. 100% > of its CPU time is bound to the partition). Offlining this core saves > the power-consumption, but this core is still bound to the partition. > Ejecting the core removes it from the partition (logically), and allows > it to be assigned to other partition as a dedicated resource with > hot-add. > Ejecting a core is reasonable when eject happens from a guest. I still wonder what firmware would do if kernel calls eject method on a core when running on the native host platform. If firmware behavior is not well defined in this case, there might be some risk associated with calling eject method on core. Makes sense?
On Tue, 2012-07-10 at 16:56 -0600, Khalid Aziz wrote: > On Fri, 2012-07-06 at 15:00 -0600, Toshi Kani wrote: > > Yes, offlining and eject are similar operations to a core as it alone > > cannot be removed physically. Ejecting a core is a logical eject > > operation, which updates the status (_STA) of the object in ACPI after > > offlining. The difference from the offlining is that the ejected core > > is no longer assigned to the partition. Here is one example. Say, a > > core is assigned to a guest partition as a dedicated resource (ex. 100% > > of its CPU time is bound to the partition). Offlining this core saves > > the power-consumption, but this core is still bound to the partition. > > Ejecting the core removes it from the partition (logically), and allows > > it to be assigned to other partition as a dedicated resource with > > hot-add. > > > > Ejecting a core is reasonable when eject happens from a guest. I still > wonder what firmware would do if kernel calls eject method on a core > when running on the native host platform. If firmware behavior is not > well defined in this case, there might be some risk associated with > calling eject method on core. > > Makes sense? No, that's not the case. The firmware only implements _EJ0 when it supports the behavior on the environment. It is true for both native and virtual platforms. Note that the presence of a CPU is abstracted with _STA in ACPI, so it does not matter to the kernel if an eject is a physical or logical operation. For example, HP Superdome 2 implements _EJ0 on the native platform to support capacity-on-demand and RAS features (which are supported by HP-UX). _EJ0 is still a logical eject operation in this case. Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Gerry, Khalid, On Mon, 2012-07-09 at 02:40 +0000, Jiang Liu wrote: > Hi Khalid, > It depends on it's running on physical or virtualizaiton host. If > it's a native OS running on physical platforms, we have real platforms > to support physical processor, memory board, IOH(PCIe host bridge) and > node (including mem/cpu/IOH) hotplug, but we haven't really seen a > platform supporting CPU(core) hotplug yet. > I think CPU(core) hotplug is for virtualization, where each physical > core is presented as a virtual processor to guest OS. So to > dynamically reconfigure guest OS capabilties, we need to support CPU > hotplug. Agreed. We need to enable CPU hot-add/remove features for visualization, such as KVM. > Actually we are working on a project to enhance ACPI based physical > device hotplug, which aims to unify the way to support physical > processor(ACPI Container), memory board(ACPI Memory Device), PCI root > bridge(ACPI PCI Host bridge) and node (ACPI Container) hotplug. Cool. > Toshi, seems there's ongoing effort from both you, Yinghai, Yasuaki > Ishimatsu and us to enable ACPI based physical device hotplug. It > would be great if we could cooperate on this area. Absolutely! It will be great for us to collaborate in this area. Gerry, Khalid, please let me know if you have any further comments on this patch. Thanks, -Toshi > Thanks! > Gerry > > > > On Sat, Jul 7, 2012 at 5:00 AM, Toshi Kani <toshi.kani@hp.com> wrote: > On Fri, 2012-07-06 at 14:09 -0600, Khalid Aziz wrote: > > On 07/06/2012 01:13 PM, Toshi Kani wrote: > > > > > > > > For step 2) and 4), I am wondering if they are relevant to CPU > hotplug > > > these days. In ACPI namespace, a processor object represents a > logical > > > processor (or a core when hyper-threading is disabled). A > physical > > > processor (i.e. a socket) usually has multiple cores, and memory > > > controller and bus interface are part of the socket functionality. > > > Hence, I think step 2) and 4) belong to socket-level hot-removal > > > operation, which can be implemented as container hot-remove when a > > > socket is represented with a container object. > > > > What does it mean to eject just a core in that case? If there are > seven > > other cores in the physical processor and you get a request to eject > > one core, what would you expect kernel to do - simply move all > processes > > and interrupts off of that core, take it out of scheduling > consideration > > and simply idle the core? If yes, how is that any different from > simply > > offlining a core? > > > Yes, offlining and eject are similar operations to a core as it alone > cannot be removed physically. Ejecting a core is a logical eject > operation, which updates the status (_STA) of the object in ACPI after > offlining. The difference from the offlining is that the ejected core > is no longer assigned to the partition. Here is one example. Say, a > core is assigned to a guest partition as a dedicated resource (ex.100% > of its CPU time is bound to the partition). Offlining this core saves > the power-consumption, but this core is still bound to the partition. > Ejecting the core removes it from the partition (logically), and > allows it to be assigned to other partition as a dedicated resource > with hot-add. > > > > If you are ejecting individual cores at a time, do you > > keep track of how many you have ejected and then eject the entire > physical > > CPU along with memory and IOH associated with the socket when the > last > > core is ejected? > > > It depends on the firmware implementation, but typically the answer is > no. _EJ0 of a core object only removes the associated core object. It > will require a separate socket hot-remove request to eject the > socket-level resources. That is, the OS may not call _EJ0 of a socket > object from the core hot-remove operation just because all children > cores are removed. > > Thanks, > -Toshi > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c index f9fa1b2..a6f6bde 100644 --- a/drivers/acpi/processor_driver.c +++ b/drivers/acpi/processor_driver.c @@ -699,8 +699,8 @@ int acpi_processor_device_add(acpi_handle handle, struct acpi_device **device) static void acpi_processor_hotplug_notify(acpi_handle handle, u32 event, void *data) { - struct acpi_processor *pr; struct acpi_device *device = NULL; + struct acpi_eject_event *ej_event = NULL; u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */ int result; @@ -732,20 +732,27 @@ static void acpi_processor_hotplug_notify(acpi_handle handle, "received ACPI_NOTIFY_EJECT_REQUEST\n")); if (acpi_bus_get_device(handle, &device)) { - printk(KERN_ERR PREFIX - "Device don't exist, dropping EJECT\n"); + pr_err(PREFIX "Device don't exist, dropping EJECT\n"); break; } - pr = acpi_driver_data(device); - if (!pr) { - printk(KERN_ERR PREFIX - "Driver data is NULL, dropping EJECT\n"); + if (!acpi_driver_data(device)) { + pr_err(PREFIX "Driver data is NULL, dropping EJECT\n"); break; } - /* REVISIT: update when eject is supported */ - ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED; - break; + ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL); + if (!ej_event) { + pr_err(PREFIX "No memory, dropping EJECT\n"); + break; + } + + ej_event->handle = handle; + ej_event->event = ACPI_NOTIFY_EJECT_REQUEST; + acpi_os_hotplug_execute(acpi_bus_hot_remove_device, + (void *)ej_event); + + /* eject is performed asynchronously */ + return; default: ACPI_DEBUG_PRINT((ACPI_DB_INFO,
Added CPU hot-remove support through an ACPI eject notification. It calls acpi_bus_hot_remove_device(), which shares the same code path with the sysfs eject operation. acpi_os_hotplug_execute() serializes hot-remove operations between ACPI hot-remove and sysfs eject requests. Signed-off-by: Toshi Kani <toshi.kani@hp.com> --- This patch applies on top of the patchset below. [PATCH v6 0/6] ACPI: Add _OST support for ACPI hotplug http://marc.info/?l=linux-acpi&m=134074381322973&w=2 --- drivers/acpi/processor_driver.c | 27 +++++++++++++++++---------- 1 files changed, 17 insertions(+), 10 deletions(-)