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 <[email protected]>
---
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,
--
1.7.7.6
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 <[email protected]> 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
>
>
>
>