Jiang, Yunhong
2010-Aug-18  03:04 UTC
[Xen-devel] [PATCH] Add cpu hotplug support for 2.6.32 branch
Hi, Jeremy, followed patch port pcpu hotplug support to 2.6.32 pvops dom0. I
don''t know if xen/next-2.6.32 branch is the right base. If it is not,
can you please advice me which branch should I base on?
Thanks
--jyh
Add cpu hotplug support for 2.6.32 branch
Add physical CPU hotplug support to origin/xen/next-2.6.32 branch.
Please notice that, even with this change, the acpi_processor->id is 
still always -1. This is because several workaround in PM side depends
on acpi_processor->id == -1. As the CPU hotplug logic does not depends
on acpi_processor->id, I''d still keep it no changes.
But we need change the acpi_processor->id in the future.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 2f37c9c..305398d 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -39,6 +39,7 @@
 #include <acpi/acpi_drivers.h>
 #include <acpi/processor.h>
 #include <xen/acpi.h>
+#include <xen/pcpu.h>
 
 #define PREFIX "ACPI: "
 
@@ -82,6 +83,42 @@ struct acpi_driver xen_acpi_processor_driver = {
 		},
 };
 
+static int is_processor_present(acpi_handle handle)
+{
+	acpi_status status;
+	unsigned long long sta = 0;
+
+
+	status = acpi_evaluate_integer(handle, "_STA", NULL, &sta);
+
+	if (ACPI_SUCCESS(status) && (sta & ACPI_STA_DEVICE_PRESENT))
+		return 1;
+
+	/*
+	 * _STA is mandatory for a processor that supports hot plug
+	 */
+	if (status == AE_NOT_FOUND)
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+				"Processor does not support hot plug\n"));
+	else
+		ACPI_EXCEPTION((AE_INFO, status,
+				"Processor Device is not present"));
+	return 0;
+}
+
+static acpi_status
+xen_acpi_processor_hotadd_init(struct acpi_processor *pr, int *p_cpu)
+{
+	if (!is_processor_present(pr->handle))
+		return AE_ERROR;
+
+	if (processor_cntl_xen_notify(pr,
+				PROCESSOR_HOTPLUG, HOTPLUG_TYPE_ADD))
+		return AE_ERROR;
+
+	return AE_OK;
+}
+
 static int xen_acpi_processor_get_info(struct acpi_device *device)
 {
 	acpi_status status = 0;
@@ -164,14 +201,12 @@ static int xen_acpi_processor_get_info(struct acpi_device
*device)
 	 *  They should be ignored _iff they are physically not present.
 	 *
 	 */
-#if 0
-	if (pr->id == -1) {
+	if (xen_pcpu_index(pr->acpi_id, 1) == -1) {
 		if (ACPI_FAILURE
-		    (acpi_processor_hotadd_init(pr->handle, &pr->id))) {
+		    (xen_acpi_processor_hotadd_init(pr, &pr->id))) {
 			return -ENODEV;
 		}
 	}
-#endif
 
 	/*
 	 * On some boxes several processors use the same processor bus id.
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
index 6450c17..6d1a770 100644
--- a/drivers/xen/pcpu.c
+++ b/drivers/xen/pcpu.c
@@ -313,6 +313,38 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_id,
int *result)
 	return pcpu;
 }
 
+int xen_pcpu_index(uint32_t id, int is_acpiid)
+{
+	int cpu_num = 0, max_id = 0, ret;
+	xen_platform_op_t op = {
+		.cmd            = XENPF_get_cpuinfo,
+		.interface_version  = XENPF_INTERFACE_VERSION,
+	};
+	struct xenpf_pcpuinfo *info = &op.u.pcpu_info;
+
+	info->xen_cpuid = 0;
+	ret = HYPERVISOR_dom0_op(&op);
+	if (ret)
+		return -1;
+	max_id = op.u.pcpu_info.max_present;
+
+	while ((cpu_num <= max_id)) {
+		info->xen_cpuid = cpu_num;
+		ret = HYPERVISOR_dom0_op(&op);
+		if (ret)
+			continue;
+
+		if (op.u.pcpu_info.max_present > max_id)
+			max_id = op.u.pcpu_info.max_present;
+		if (id == (is_acpiid ? info->acpi_id : info->apic_id))
+			return cpu_num;
+		cpu_num++;
+	}
+
+    return -1;
+}
+EXPORT_SYMBOL(xen_pcpu_index);
+
 /*
  * Sync dom0''s pcpu information with xen hypervisor''s
  */
@@ -417,4 +449,4 @@ static int __init xen_pcpu_init(void)
 	return err;
 }
 
-subsys_initcall(xen_pcpu_init);
+arch_initcall(xen_pcpu_init);
diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h
index fb2bf6b..7e8f9d1 100644
--- a/include/xen/pcpu.h
+++ b/include/xen/pcpu.h
@@ -27,4 +27,6 @@ static inline int xen_pcpu_online(uint32_t flags)
 extern int register_xen_pcpu_notifier(struct notifier_block *nb);
 
 extern void unregister_xen_pcpu_notifier(struct notifier_block *nb);
+
+extern int xen_pcpu_index(uint32_t acpi_id, int is_acpiid);
 #endif
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jan Beulich
2010-Aug-18  09:54 UTC
Re: [Xen-devel] [PATCH] Add cpu hotplug support for 2.6.32 branch
>>> On 18.08.10 at 05:04, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: > Add cpu hotplug support for 2.6.32 branch > > Add physical CPU hotplug support to origin/xen/next-2.6.32 branch.What is the reason this is no longer done through the acpi_processor_hotplug_notify() code path? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Aug-18  19:41 UTC
Re: [Xen-devel] [PATCH] Add cpu hotplug support for 2.6.32 branch
On 08/17/2010 08:04 PM, Jiang, Yunhong wrote:> Hi, Jeremy, followed patch port pcpu hotplug support to 2.6.32 pvops dom0. I don''t know if xen/next-2.6.32 branch is the right base. If it is not, can you please advice me which branch should I base on?No, that''s not really a good base. Ideally you should base on plain v2.6.32, but if that doesn''t work, base it on whatever topic branch has your pre-requisite changes. If that''s too complex (too many changes from multiple branches), then base on xen/next. The existing xen/dom0/pcpu-hotplug branch should a useful guide. Alternatively, if you can provide me with a merge of xen/dom0/pcpu-hotplug into xen/next (ie, with conflict resolution done), then I could just use that. (Though it looks like certain parts may have already been merged - I didn''t look closely.) Thanks, J> Thanks > --jyh > > Add cpu hotplug support for 2.6.32 branch > > Add physical CPU hotplug support to origin/xen/next-2.6.32 branch. > Please notice that, even with this change, the acpi_processor->id is > still always -1. This is because several workaround in PM side depends > on acpi_processor->id == -1. As the CPU hotplug logic does not depends > on acpi_processor->id, I''d still keep it no changes. > > But we need change the acpi_processor->id in the future. > > Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com> > > > diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c > index 2f37c9c..305398d 100644 > --- a/drivers/acpi/processor_xen.c > +++ b/drivers/acpi/processor_xen.c > @@ -39,6 +39,7 @@ > #include <acpi/acpi_drivers.h> > #include <acpi/processor.h> > #include <xen/acpi.h> > +#include <xen/pcpu.h> > > #define PREFIX "ACPI: " > > @@ -82,6 +83,42 @@ struct acpi_driver xen_acpi_processor_driver = { > }, > }; > > +static int is_processor_present(acpi_handle handle) > +{ > + acpi_status status; > + unsigned long long sta = 0; > + > + > + status = acpi_evaluate_integer(handle, "_STA", NULL, &sta); > + > + if (ACPI_SUCCESS(status) && (sta & ACPI_STA_DEVICE_PRESENT)) > + return 1; > + > + /* > + * _STA is mandatory for a processor that supports hot plug > + */ > + if (status == AE_NOT_FOUND) > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, > + "Processor does not support hot plug\n")); > + else > + ACPI_EXCEPTION((AE_INFO, status, > + "Processor Device is not present")); > + return 0; > +} > + > +static acpi_status > +xen_acpi_processor_hotadd_init(struct acpi_processor *pr, int *p_cpu) > +{ > + if (!is_processor_present(pr->handle)) > + return AE_ERROR; > + > + if (processor_cntl_xen_notify(pr, > + PROCESSOR_HOTPLUG, HOTPLUG_TYPE_ADD)) > + return AE_ERROR; > + > + return AE_OK; > +} > + > static int xen_acpi_processor_get_info(struct acpi_device *device) > { > acpi_status status = 0; > @@ -164,14 +201,12 @@ static int xen_acpi_processor_get_info(struct acpi_device *device) > * They should be ignored _iff they are physically not present. > * > */ > -#if 0 > - if (pr->id == -1) { > + if (xen_pcpu_index(pr->acpi_id, 1) == -1) { > if (ACPI_FAILURE > - (acpi_processor_hotadd_init(pr->handle, &pr->id))) { > + (xen_acpi_processor_hotadd_init(pr, &pr->id))) { > return -ENODEV; > } > } > -#endif > > /* > * On some boxes several processors use the same processor bus id. > diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c > index 6450c17..6d1a770 100644 > --- a/drivers/xen/pcpu.c > +++ b/drivers/xen/pcpu.c > @@ -313,6 +313,38 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, int *result) > return pcpu; > } > > +int xen_pcpu_index(uint32_t id, int is_acpiid) > +{ > + int cpu_num = 0, max_id = 0, ret; > + xen_platform_op_t op = { > + .cmd = XENPF_get_cpuinfo, > + .interface_version = XENPF_INTERFACE_VERSION, > + }; > + struct xenpf_pcpuinfo *info = &op.u.pcpu_info; > + > + info->xen_cpuid = 0; > + ret = HYPERVISOR_dom0_op(&op); > + if (ret) > + return -1; > + max_id = op.u.pcpu_info.max_present; > + > + while ((cpu_num <= max_id)) { > + info->xen_cpuid = cpu_num; > + ret = HYPERVISOR_dom0_op(&op); > + if (ret) > + continue; > + > + if (op.u.pcpu_info.max_present > max_id) > + max_id = op.u.pcpu_info.max_present; > + if (id == (is_acpiid ? info->acpi_id : info->apic_id)) > + return cpu_num; > + cpu_num++; > + } > + > + return -1; > +} > +EXPORT_SYMBOL(xen_pcpu_index); > + > /* > * Sync dom0''s pcpu information with xen hypervisor''s > */ > @@ -417,4 +449,4 @@ static int __init xen_pcpu_init(void) > return err; > } > > -subsys_initcall(xen_pcpu_init); > +arch_initcall(xen_pcpu_init); > diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h > index fb2bf6b..7e8f9d1 100644 > --- a/include/xen/pcpu.h > +++ b/include/xen/pcpu.h > @@ -27,4 +27,6 @@ static inline int xen_pcpu_online(uint32_t flags) > extern int register_xen_pcpu_notifier(struct notifier_block *nb); > > extern void unregister_xen_pcpu_notifier(struct notifier_block *nb); > + > +extern int xen_pcpu_index(uint32_t acpi_id, int is_acpiid); > #endif > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2010-Aug-19  05:02 UTC
RE: [Xen-devel] [PATCH] Add cpu hotplug support for 2.6.32 branch
In .32 both the hotplug through container/processor will all go-through the acpi_bus_add =>acpi_processor_driver.add, so we only need change the .add function to achive the purpose. After checking the code, I think in .31 kernel, the changes to the acpi_processor_hotplug_notify() code path is not needed. Thanks --jyh>-----Original Message----- >From: Jan Beulich [mailto:JBeulich@novell.com] >Sent: Wednesday, August 18, 2010 5:55 PM >To: Jiang, Yunhong >Cc: Jeremy Fitzhardinge; Xen-devel >Subject: Re: [Xen-devel] [PATCH] Add cpu hotplug support for 2.6.32 branch > >>>> On 18.08.10 at 05:04, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: >> Add cpu hotplug support for 2.6.32 branch >> >> Add physical CPU hotplug support to origin/xen/next-2.6.32 branch. > >What is the reason this is no longer done through the >acpi_processor_hotplug_notify() code path? > >Jan_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2010-Aug-20  03:45 UTC
RE: [Xen-devel] [PATCH] Add cpu hotplug support for 2.6.32 branch
Jeremy, I think all this patch is purely for acpi changes, so not sure if it is ok to apply it on origin/xen/dom0/acpi-next? I have a talk with Ke, the xen/dom0/acpi-next has already covere all work for PM and CPU/Mem hotplug in a cleaner way and is based on 2.6.32 kernel, so maybe we can use that for the base tree. Thanks --jyh>-----Original Message----- >From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] >Sent: Thursday, August 19, 2010 3:41 AM >To: Jiang, Yunhong >Cc: Xen-devel >Subject: Re: [Xen-devel] [PATCH] Add cpu hotplug support for 2.6.32 branch > > On 08/17/2010 08:04 PM, Jiang, Yunhong wrote: >> Hi, Jeremy, followed patch port pcpu hotplug support to 2.6.32 pvops dom0. I don''t >know if xen/next-2.6.32 branch is the right base. If it is not, can you please advice me >which branch should I base on? > >No, that''s not really a good base. Ideally you should base on plain >v2.6.32, but if that doesn''t work, base it on whatever topic branch has >your pre-requisite changes. If that''s too complex (too many changes >from multiple branches), then base on xen/next. > >The existing xen/dom0/pcpu-hotplug branch should a useful guide. > >Alternatively, if you can provide me with a merge of >xen/dom0/pcpu-hotplug into xen/next (ie, with conflict resolution done), >then I could just use that. (Though it looks like certain parts may have >already been merged - I didn''t look closely.) > >Thanks, > J > >> Thanks >> --jyh >> >> Add cpu hotplug support for 2.6.32 branch >> >> Add physical CPU hotplug support to origin/xen/next-2.6.32 branch. >> Please notice that, even with this change, the acpi_processor->id is >> still always -1. This is because several workaround in PM side depends >> on acpi_processor->id == -1. As the CPU hotplug logic does not depends >> on acpi_processor->id, I''d still keep it no changes. >> >> But we need change the acpi_processor->id in the future. >> >> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com> >> >> >> diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c >> index 2f37c9c..305398d 100644 >> --- a/drivers/acpi/processor_xen.c >> +++ b/drivers/acpi/processor_xen.c >> @@ -39,6 +39,7 @@ >> #include <acpi/acpi_drivers.h> >> #include <acpi/processor.h> >> #include <xen/acpi.h> >> +#include <xen/pcpu.h> >> >> #define PREFIX "ACPI: " >> >> @@ -82,6 +83,42 @@ struct acpi_driver xen_acpi_processor_driver = { >> }, >> }; >> >> +static int is_processor_present(acpi_handle handle) >> +{ >> + acpi_status status; >> + unsigned long long sta = 0; >> + >> + >> + status = acpi_evaluate_integer(handle, "_STA", NULL, &sta); >> + >> + if (ACPI_SUCCESS(status) && (sta & ACPI_STA_DEVICE_PRESENT)) >> + return 1; >> + >> + /* >> + * _STA is mandatory for a processor that supports hot plug >> + */ >> + if (status == AE_NOT_FOUND) >> + ACPI_DEBUG_PRINT((ACPI_DB_INFO, >> + "Processor does not support hot plug\n")); >> + else >> + ACPI_EXCEPTION((AE_INFO, status, >> + "Processor Device is not present")); >> + return 0; >> +} >> + >> +static acpi_status >> +xen_acpi_processor_hotadd_init(struct acpi_processor *pr, int *p_cpu) >> +{ >> + if (!is_processor_present(pr->handle)) >> + return AE_ERROR; >> + >> + if (processor_cntl_xen_notify(pr, >> + PROCESSOR_HOTPLUG, HOTPLUG_TYPE_ADD)) >> + return AE_ERROR; >> + >> + return AE_OK; >> +} >> + >> static int xen_acpi_processor_get_info(struct acpi_device *device) >> { >> acpi_status status = 0; >> @@ -164,14 +201,12 @@ static int xen_acpi_processor_get_info(struct >acpi_device *device) >> * They should be ignored _iff they are physically not present. >> * >> */ >> -#if 0 >> - if (pr->id == -1) { >> + if (xen_pcpu_index(pr->acpi_id, 1) == -1) { >> if (ACPI_FAILURE >> - (acpi_processor_hotadd_init(pr->handle, &pr->id))) { >> + (xen_acpi_processor_hotadd_init(pr, &pr->id))) { >> return -ENODEV; >> } >> } >> -#endif >> >> /* >> * On some boxes several processors use the same processor bus id. >> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c >> index 6450c17..6d1a770 100644 >> --- a/drivers/xen/pcpu.c >> +++ b/drivers/xen/pcpu.c >> @@ -313,6 +313,38 @@ static struct pcpu *_sync_pcpu(int cpu_num, int *max_id, >int *result) >> return pcpu; >> } >> >> +int xen_pcpu_index(uint32_t id, int is_acpiid) >> +{ >> + int cpu_num = 0, max_id = 0, ret; >> + xen_platform_op_t op = { >> + .cmd = XENPF_get_cpuinfo, >> + .interface_version = XENPF_INTERFACE_VERSION, >> + }; >> + struct xenpf_pcpuinfo *info = &op.u.pcpu_info; >> + >> + info->xen_cpuid = 0; >> + ret = HYPERVISOR_dom0_op(&op); >> + if (ret) >> + return -1; >> + max_id = op.u.pcpu_info.max_present; >> + >> + while ((cpu_num <= max_id)) { >> + info->xen_cpuid = cpu_num; >> + ret = HYPERVISOR_dom0_op(&op); >> + if (ret) >> + continue; >> + >> + if (op.u.pcpu_info.max_present > max_id) >> + max_id = op.u.pcpu_info.max_present; >> + if (id == (is_acpiid ? info->acpi_id : info->apic_id)) >> + return cpu_num; >> + cpu_num++; >> + } >> + >> + return -1; >> +} >> +EXPORT_SYMBOL(xen_pcpu_index); >> + >> /* >> * Sync dom0''s pcpu information with xen hypervisor''s >> */ >> @@ -417,4 +449,4 @@ static int __init xen_pcpu_init(void) >> return err; >> } >> >> -subsys_initcall(xen_pcpu_init); >> +arch_initcall(xen_pcpu_init); >> diff --git a/include/xen/pcpu.h b/include/xen/pcpu.h >> index fb2bf6b..7e8f9d1 100644 >> --- a/include/xen/pcpu.h >> +++ b/include/xen/pcpu.h >> @@ -27,4 +27,6 @@ static inline int xen_pcpu_online(uint32_t flags) >> extern int register_xen_pcpu_notifier(struct notifier_block *nb); >> >> extern void unregister_xen_pcpu_notifier(struct notifier_block *nb); >> + >> +extern int xen_pcpu_index(uint32_t acpi_id, int is_acpiid); >> #endif >> >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Aug-21  00:45 UTC
Re: [Xen-devel] [PATCH] Add cpu hotplug support for 2.6.32 branch
On 08/19/2010 08:45 PM, Jiang, Yunhong wrote:> Jeremy, I think all this patch is purely for acpi changes, so not sure if it is ok to apply it on origin/xen/dom0/acpi-next? > I have a talk with Ke, the xen/dom0/acpi-next has already covere all work for PM and CPU/Mem hotplug in a cleaner way and is based on 2.6.32 kernel, so maybe we can use that for the base tree.I''m not sure what you mean by the "base tree". As far as I know, everything is already merged into the 2.6.32 tree. Have I overlooked something? Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2010-Aug-23  03:02 UTC
RE: [Xen-devel] [PATCH] Add cpu hotplug support for 2.6.32 branch
>-----Original Message----- >From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] >Sent: Saturday, August 21, 2010 8:45 AM >To: Jiang, Yunhong >Cc: Xen-devel >Subject: Re: [Xen-devel] [PATCH] Add cpu hotplug support for 2.6.32 branch > > On 08/19/2010 08:45 PM, Jiang, Yunhong wrote: >> Jeremy, I think all this patch is purely for acpi changes, so not sure if it is ok to apply >it on origin/xen/dom0/acpi-next? >> I have a talk with Ke, the xen/dom0/acpi-next has already covere all work for PM >and CPU/Mem hotplug in a cleaner way and is based on 2.6.32 kernel, so maybe we >can use that for the base tree. > >I''m not sure what you mean by the "base tree". As far as I know, >everything is already merged into the 2.6.32 tree. Have I overlooked >something?Sorry, it''s not you overlook, but we. We didn''t port the CPU hotplug patch to 2.6.32 kernel. Thanks --jyh> >Thanks, > J_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel