thr3ads.net - Xen devel - [PATCH 1/3] PAD helper for native and paravirt platform [Feb 2012]

If this information is useful, please help other people find it:
Share via:

Liu, Jinsong

2012-Feb-17 08:56 UTC

[PATCH 1/3] PAD helper for native and paravirt platform

From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00 2001
From: Liu, Jinsong <jinsong.liu@intel.com>
Date: Fri, 10 Feb 2012 20:32:50 +0800
Subject: [PATCH 1/3] PAD helper for native and paravirt platform

This patch is PAD (Processor Aggregator Device) helper.
It provides a native interface for natvie platform, and a template
for paravirt platform, so that os can implicitly hook to proper ops accordingly.
The paravirt template will further redirect to Xen pv ops in later patch for Xen
 core parking.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
 arch/x86/include/asm/paravirt.h       |   10 +++++
 arch/x86/include/asm/paravirt_types.h |    7 ++++
 arch/x86/kernel/paravirt.c            |    9 +++++
 drivers/acpi/acpi_pad.c               |   15 +++-----
 include/acpi/acpi_pad.h               |   61 +++++++++++++++++++++++++++++++++
 5 files changed, 93 insertions(+), 9 deletions(-)
 create mode 100644 include/acpi/acpi_pad.h

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index a7d2db9..02e6df0 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
 	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);
 }
 
+static inline int __acpi_pad_init(void)
+{
+	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init);
+}
+
+static inline void __acpi_pad_exit(void)
+{
+	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
+}
+
 static inline void write_cr0(unsigned long x)
 {
 	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index 8e8b9a4..61e20de 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -336,6 +336,11 @@ struct pv_lock_ops {
 	void (*spin_unlock)(struct arch_spinlock *lock);
 };
 
+struct pv_pad_ops {
+	int (*acpi_pad_init)(void);
+	void (*acpi_pad_exit)(void);
+};
+
 /* This contains all the paravirt structures: we get a convenient
  * number for each function using the offset which we use to indicate
  * what to patch. */
@@ -347,6 +352,7 @@ struct paravirt_patch_template {
 	struct pv_apic_ops pv_apic_ops;
 	struct pv_mmu_ops pv_mmu_ops;
 	struct pv_lock_ops pv_lock_ops;
+	struct pv_pad_ops pv_pad_ops;
 };
 
 extern struct pv_info pv_info;
@@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
 extern struct pv_apic_ops pv_apic_ops;
 extern struct pv_mmu_ops pv_mmu_ops;
 extern struct pv_lock_ops pv_lock_ops;
+extern struct pv_pad_ops pv_pad_ops;
 
 #define PARAVIRT_PATCH(x)					\
 	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index d90272e..ec778f6 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -38,6 +38,8 @@
 #include <asm/tlbflush.h>
 #include <asm/timer.h>
 
+#include <acpi/acpi_pad.h>
+
 /* nop stub */
 void _paravirt_nop(void)
 {
@@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
 #ifdef CONFIG_PARAVIRT_SPINLOCKS
 		.pv_lock_ops = pv_lock_ops,
 #endif
+		.pv_pad_ops = pv_pad_ops,
 	};
 	return *((void **)&tmpl + type);
 }
@@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops = {
 	.set_fixmap = native_set_fixmap,
 };
 
+struct pv_pad_ops pv_pad_ops = {
+	.acpi_pad_init = native_acpi_pad_init,
+	.acpi_pad_exit = native_acpi_pad_exit,
+};
+
 EXPORT_SYMBOL_GPL(pv_time_ops);
 EXPORT_SYMBOL    (pv_cpu_ops);
 EXPORT_SYMBOL    (pv_mmu_ops);
 EXPORT_SYMBOL_GPL(pv_apic_ops);
 EXPORT_SYMBOL_GPL(pv_info);
 EXPORT_SYMBOL    (pv_irq_ops);
+EXPORT_SYMBOL_GPL(pv_pad_ops);
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index a43fa1a..3f0fd27 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -30,6 +30,7 @@
 #include <linux/slab.h>
 #include <acpi/acpi_bus.h>
 #include <acpi/acpi_drivers.h>
+#include <acpi/acpi_pad.h>
 #include <asm/mwait.h>
 
 #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
@@ -37,14 +38,14 @@
 #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
 static DEFINE_MUTEX(isolated_cpus_lock);
 
-static unsigned long power_saving_mwait_eax;
+unsigned long power_saving_mwait_eax;
 
 static unsigned char tsc_detected_unstable;
 static unsigned char tsc_marked_unstable;
 static unsigned char lapic_detected_unstable;
 static unsigned char lapic_marked_unstable;
 
-static void power_saving_mwait_init(void)
+void power_saving_mwait_init(void)
 {
 	unsigned int eax, ebx, ecx, edx;
 	unsigned int highest_cstate = 0;
@@ -500,7 +501,7 @@ static const struct acpi_device_id pad_device_ids[] = {
 };
 MODULE_DEVICE_TABLE(acpi, pad_device_ids);
 
-static struct acpi_driver acpi_pad_driver = {
+struct acpi_driver acpi_pad_driver = {
 	.name = "processor_aggregator",
 	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
 	.ids = pad_device_ids,
@@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver = {
 
 static int __init acpi_pad_init(void)
 {
-	power_saving_mwait_init();
-	if (power_saving_mwait_eax == 0)
-		return -EINVAL;
-
-	return acpi_bus_register_driver(&acpi_pad_driver);
+	return __acpi_pad_init();
 }
 
 static void __exit acpi_pad_exit(void)
 {
-	acpi_bus_unregister_driver(&acpi_pad_driver);
+	__acpi_pad_exit();
 }
 
 module_init(acpi_pad_init);
diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
new file mode 100644
index 0000000..1a1471d
--- /dev/null
+++ b/include/acpi/acpi_pad.h
@@ -0,0 +1,61 @@
+/*
+ *  acpi_pad.h - pad device helper for native and paravirt platform
+ *
+ *  Copyright (C) 2012, Intel Corporation.
+ *     Author: Liu, Jinsong <jinsong.liu@intel.com>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ */
+
+#ifndef __ACPI_PAD_H__
+#define __ACPI_PAD_H__
+
+#include <acpi/acpi_bus.h>
+
+extern unsigned long power_saving_mwait_eax;
+extern struct acpi_driver acpi_pad_driver;
+extern void power_saving_mwait_init(void);
+
+static inline int native_acpi_pad_init(void)
+{
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+	power_saving_mwait_init();
+	if (power_saving_mwait_eax == 0)
+		return -EINVAL;
+
+	return acpi_bus_register_driver(&acpi_pad_driver);
+#else
+	return 0;
+#endif
+}
+
+static inline void native_acpi_pad_exit(void)
+{
+#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
+	acpi_bus_unregister_driver(&acpi_pad_driver);
+#endif
+}
+
+#ifdef CONFIG_PARAVIRT
+#include <asm/paravirt.h>
+#else
+static inline int __acpi_pad_init(void)
+{
+	return native_acpi_pad_init();
+}
+
+static inline void __acpi_pad_exit(void)
+{
+	native_acpi_pad_exit();
+}
+#endif
+
+#endif /* __ACPI_PAD_H__ */
-- 
1.7.1

Jan Beulich

2012-Feb-17 10:04 UTC

head link

Re: [PATCH 1/3] PAD helper for native and paravirt platform

>>> On 17.02.12 at 09:56, "Liu, Jinsong"
<jinsong.liu@intel.com> wrote:
> From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 10 Feb 2012 20:32:50 +0800
> Subject: [PATCH 1/3] PAD helper for native and paravirt platform
> 
> This patch is PAD (Processor Aggregator Device) helper.
> It provides a native interface for natvie platform, and a template
> for paravirt platform, so that os can implicitly hook to proper ops 
> accordingly.
> The paravirt template will further redirect to Xen pv ops in later patch
for
> Xen
>  core parking.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  arch/x86/include/asm/paravirt.h       |   10 +++++
>  arch/x86/include/asm/paravirt_types.h |    7 ++++
>  arch/x86/kernel/paravirt.c            |    9 +++++
>  drivers/acpi/acpi_pad.c               |   15 +++-----
>  include/acpi/acpi_pad.h               |   61 
> +++++++++++++++++++++++++++++++++
>  5 files changed, 93 insertions(+), 9 deletions(-)
>  create mode 100644 include/acpi/acpi_pad.h
> 
> diff --git a/arch/x86/include/asm/paravirt.h
b/arch/x86/include/asm/paravirt.h
> index a7d2db9..02e6df0 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
>  	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);
>  }
>  
> +static inline int __acpi_pad_init(void)
> +{
> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init);
> +}
> +
> +static inline void __acpi_pad_exit(void)
> +{
> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
> +}
With this you, aiui, you aim at getting the calls patched. Are the callers
of this really on performance critical paths? If not, the simpler approach
of having an ops structure the fields of which get overwritten by
Xen initialization would seem a more appropriate approach.

Jan
> +
>  static inline void write_cr0(unsigned long x)
>  {
>  	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
> diff --git a/arch/x86/include/asm/paravirt_types.h 
> b/arch/x86/include/asm/paravirt_types.h
> index 8e8b9a4..61e20de 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -336,6 +336,11 @@ struct pv_lock_ops {
>  	void (*spin_unlock)(struct arch_spinlock *lock);
>  };
>  
> +struct pv_pad_ops {
> +	int (*acpi_pad_init)(void);
> +	void (*acpi_pad_exit)(void);
> +};
> +
>  /* This contains all the paravirt structures: we get a convenient
>   * number for each function using the offset which we use to indicate
>   * what to patch. */
> @@ -347,6 +352,7 @@ struct paravirt_patch_template {
>  	struct pv_apic_ops pv_apic_ops;
>  	struct pv_mmu_ops pv_mmu_ops;
>  	struct pv_lock_ops pv_lock_ops;
> +	struct pv_pad_ops pv_pad_ops;
>  };
>  
>  extern struct pv_info pv_info;
> @@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
>  extern struct pv_apic_ops pv_apic_ops;
>  extern struct pv_mmu_ops pv_mmu_ops;
>  extern struct pv_lock_ops pv_lock_ops;
> +extern struct pv_pad_ops pv_pad_ops;
>  
>  #define PARAVIRT_PATCH(x)					\
>  	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index d90272e..ec778f6 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -38,6 +38,8 @@
>  #include <asm/tlbflush.h>
>  #include <asm/timer.h>
>  
> +#include <acpi/acpi_pad.h>
> +
>  /* nop stub */
>  void _paravirt_nop(void)
>  {
> @@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
>  #ifdef CONFIG_PARAVIRT_SPINLOCKS
>  		.pv_lock_ops = pv_lock_ops,
>  #endif
> +		.pv_pad_ops = pv_pad_ops,
>  	};
>  	return *((void **)&tmpl + type);
>  }
> @@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops = {
>  	.set_fixmap = native_set_fixmap,
>  };
>  
> +struct pv_pad_ops pv_pad_ops = {
> +	.acpi_pad_init = native_acpi_pad_init,
> +	.acpi_pad_exit = native_acpi_pad_exit,
> +};
> +
>  EXPORT_SYMBOL_GPL(pv_time_ops);
>  EXPORT_SYMBOL    (pv_cpu_ops);
>  EXPORT_SYMBOL    (pv_mmu_ops);
>  EXPORT_SYMBOL_GPL(pv_apic_ops);
>  EXPORT_SYMBOL_GPL(pv_info);
>  EXPORT_SYMBOL    (pv_irq_ops);
> +EXPORT_SYMBOL_GPL(pv_pad_ops);
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index a43fa1a..3f0fd27 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -30,6 +30,7 @@
>  #include <linux/slab.h>
>  #include <acpi/acpi_bus.h>
>  #include <acpi/acpi_drivers.h>
> +#include <acpi/acpi_pad.h>
>  #include <asm/mwait.h>
>  
>  #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
> @@ -37,14 +38,14 @@
>  #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
>  static DEFINE_MUTEX(isolated_cpus_lock);
>  
> -static unsigned long power_saving_mwait_eax;
> +unsigned long power_saving_mwait_eax;
>  
>  static unsigned char tsc_detected_unstable;
>  static unsigned char tsc_marked_unstable;
>  static unsigned char lapic_detected_unstable;
>  static unsigned char lapic_marked_unstable;
>  
> -static void power_saving_mwait_init(void)
> +void power_saving_mwait_init(void)
>  {
>  	unsigned int eax, ebx, ecx, edx;
>  	unsigned int highest_cstate = 0;
> @@ -500,7 +501,7 @@ static const struct acpi_device_id pad_device_ids[] = {
>  };
>  MODULE_DEVICE_TABLE(acpi, pad_device_ids);
>  
> -static struct acpi_driver acpi_pad_driver = {
> +struct acpi_driver acpi_pad_driver = {
>  	.name = "processor_aggregator",
>  	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>  	.ids = pad_device_ids,
> @@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver = {
>  
>  static int __init acpi_pad_init(void)
>  {
> -	power_saving_mwait_init();
> -	if (power_saving_mwait_eax == 0)
> -		return -EINVAL;
> -
> -	return acpi_bus_register_driver(&acpi_pad_driver);
> +	return __acpi_pad_init();
>  }
>  
>  static void __exit acpi_pad_exit(void)
>  {
> -	acpi_bus_unregister_driver(&acpi_pad_driver);
> +	__acpi_pad_exit();
>  }
>  
>  module_init(acpi_pad_init);
> diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
> new file mode 100644
> index 0000000..1a1471d
> --- /dev/null
> +++ b/include/acpi/acpi_pad.h
> @@ -0,0 +1,61 @@
> +/*
> + *  acpi_pad.h - pad device helper for native and paravirt platform
> + *
> + *  Copyright (C) 2012, Intel Corporation.
> + *     Author: Liu, Jinsong <jinsong.liu@intel.com>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or (at
> + *  your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful, but
> + *  WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + *  General Public License for more details.
> + */
> +
> +#ifndef __ACPI_PAD_H__
> +#define __ACPI_PAD_H__
> +
> +#include <acpi/acpi_bus.h>
> +
> +extern unsigned long power_saving_mwait_eax;
> +extern struct acpi_driver acpi_pad_driver;
> +extern void power_saving_mwait_init(void);
> +
> +static inline int native_acpi_pad_init(void)
> +{
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	power_saving_mwait_init();
> +	if (power_saving_mwait_eax == 0)
> +		return -EINVAL;
> +
> +	return acpi_bus_register_driver(&acpi_pad_driver);
> +#else
> +	return 0;
> +#endif
> +}
> +
> +static inline void native_acpi_pad_exit(void)
> +{
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	acpi_bus_unregister_driver(&acpi_pad_driver);
> +#endif
> +}
> +
> +#ifdef CONFIG_PARAVIRT
> +#include <asm/paravirt.h>
> +#else
> +static inline int __acpi_pad_init(void)
> +{
> +	return native_acpi_pad_init();
> +}
> +
> +static inline void __acpi_pad_exit(void)
> +{
> +	native_acpi_pad_exit();
> +}
> +#endif
> +
> +#endif /* __ACPI_PAD_H__ */
> -- 
> 1.7.1

Konrad Rzeszutek Wilk

2012-Feb-17 14:29 UTC

head link

Re: [PATCH 1/3] PAD helper for native and paravirt platform

On Fri, Feb 17, 2012 at 08:56:43AM +0000, Liu, Jinsong
wrote:> >From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 10 Feb 2012 20:32:50 +0800
> Subject: [PATCH 1/3] PAD helper for native and paravirt platform
> 
> This patch is PAD (Processor Aggregator Device) helper.
> It provides a native interface for natvie platform, and a template
> for paravirt platform, so that os can implicitly hook to proper ops
accordingly.
> The paravirt template will further redirect to Xen pv ops in later patch
for Xen
>  core parking.
You need to CC the ACPI maintainer and the acpi mailing on this patch. I did
that
for you in the CC.

> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> ---
>  arch/x86/include/asm/paravirt.h       |   10 +++++
>  arch/x86/include/asm/paravirt_types.h |    7 ++++
>  arch/x86/kernel/paravirt.c            |    9 +++++
>  drivers/acpi/acpi_pad.c               |   15 +++-----
>  include/acpi/acpi_pad.h               |   61
+++++++++++++++++++++++++++++++++
>  5 files changed, 93 insertions(+), 9 deletions(-)
>  create mode 100644 include/acpi/acpi_pad.h
> 
> diff --git a/arch/x86/include/asm/paravirt.h
b/arch/x86/include/asm/paravirt.h
> index a7d2db9..02e6df0 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
>  	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);
>  }
>  
> +static inline int __acpi_pad_init(void)
> +{
> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init);
> +}
> +
> +static inline void __acpi_pad_exit(void)
> +{
> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
> +}
> +
>  static inline void write_cr0(unsigned long x)
>  {
>  	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
> diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
> index 8e8b9a4..61e20de 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -336,6 +336,11 @@ struct pv_lock_ops {
>  	void (*spin_unlock)(struct arch_spinlock *lock);
>  };
>  
> +struct pv_pad_ops {
> +	int (*acpi_pad_init)(void);
> +	void (*acpi_pad_exit)(void);
> +};
> +
>  /* This contains all the paravirt structures: we get a convenient
>   * number for each function using the offset which we use to indicate
>   * what to patch. */
> @@ -347,6 +352,7 @@ struct paravirt_patch_template {
>  	struct pv_apic_ops pv_apic_ops;
>  	struct pv_mmu_ops pv_mmu_ops;
>  	struct pv_lock_ops pv_lock_ops;
> +	struct pv_pad_ops pv_pad_ops;
>  };
>  
>  extern struct pv_info pv_info;
> @@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
>  extern struct pv_apic_ops pv_apic_ops;
>  extern struct pv_mmu_ops pv_mmu_ops;
>  extern struct pv_lock_ops pv_lock_ops;
> +extern struct pv_pad_ops pv_pad_ops;
>  
>  #define PARAVIRT_PATCH(x)					\
>  	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index d90272e..ec778f6 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -38,6 +38,8 @@
>  #include <asm/tlbflush.h>
>  #include <asm/timer.h>
>  
> +#include <acpi/acpi_pad.h>
> +
>  /* nop stub */
>  void _paravirt_nop(void)
>  {
> @@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
>  #ifdef CONFIG_PARAVIRT_SPINLOCKS
>  		.pv_lock_ops = pv_lock_ops,
>  #endif
> +		.pv_pad_ops = pv_pad_ops,
>  	};
>  	return *((void **)&tmpl + type);
>  }
> @@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops = {
>  	.set_fixmap = native_set_fixmap,
>  };
>  
> +struct pv_pad_ops pv_pad_ops = {
> +	.acpi_pad_init = native_acpi_pad_init,
> +	.acpi_pad_exit = native_acpi_pad_exit,
> +};
> +
>  EXPORT_SYMBOL_GPL(pv_time_ops);
>  EXPORT_SYMBOL    (pv_cpu_ops);
>  EXPORT_SYMBOL    (pv_mmu_ops);
>  EXPORT_SYMBOL_GPL(pv_apic_ops);
>  EXPORT_SYMBOL_GPL(pv_info);
>  EXPORT_SYMBOL    (pv_irq_ops);
> +EXPORT_SYMBOL_GPL(pv_pad_ops);
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index a43fa1a..3f0fd27 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -30,6 +30,7 @@
>  #include <linux/slab.h>
>  #include <acpi/acpi_bus.h>
>  #include <acpi/acpi_drivers.h>
> +#include <acpi/acpi_pad.h>
>  #include <asm/mwait.h>
>  
>  #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
> @@ -37,14 +38,14 @@
>  #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
>  static DEFINE_MUTEX(isolated_cpus_lock);
>  
> -static unsigned long power_saving_mwait_eax;
> +unsigned long power_saving_mwait_eax;
>  
>  static unsigned char tsc_detected_unstable;
>  static unsigned char tsc_marked_unstable;
>  static unsigned char lapic_detected_unstable;
>  static unsigned char lapic_marked_unstable;
>  
> -static void power_saving_mwait_init(void)
> +void power_saving_mwait_init(void)
>  {
>  	unsigned int eax, ebx, ecx, edx;
>  	unsigned int highest_cstate = 0;
> @@ -500,7 +501,7 @@ static const struct acpi_device_id pad_device_ids[] = {
>  };
>  MODULE_DEVICE_TABLE(acpi, pad_device_ids);
>  
> -static struct acpi_driver acpi_pad_driver = {
> +struct acpi_driver acpi_pad_driver = {
>  	.name = "processor_aggregator",
>  	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>  	.ids = pad_device_ids,
> @@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver = {
>  
>  static int __init acpi_pad_init(void)
>  {
> -	power_saving_mwait_init();
> -	if (power_saving_mwait_eax == 0)
> -		return -EINVAL;
> -
> -	return acpi_bus_register_driver(&acpi_pad_driver);
> +	return __acpi_pad_init();
>  }
>  
>  static void __exit acpi_pad_exit(void)
>  {
> -	acpi_bus_unregister_driver(&acpi_pad_driver);
> +	__acpi_pad_exit();
>  }
>  
>  module_init(acpi_pad_init);
> diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
> new file mode 100644
> index 0000000..1a1471d
> --- /dev/null
> +++ b/include/acpi/acpi_pad.h
> @@ -0,0 +1,61 @@
> +/*
> + *  acpi_pad.h - pad device helper for native and paravirt platform
> + *
> + *  Copyright (C) 2012, Intel Corporation.
> + *     Author: Liu, Jinsong <jinsong.liu@intel.com>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or (at
> + *  your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful, but
> + *  WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + *  General Public License for more details.
> + */
> +
> +#ifndef __ACPI_PAD_H__
> +#define __ACPI_PAD_H__
> +
> +#include <acpi/acpi_bus.h>
> +
> +extern unsigned long power_saving_mwait_eax;
> +extern struct acpi_driver acpi_pad_driver;
> +extern void power_saving_mwait_init(void);
> +
> +static inline int native_acpi_pad_init(void)
> +{
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	power_saving_mwait_init();
> +	if (power_saving_mwait_eax == 0)
> +		return -EINVAL;
> +
> +	return acpi_bus_register_driver(&acpi_pad_driver);
> +#else
> +	return 0;
> +#endif
> +}
> +
> +static inline void native_acpi_pad_exit(void)
> +{
> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> +	acpi_bus_unregister_driver(&acpi_pad_driver);
> +#endif
> +}
> +
> +#ifdef CONFIG_PARAVIRT
> +#include <asm/paravirt.h>
> +#else
> +static inline int __acpi_pad_init(void)
> +{
> +	return native_acpi_pad_init();
> +}
> +
> +static inline void __acpi_pad_exit(void)
> +{
> +	native_acpi_pad_exit();
> +}
> +#endif
> +
> +#endif /* __ACPI_PAD_H__ */
> -- 
> 1.7.1

--
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

Konrad Rzeszutek Wilk

2012-Feb-17 14:47 UTC

head link

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

On Fri, Feb 17, 2012 at 09:29:09AM -0500, Konrad Rzeszutek Wilk
wrote:> On Fri, Feb 17, 2012 at 08:56:43AM +0000, Liu, Jinsong wrote:
> > >From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00
2001
> > From: Liu, Jinsong <jinsong.liu@intel.com>
> > Date: Fri, 10 Feb 2012 20:32:50 +0800
> > Subject: [PATCH 1/3] PAD helper for native and paravirt platform
> > 
> > This patch is PAD (Processor Aggregator Device) helper.
> > It provides a native interface for natvie platform, and a template
> > for paravirt platform, so that os can implicitly hook to proper ops
accordingly.
> > The paravirt template will further redirect to Xen pv ops in later
patch for Xen
> >  core parking.
> 
> You need to CC the ACPI maintainer and the acpi mailing on this patch. I
did that
> for you in the CC.
> 
> 
> > 
> > Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> > ---
> >  arch/x86/include/asm/paravirt.h       |   10 +++++
> >  arch/x86/include/asm/paravirt_types.h |    7 ++++
> >  arch/x86/kernel/paravirt.c            |    9 +++++
> >  drivers/acpi/acpi_pad.c               |   15 +++-----
> >  include/acpi/acpi_pad.h               |   61
+++++++++++++++++++++++++++++++++
> >  5 files changed, 93 insertions(+), 9 deletions(-)
> >  create mode 100644 include/acpi/acpi_pad.h
> > 
> > diff --git a/arch/x86/include/asm/paravirt.h
b/arch/x86/include/asm/paravirt.h
> > index a7d2db9..02e6df0 100644
> > --- a/arch/x86/include/asm/paravirt.h
> > +++ b/arch/x86/include/asm/paravirt.h
> > @@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
> >  	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);
> >  }
> >  
> > +static inline int __acpi_pad_init(void)
> > +{
> > +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init);
> > +}
> > +
> > +static inline void __acpi_pad_exit(void)
> > +{
> > +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
> > +}
> > +
> >  static inline void write_cr0(unsigned long x)
> >  {
> >  	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
> > diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
> > index 8e8b9a4..61e20de 100644
> > --- a/arch/x86/include/asm/paravirt_types.h
> > +++ b/arch/x86/include/asm/paravirt_types.h
> > @@ -336,6 +336,11 @@ struct pv_lock_ops {
> >  	void (*spin_unlock)(struct arch_spinlock *lock);
> >  };
> >  
> > +struct pv_pad_ops {
> > +	int (*acpi_pad_init)(void);
> > +	void (*acpi_pad_exit)(void);
> > +};
> > +
Looking at this a bit closer I am not sure why you choose the paravirt
interface for this? There is another one - the x86 that could have been
choosen. Or introduce a new one that is specific to ACPI.

I am curious - what was the reason for using the paravirt interface?
I understand it does get the job done, but it seems a bit overkill when
something
simple could have been used?
> >  /* This contains all the paravirt structures: we get a convenient
> >   * number for each function using the offset which we use to indicate
> >   * what to patch. */
> > @@ -347,6 +352,7 @@ struct paravirt_patch_template {
> >  	struct pv_apic_ops pv_apic_ops;
> >  	struct pv_mmu_ops pv_mmu_ops;
> >  	struct pv_lock_ops pv_lock_ops;
> > +	struct pv_pad_ops pv_pad_ops;
> >  };
> >  
> >  extern struct pv_info pv_info;
> > @@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
> >  extern struct pv_apic_ops pv_apic_ops;
> >  extern struct pv_mmu_ops pv_mmu_ops;
> >  extern struct pv_lock_ops pv_lock_ops;
> > +extern struct pv_pad_ops pv_pad_ops;
> >  
> >  #define PARAVIRT_PATCH(x)					\
> >  	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
> > diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> > index d90272e..ec778f6 100644
> > --- a/arch/x86/kernel/paravirt.c
> > +++ b/arch/x86/kernel/paravirt.c
> > @@ -38,6 +38,8 @@
> >  #include <asm/tlbflush.h>
> >  #include <asm/timer.h>
> >  
> > +#include <acpi/acpi_pad.h>
> > +
> >  /* nop stub */
> >  void _paravirt_nop(void)
> >  {
> > @@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
> >  #ifdef CONFIG_PARAVIRT_SPINLOCKS
> >  		.pv_lock_ops = pv_lock_ops,
> >  #endif
> > +		.pv_pad_ops = pv_pad_ops,
> >  	};
> >  	return *((void **)&tmpl + type);
> >  }
> > @@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops = {
> >  	.set_fixmap = native_set_fixmap,
> >  };
> >  
> > +struct pv_pad_ops pv_pad_ops = {
> > +	.acpi_pad_init = native_acpi_pad_init,
> > +	.acpi_pad_exit = native_acpi_pad_exit,
> > +};
> > +
> >  EXPORT_SYMBOL_GPL(pv_time_ops);
> >  EXPORT_SYMBOL    (pv_cpu_ops);
> >  EXPORT_SYMBOL    (pv_mmu_ops);
> >  EXPORT_SYMBOL_GPL(pv_apic_ops);
> >  EXPORT_SYMBOL_GPL(pv_info);
> >  EXPORT_SYMBOL    (pv_irq_ops);
> > +EXPORT_SYMBOL_GPL(pv_pad_ops);
> > diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> > index a43fa1a..3f0fd27 100644
> > --- a/drivers/acpi/acpi_pad.c
> > +++ b/drivers/acpi/acpi_pad.c
> > @@ -30,6 +30,7 @@
> >  #include <linux/slab.h>
> >  #include <acpi/acpi_bus.h>
> >  #include <acpi/acpi_drivers.h>
> > +#include <acpi/acpi_pad.h>
> >  #include <asm/mwait.h>
> >  
> >  #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad"
> > @@ -37,14 +38,14 @@
> >  #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
> >  static DEFINE_MUTEX(isolated_cpus_lock);
> >  
> > -static unsigned long power_saving_mwait_eax;
> > +unsigned long power_saving_mwait_eax;
> >  
> >  static unsigned char tsc_detected_unstable;
> >  static unsigned char tsc_marked_unstable;
> >  static unsigned char lapic_detected_unstable;
> >  static unsigned char lapic_marked_unstable;
> >  
> > -static void power_saving_mwait_init(void)
> > +void power_saving_mwait_init(void)
> >  {
> >  	unsigned int eax, ebx, ecx, edx;
> >  	unsigned int highest_cstate = 0;
> > @@ -500,7 +501,7 @@ static const struct acpi_device_id
pad_device_ids[] = {
> >  };
> >  MODULE_DEVICE_TABLE(acpi, pad_device_ids);
> >  
> > -static struct acpi_driver acpi_pad_driver = {
> > +struct acpi_driver acpi_pad_driver = {
> >  	.name = "processor_aggregator",
> >  	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
> >  	.ids = pad_device_ids,
> > @@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver = {
> >  
> >  static int __init acpi_pad_init(void)
> >  {
> > -	power_saving_mwait_init();
> > -	if (power_saving_mwait_eax == 0)
> > -		return -EINVAL;
> > -
> > -	return acpi_bus_register_driver(&acpi_pad_driver);
> > +	return __acpi_pad_init();
> >  }
> >  
> >  static void __exit acpi_pad_exit(void)
> >  {
> > -	acpi_bus_unregister_driver(&acpi_pad_driver);
> > +	__acpi_pad_exit();
> >  }
> >  
> >  module_init(acpi_pad_init);
> > diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
> > new file mode 100644
> > index 0000000..1a1471d
> > --- /dev/null
> > +++ b/include/acpi/acpi_pad.h
> > @@ -0,0 +1,61 @@
> > +/*
> > + *  acpi_pad.h - pad device helper for native and paravirt platform
> > + *
> > + *  Copyright (C) 2012, Intel Corporation.
> > + *     Author: Liu, Jinsong <jinsong.liu@intel.com>
> > + *
> > + *  This program is free software; you can redistribute it and/or
modify
> > + *  it under the terms of the GNU General Public License as published
by
> > + *  the Free Software Foundation; either version 2 of the License, or
(at
> > + *  your option) any later version.
> > + *
> > + *  This program is distributed in the hope that it will be useful,
but
> > + *  WITHOUT ANY WARRANTY; without even the implied warranty of
> > + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + *  General Public License for more details.
> > + */
> > +
> > +#ifndef __ACPI_PAD_H__
> > +#define __ACPI_PAD_H__
> > +
> > +#include <acpi/acpi_bus.h>
> > +
> > +extern unsigned long power_saving_mwait_eax;
> > +extern struct acpi_driver acpi_pad_driver;
> > +extern void power_saving_mwait_init(void);
> > +
> > +static inline int native_acpi_pad_init(void)
> > +{
> > +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> > +	power_saving_mwait_init();
> > +	if (power_saving_mwait_eax == 0)
> > +		return -EINVAL;
> > +
> > +	return acpi_bus_register_driver(&acpi_pad_driver);
> > +#else
> > +	return 0;
> > +#endif
> > +}
> > +
> > +static inline void native_acpi_pad_exit(void)
> > +{
> > +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
> > +	acpi_bus_unregister_driver(&acpi_pad_driver);
> > +#endif
> > +}
> > +
> > +#ifdef CONFIG_PARAVIRT
> > +#include <asm/paravirt.h>
> > +#else
> > +static inline int __acpi_pad_init(void)
> > +{
> > +	return native_acpi_pad_init();
> > +}
> > +
> > +static inline void __acpi_pad_exit(void)
> > +{
> > +	native_acpi_pad_exit();
> > +}
> > +#endif
> > +
> > +#endif /* __ACPI_PAD_H__ */
> > -- 
> > 1.7.1
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel--
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

Liu, Jinsong

2012-Feb-17 17:59 UTC

head link

Re: [PATCH 1/3] PAD helper for native and paravirt platform

>> 
>> +static inline int __acpi_pad_init(void)
>> +{
>> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init); +}
>> +
>> +static inline void __acpi_pad_exit(void)
>> +{
>> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
>> +}
> 
> With this you, aiui, you aim at getting the calls patched. Are the
> callers of this really on performance critical paths? If not, the
> simpler approach of having an ops structure the fields of which get
> overwritten by 
> Xen initialization would seem a more appropriate approach.
> 
Yes, I agree. I code in this way just want to keep same coding style as other pv
functions of paravirt.h.
I update the patch w/ a simpler approach, and will post later.
Of course, we need Konrad''s comments.

Thanks,
Jinsong

Konrad Rzeszutek Wilk

2012-Feb-17 19:06 UTC

head link

Re: [PATCH 1/3] PAD helper for native and paravirt platform

On Fri, Feb 17, 2012 at 05:59:56PM +0000, Liu, Jinsong
wrote:> >> 
> >> +static inline int __acpi_pad_init(void)
> >> +{
> >> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init); +}
> >> +
> >> +static inline void __acpi_pad_exit(void)
> >> +{
> >> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
> >> +}
> > 
> > With this you, aiui, you aim at getting the calls patched. Are the
> > callers of this really on performance critical paths? If not, the
> > simpler approach of having an ops structure the fields of which get
> > overwritten by 
> > Xen initialization would seem a more appropriate approach.
> > 
> 
> Yes, I agree. I code in this way just want to keep same coding style as
other pv functions of paravirt.h.
> I update the patch w/ a simpler approach, and will post later.
> Of course, we need Konrad''s comments.
The thing is that the paravirt approach also impacts lguests. While I
don''t
think your patch will affect it, it just doesn''t seem like the right
place.

It seems that a more general approach, like the x86 one would be appropiate.
Or since this is ACPI related - perhaps in the drivers/acpi/osl.c ? - That is
all "OS dependent functions" and seem proper?

Liu, Jinsong

2012-Feb-19 12:14 UTC

head link

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Konrad Rzeszutek Wilk wrote:> On Fri, Feb 17, 2012 at 09:29:09AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Feb 17, 2012 at 08:56:43AM +0000, Liu, Jinsong wrote:
>>>> From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17
00:00:00
>>>> 2001 
>>> From: Liu, Jinsong <jinsong.liu@intel.com>
>>> Date: Fri, 10 Feb 2012 20:32:50 +0800
>>> Subject: [PATCH 1/3] PAD helper for native and paravirt platform
>>> 
>>> This patch is PAD (Processor Aggregator Device) helper.
>>> It provides a native interface for natvie platform, and a template
>>> for paravirt platform, so that os can implicitly hook to proper ops
>>> accordingly. 
>>> The paravirt template will further redirect to Xen pv ops in later
>>>  patch for Xen core parking.
>> 
>> You need to CC the ACPI maintainer and the acpi mailing on this
>> patch. I did that for you in the CC. 
>> 
>> 
>>> 
>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> ---
>>>  arch/x86/include/asm/paravirt.h       |   10 +++++
>>>  arch/x86/include/asm/paravirt_types.h |    7 ++++
>>>  arch/x86/kernel/paravirt.c            |    9 +++++
>>>  drivers/acpi/acpi_pad.c               |   15 +++-----
>>>  include/acpi/acpi_pad.h               |   61
>>>  +++++++++++++++++++++++++++++++++ 5 files changed, 93
>>>  insertions(+), 9 deletions(-) create mode 100644
>>> include/acpi/acpi_pad.h 
>>> 
>>> diff --git a/arch/x86/include/asm/paravirt.h
>>> b/arch/x86/include/asm/paravirt.h 
>>> index a7d2db9..02e6df0 100644
>>> --- a/arch/x86/include/asm/paravirt.h
>>> +++ b/arch/x86/include/asm/paravirt.h
>>> @@ -54,6 +54,16 @@ static inline unsigned long read_cr0(void)
>>>  	return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);  }
>>> 
>>> +static inline int __acpi_pad_init(void)
>>> +{
>>> +	return PVOP_CALL0(int, pv_pad_ops.acpi_pad_init); +}
>>> +
>>> +static inline void __acpi_pad_exit(void)
>>> +{
>>> +	PVOP_VCALL0(pv_pad_ops.acpi_pad_exit);
>>> +}
>>> +
>>>  static inline void write_cr0(unsigned long x)
>>>  {
>>>  	PVOP_VCALL1(pv_cpu_ops.write_cr0, x);
>>> diff --git a/arch/x86/include/asm/paravirt_types.h
>>> b/arch/x86/include/asm/paravirt_types.h index 8e8b9a4..61e20de
>>> 100644 --- a/arch/x86/include/asm/paravirt_types.h +++
>>> b/arch/x86/include/asm/paravirt_types.h @@ -336,6 +336,11 @@ struct
>>>  	pv_lock_ops { void (*spin_unlock)(struct arch_spinlock *lock);
>>>  };
>>> 
>>> +struct pv_pad_ops {
>>> +	int (*acpi_pad_init)(void);
>>> +	void (*acpi_pad_exit)(void);
>>> +};
>>> +
> 
> Looking at this a bit closer I am not sure why you choose the paravirt
> interface for this? There is another one - the x86 that could have
> been 
> choosen. Or introduce a new one that is specific to ACPI.
> 
> I am curious - what was the reason for using the paravirt interface?
> I understand it does get the job done, but it seems a bit overkill
> when something simple could have been used?
> 
It uses paravirt interface to avoid some code like ''xen_...''
in native code path (acpi_pad.c).
I''m not quite sure what does ''x86'' here mean? Adding
2 fields (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops?
seems it''s much simpler.

Thanks,
Jinsong
>>>  /* This contains all the paravirt structures: we get a convenient
>>>   * number for each function using the offset which we use to
>>> indicate 
>>>   * what to patch. */
>>> @@ -347,6 +352,7 @@ struct paravirt_patch_template {
>>>  	struct pv_apic_ops pv_apic_ops;
>>>  	struct pv_mmu_ops pv_mmu_ops;
>>>  	struct pv_lock_ops pv_lock_ops;
>>> +	struct pv_pad_ops pv_pad_ops;
>>>  };
>>> 
>>>  extern struct pv_info pv_info;
>>> @@ -357,6 +363,7 @@ extern struct pv_irq_ops pv_irq_ops;
>>>  extern struct pv_apic_ops pv_apic_ops;
>>>  extern struct pv_mmu_ops pv_mmu_ops;
>>>  extern struct pv_lock_ops pv_lock_ops;
>>> +extern struct pv_pad_ops pv_pad_ops;
>>> 
>>>  #define PARAVIRT_PATCH(x)					\
>>>  	(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
>>> diff --git a/arch/x86/kernel/paravirt.c
b/arch/x86/kernel/paravirt.c
>>> index d90272e..ec778f6 100644
>>> --- a/arch/x86/kernel/paravirt.c
>>> +++ b/arch/x86/kernel/paravirt.c
>>> @@ -38,6 +38,8 @@
>>>  #include <asm/tlbflush.h>
>>>  #include <asm/timer.h>
>>> 
>>> +#include <acpi/acpi_pad.h>
>>> +
>>>  /* nop stub */
>>>  void _paravirt_nop(void)
>>>  {
>>> @@ -132,6 +134,7 @@ static void *get_call_destination(u8 type)
>>>  #ifdef CONFIG_PARAVIRT_SPINLOCKS
>>>  		.pv_lock_ops = pv_lock_ops,
>>>  #endif
>>> +		.pv_pad_ops = pv_pad_ops,
>>>  	};
>>>  	return *((void **)&tmpl + type);
>>>  }
>>> @@ -480,9 +483,15 @@ struct pv_mmu_ops pv_mmu_ops = {
>>>  	.set_fixmap = native_set_fixmap,
>>>  };
>>> 
>>> +struct pv_pad_ops pv_pad_ops = {
>>> +	.acpi_pad_init = native_acpi_pad_init,
>>> +	.acpi_pad_exit = native_acpi_pad_exit,
>>> +};
>>> +
>>>  EXPORT_SYMBOL_GPL(pv_time_ops);
>>>  EXPORT_SYMBOL    (pv_cpu_ops);
>>>  EXPORT_SYMBOL    (pv_mmu_ops);
>>>  EXPORT_SYMBOL_GPL(pv_apic_ops);
>>>  EXPORT_SYMBOL_GPL(pv_info);
>>>  EXPORT_SYMBOL    (pv_irq_ops);
>>> +EXPORT_SYMBOL_GPL(pv_pad_ops);
>>> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
>>> index a43fa1a..3f0fd27 100644
>>> --- a/drivers/acpi/acpi_pad.c
>>> +++ b/drivers/acpi/acpi_pad.c
>>> @@ -30,6 +30,7 @@
>>>  #include <linux/slab.h>
>>>  #include <acpi/acpi_bus.h>
>>>  #include <acpi/acpi_drivers.h>
>>> +#include <acpi/acpi_pad.h>
>>>  #include <asm/mwait.h>
>>> 
>>>  #define ACPI_PROCESSOR_AGGREGATOR_CLASS	"acpi_pad" @@
-37,14
>>>  +38,14 @@ #define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
>>>  static DEFINE_MUTEX(isolated_cpus_lock);
>>> 
>>> -static unsigned long power_saving_mwait_eax;
>>> +unsigned long power_saving_mwait_eax;
>>> 
>>>  static unsigned char tsc_detected_unstable;
>>>  static unsigned char tsc_marked_unstable;
>>>  static unsigned char lapic_detected_unstable;
>>>  static unsigned char lapic_marked_unstable;
>>> 
>>> -static void power_saving_mwait_init(void)
>>> +void power_saving_mwait_init(void)
>>>  {
>>>  	unsigned int eax, ebx, ecx, edx;
>>>  	unsigned int highest_cstate = 0;
>>> @@ -500,7 +501,7 @@ static const struct acpi_device_id
>>>  pad_device_ids[] = {  }; MODULE_DEVICE_TABLE(acpi,
pad_device_ids);
>>> 
>>> -static struct acpi_driver acpi_pad_driver = {
>>> +struct acpi_driver acpi_pad_driver = {
>>>  	.name = "processor_aggregator",
>>>  	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>>>  	.ids = pad_device_ids,
>>> @@ -512,16 +513,12 @@ static struct acpi_driver acpi_pad_driver = {
>>> 
>>>  static int __init acpi_pad_init(void)
>>>  {
>>> -	power_saving_mwait_init();
>>> -	if (power_saving_mwait_eax == 0)
>>> -		return -EINVAL;
>>> -
>>> -	return acpi_bus_register_driver(&acpi_pad_driver); +	return
>>>  __acpi_pad_init(); }
>>> 
>>>  static void __exit acpi_pad_exit(void)
>>>  {
>>> -	acpi_bus_unregister_driver(&acpi_pad_driver);
>>> +	__acpi_pad_exit();
>>>  }
>>> 
>>>  module_init(acpi_pad_init);
>>> diff --git a/include/acpi/acpi_pad.h b/include/acpi/acpi_pad.h
>>> new file mode 100644
>>> index 0000000..1a1471d
>>> --- /dev/null
>>> +++ b/include/acpi/acpi_pad.h
>>> @@ -0,0 +1,61 @@
>>> +/*
>>> + *  acpi_pad.h - pad device helper for native and paravirt
>>> platform + * + *  Copyright (C) 2012, Intel Corporation.
>>> + *     Author: Liu, Jinsong <jinsong.liu@intel.com> + *
>>> + *  This program is free software; you can redistribute it and/or
>>> modify + *  it under the terms of the GNU General Public License as
>>> published by + *  the Free Software Foundation; either version 2 of
>>> the License, or (at + *  your option) any later version.
>>> + *
>>> + *  This program is distributed in the hope that it will be
>>> useful, but + *  WITHOUT ANY WARRANTY; without even the implied
>>> warranty of + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>> PURPOSE.  See the GNU + *  General Public License for more details.
>>> + */
>>> +
>>> +#ifndef __ACPI_PAD_H__
>>> +#define __ACPI_PAD_H__
>>> +
>>> +#include <acpi/acpi_bus.h>
>>> +
>>> +extern unsigned long power_saving_mwait_eax;
>>> +extern struct acpi_driver acpi_pad_driver;
>>> +extern void power_saving_mwait_init(void);
>>> +
>>> +static inline int native_acpi_pad_init(void)
>>> +{
>>> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
>>> +	power_saving_mwait_init();
>>> +	if (power_saving_mwait_eax == 0)
>>> +		return -EINVAL;
>>> +
>>> +	return acpi_bus_register_driver(&acpi_pad_driver); +#else
>>> +	return 0;
>>> +#endif
>>> +}
>>> +
>>> +static inline void native_acpi_pad_exit(void)
>>> +{
>>> +#ifdef CONFIG_ACPI_PROCESSOR_AGGREGATOR
>>> +	acpi_bus_unregister_driver(&acpi_pad_driver);
>>> +#endif
>>> +}
>>> +
>>> +#ifdef CONFIG_PARAVIRT
>>> +#include <asm/paravirt.h>
>>> +#else
>>> +static inline int __acpi_pad_init(void)
>>> +{
>>> +	return native_acpi_pad_init();
>>> +}
>>> +
>>> +static inline void __acpi_pad_exit(void)
>>> +{
>>> +	native_acpi_pad_exit();
>>> +}
>>> +#endif
>>> +
>>> +#endif /* __ACPI_PAD_H__ */
>>> --
>>> 1.7.1
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
--
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

Konrad Rzeszutek Wilk

2012-Feb-19 18:23 UTC

head link

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

> >>> +struct pv_pad_ops {
> >>> +	int (*acpi_pad_init)(void);
> >>> +	void (*acpi_pad_exit)(void);
> >>> +};
> >>> +
> > 
> > Looking at this a bit closer I am not sure why you choose the paravirt
> > interface for this? There is another one - the x86 that could have
> > been 
> > choosen. Or introduce a new one that is specific to ACPI.
> > 
> > I am curious - what was the reason for using the paravirt interface?
> > I understand it does get the job done, but it seems a bit overkill
> > when something simple could have been used?
> > 
> 
> It uses paravirt interface to avoid some code like
''xen_...'' in native code path (acpi_pad.c).
> I''m not quite sure what does ''x86'' here mean?
Adding 2 fields (acpi_pad_init/exit) in arch/x86/xen/enlighten.c -->
xen_cpu_ops? seems it''s much simpler.
arch/x86/include/asm/x86_init.h

But before you go that way let me ask you another question - can ACPI PAD
be used on ARM or IA64? If so, wouldn''t this fail compilation as this
pvops
structure is not defined on IA64?

The other thing I am not comfortable about is that the pvops structure
are used for low-level code. Not for higher up, like ACPI. For that another
structure seems more prudent. Perhaps something like the x86 one, but specific
to ACPI?
--
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

Liu, Jinsong

2012-Feb-21 05:49 UTC

head link

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Konrad Rzeszutek Wilk wrote:>>>>> +struct pv_pad_ops {
>>>>> +	int (*acpi_pad_init)(void);
>>>>> +	void (*acpi_pad_exit)(void);
>>>>> +};
>>>>> +
>>> 
>>> Looking at this a bit closer I am not sure why you choose the
>>> paravirt interface for this? There is another one - the x86 that
>>> could have been choosen. Or introduce a new one that is specific to
>>> ACPI. 
>>> 
>>> I am curious - what was the reason for using the paravirt
interface?
>>> I understand it does get the job done, but it seems a bit overkill
>>> when something simple could have been used?
>>> 
>> 
>> It uses paravirt interface to avoid some code like
''xen_...'' in
>> native code path (acpi_pad.c). 
>> I''m not quite sure what does ''x86'' here
mean? Adding 2 fields
>> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c --> xen_cpu_ops?
>> seems it''s much simpler.  
> 
> arch/x86/include/asm/x86_init.h
> 
> But before you go that way let me ask you another question - can ACPI
> PAD 
> be used on ARM or IA64? If so, wouldn''t this fail compilation as
this
> pvops structure is not defined on IA64?
Ideally ACPI PAD is not bound to some arch, so IMO it could be used at least on
IA64 (through currently no real PAD on IA64 platform as far as I know).
However, in native acpi_pad implementation, it indeed depends on X86 for reason
like mwait.
So for xen acpi_pad, I think it''s OK to choose x86, defining an
acpi_pad_ops at x86_init.c which would be overwritten when xen init.

Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as
''bool'', which would disable native acpi_pad module.

Your opinion?

Thanks,
Jinsong
> 
> The other thing I am not comfortable about is that the pvops structure
> are used for low-level code. Not for higher up, like ACPI. For that
> another structure seems more prudent. Perhaps something like the x86
> one, but specific to ACPI?
--
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

Konrad Rzeszutek Wilk

2012-Feb-21 14:27 UTC

head link

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

On Tue, Feb 21, 2012 at 05:49:58AM +0000, Liu, Jinsong
wrote:> Konrad Rzeszutek Wilk wrote:
> >>>>> +struct pv_pad_ops {
> >>>>> +	int (*acpi_pad_init)(void);
> >>>>> +	void (*acpi_pad_exit)(void);
> >>>>> +};
> >>>>> +
> >>> 
> >>> Looking at this a bit closer I am not sure why you choose the
> >>> paravirt interface for this? There is another one - the x86
that
> >>> could have been choosen. Or introduce a new one that is
specific to
> >>> ACPI. 
> >>> 
> >>> I am curious - what was the reason for using the paravirt
interface?
> >>> I understand it does get the job done, but it seems a bit
overkill
> >>> when something simple could have been used?
> >>> 
> >> 
> >> It uses paravirt interface to avoid some code like
''xen_...'' in
> >> native code path (acpi_pad.c). 
> >> I''m not quite sure what does ''x86'' here
mean? Adding 2 fields
> >> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c -->
xen_cpu_ops?
> >> seems it''s much simpler.  
> > 
> > arch/x86/include/asm/x86_init.h
> > 
> > But before you go that way let me ask you another question - can ACPI
> > PAD 
> > be used on ARM or IA64? If so, wouldn''t this fail compilation
as this
> > pvops structure is not defined on IA64?
> 
> Ideally ACPI PAD is not bound to some arch, so IMO it could be used at
least on IA64 (through currently no real PAD on IA64 platform as far as I know).
> However, in native acpi_pad implementation, it indeed depends on X86 for
reason like mwait.
> So for xen acpi_pad, I think it''s OK to choose x86, defining an
acpi_pad_ops at x86_init.c which would be overwritten when xen init.
OK, or in osl.c. We need Len to chime in here as I can see this expanding in the
future.> 
> Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as
''bool'', which would disable native acpi_pad module.
Ewww. No.> 
> Your opinion?
> 
> Thanks,
> Jinsong
> 
> > 
> > The other thing I am not comfortable about is that the pvops structure
> > are used for low-level code. Not for higher up, like ACPI. For that
> > another structure seems more prudent. Perhaps something like the x86
> > one, but specific to ACPI?--
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

Liu, Jinsong

2012-Feb-22 17:02 UTC

head link

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Konrad Rzeszutek Wilk wrote:> On Tue, Feb 21, 2012 at 05:49:58AM +0000, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>>>>>> +struct pv_pad_ops {
>>>>>>> +	int (*acpi_pad_init)(void);
>>>>>>> +	void (*acpi_pad_exit)(void);
>>>>>>> +};
>>>>>>> +
>>>>> 
>>>>> Looking at this a bit closer I am not sure why you choose
the
>>>>> paravirt interface for this? There is another one - the x86
that
>>>>> could have been choosen. Or introduce a new one that is
specific
>>>>> to ACPI. 
>>>>> 
>>>>> I am curious - what was the reason for using the paravirt
>>>>> interface? I understand it does get the job done, but it
seems a
>>>>> bit overkill when something simple could have been used?
>>>>> 
>>>> 
>>>> It uses paravirt interface to avoid some code like
''xen_...'' in
>>>> native code path (acpi_pad.c).
>>>> I''m not quite sure what does ''x86''
here mean? Adding 2 fields
>>>> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c -->
xen_cpu_ops?
>>>> seems it''s much simpler.
>>> 
>>> arch/x86/include/asm/x86_init.h
>>> 
>>> But before you go that way let me ask you another question - can
>>> ACPI PAD be used on ARM or IA64? If so, wouldn''t this fail
>>> compilation as this pvops structure is not defined on IA64?
>> 
>> Ideally ACPI PAD is not bound to some arch, so IMO it could be used
>> at least on IA64 (through currently no real PAD on IA64 platform as
>> far as I know). However, in native acpi_pad implementation, it
>> indeed depends on X86 for reason like mwait.  
>> So for xen acpi_pad, I think it''s OK to choose x86, defining
an
>> acpi_pad_ops at x86_init.c which would be overwritten when xen init. 
> 
> OK, or in osl.c. We need Len to chime in here as I can see this
> expanding in the future. 
>> 
>> Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as
>> ''bool'', which would disable native acpi_pad module. 
> 
> Ewww. No.
I''m OK with x86_init approach, but advantage of ''config
ACPI_PROCESSOR_AGGREGATOR as bool'' would get rid of X86/IA64/... arch
issue for xen (at least from coding view), through it need disable native
acpi_pad module (IMO acpi_pad module has not strong reason to must be so).
Have a re-consider of this approach? :-)

Thanks,
Jinsong
>> 
>> Your opinion?
>> 
>> Thanks,
>> Jinsong
>> 
>>> 
>>> The other thing I am not comfortable about is that the pvops
>>> structure are used for low-level code. Not for higher up, like
>>> ACPI. For that another structure seems more prudent. Perhaps
>>> something like the x86 one, but specific to ACPI?
--
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

Konrad Rzeszutek Wilk

2012-Feb-22 18:23 UTC

head link

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

On Wed, Feb 22, 2012 at 05:02:59PM +0000, Liu, Jinsong
wrote:> Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 21, 2012 at 05:49:58AM +0000, Liu, Jinsong wrote:
> >> Konrad Rzeszutek Wilk wrote:
> >>>>>>> +struct pv_pad_ops {
> >>>>>>> +	int (*acpi_pad_init)(void);
> >>>>>>> +	void (*acpi_pad_exit)(void);
> >>>>>>> +};
> >>>>>>> +
> >>>>> 
> >>>>> Looking at this a bit closer I am not sure why you
choose the
> >>>>> paravirt interface for this? There is another one -
the x86 that
> >>>>> could have been choosen. Or introduce a new one that
is specific
> >>>>> to ACPI. 
> >>>>> 
> >>>>> I am curious - what was the reason for using the
paravirt
> >>>>> interface? I understand it does get the job done, but
it seems a
> >>>>> bit overkill when something simple could have been
used?
> >>>>> 
> >>>> 
> >>>> It uses paravirt interface to avoid some code like
''xen_...'' in
> >>>> native code path (acpi_pad.c).
> >>>> I''m not quite sure what does
''x86'' here mean? Adding 2 fields
> >>>> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c -->
xen_cpu_ops?
> >>>> seems it''s much simpler.
> >>> 
> >>> arch/x86/include/asm/x86_init.h
> >>> 
> >>> But before you go that way let me ask you another question -
can
> >>> ACPI PAD be used on ARM or IA64? If so, wouldn''t this
fail
> >>> compilation as this pvops structure is not defined on IA64?
> >> 
> >> Ideally ACPI PAD is not bound to some arch, so IMO it could be
used
> >> at least on IA64 (through currently no real PAD on IA64 platform
as
> >> far as I know). However, in native acpi_pad implementation, it
> >> indeed depends on X86 for reason like mwait.  
> >> So for xen acpi_pad, I think it''s OK to choose x86,
defining an
> >> acpi_pad_ops at x86_init.c which would be overwritten when xen
init.
> > 
> > OK, or in osl.c. We need Len to chime in here as I can see this
> > expanding in the future. 
> >> 
> >> Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as
> >> ''bool'', which would disable native acpi_pad
module.
> > 
> > Ewww. No.
> 
> I''m OK with x86_init approach, but advantage of ''config
ACPI_PROCESSOR_AGGREGATOR as bool'' would get rid of X86/IA64/... arch
issue for xen (at least from coding view), through it need disable native
acpi_pad module (IMO acpi_pad module has not strong reason to must be so).
> Have a re-consider of this approach? :-)
But it is a compile option right? We wantone kernel that can do both
baremetal and Xen.
--
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

Liu, Jinsong

2012-Feb-23 13:26 UTC

head link

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Konrad Rzeszutek Wilk wrote:> On Wed, Feb 22, 2012 at 05:02:59PM +0000, Liu, Jinsong wrote:
>> Konrad Rzeszutek Wilk wrote:
>>> On Tue, Feb 21, 2012 at 05:49:58AM +0000, Liu, Jinsong wrote:
>>>> Konrad Rzeszutek Wilk wrote:
>>>>>>>>> +struct pv_pad_ops {
>>>>>>>>> +	int (*acpi_pad_init)(void);
>>>>>>>>> +	void (*acpi_pad_exit)(void);
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>> 
>>>>>>> Looking at this a bit closer I am not sure why you
choose the
>>>>>>> paravirt interface for this? There is another one -
the x86 that
>>>>>>> could have been choosen. Or introduce a new one
that is
>>>>>>> specific to ACPI. 
>>>>>>> 
>>>>>>> I am curious - what was the reason for using the
paravirt
>>>>>>> interface? I understand it does get the job done,
but it seems a
>>>>>>> bit overkill when something simple could have been
used?
>>>>>>> 
>>>>>> 
>>>>>> It uses paravirt interface to avoid some code like
''xen_...'' in
>>>>>> native code path (acpi_pad.c).
>>>>>> I''m not quite sure what does
''x86'' here mean? Adding 2 fields
>>>>>> (acpi_pad_init/exit) in arch/x86/xen/enlighten.c -->
xen_cpu_ops?
>>>>>> seems it''s much simpler.
>>>>> 
>>>>> arch/x86/include/asm/x86_init.h
>>>>> 
>>>>> But before you go that way let me ask you another question
- can
>>>>> ACPI PAD be used on ARM or IA64? If so, wouldn''t
this fail
>>>>> compilation as this pvops structure is not defined on IA64?
>>>> 
>>>> Ideally ACPI PAD is not bound to some arch, so IMO it could be
used
>>>> at least on IA64 (through currently no real PAD on IA64
platform as
>>>> far as I know). However, in native acpi_pad implementation, it
>>>> indeed depends on X86 for reason like mwait.
>>>> So for xen acpi_pad, I think it''s OK to choose x86,
defining an
>>>> acpi_pad_ops at x86_init.c which would be overwritten when xen
>>>> init. 
>>> 
>>> OK, or in osl.c. We need Len to chime in here as I can see this
>>> expanding in the future.
>>>> 
>>>> Another choice is to define config ACPI_PROCESSOR_AGGREGATOR as
>>>> ''bool'', which would disable native acpi_pad
module.
>>> 
>>> Ewww. No.
>> 
>> I''m OK with x86_init approach, but advantage of
''config
>> ACPI_PROCESSOR_AGGREGATOR as bool'' would get rid of
X86/IA64/...
>> arch issue for xen (at least from coding view), through it need
>> disable native acpi_pad module (IMO acpi_pad module has not strong
>> reason to must be so). Have a re-consider of this approach? :-)   
> 
> But it is a compile option right? We wantone kernel that can do both
> baremetal and Xen.
Sorry, I didn''t speak clear my approach.
The approach can enable kernel run both baremetal and Xen platform, and not bind
acpi pad logic to x86.
Send 2 patches as RFC.

Thanks
Jinsong--
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

Konrad Rzeszutek Wilk

2012-Mar-24 00:31 UTC

head link

Re: [PATCH 1/3] PAD helper for native and paravirt platform

On Fri, Feb 17, 2012 at 08:56:43AM +0000, Liu, Jinsong
wrote:> >From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00 2001
> From: Liu, Jinsong <jinsong.liu@intel.com>
> Date: Fri, 10 Feb 2012 20:32:50 +0800
> Subject: [PATCH 1/3] PAD helper for native and paravirt platform
> 
> This patch is PAD (Processor Aggregator Device) helper.
> It provides a native interface for natvie platform, and a template
> for paravirt platform, so that os can implicitly hook to proper ops
accordingly.
> The paravirt template will further redirect to Xen pv ops in later patch
for Xen
>  core parking.
Liu,

With this patch: "  xen/enlighten: Expose MWAIT and MWAIT_LEAF if
hypervisor OKs it." which is now in 3.4-rc0:
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blobdiff;f=arch/x86/xen/enlighten.c;h=b132ade26f778f2cfec7c2d5c7b6db48afe424d5;hp=4172af8ceeb363d06912af15bf89e8508752b794;hb=d4c6fa73fe984e504d52f3d6bba291fd76fe49f7;hpb=aab008db8063364dc3c8ccf4981c21124866b395)
it means that now that the drivers/acpi/acpi_pad.c can run
as is under Xen (as the MWAIT_LEAF is exposed) What is the impact
of that? Is the monitor call causing a trap to the hypervisor which will
ignore the call? Or will it have some more worrysome consequences?

Thanks!

Liu, Jinsong

2012-Mar-26 02:50 UTC

head link

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Konrad Rzeszutek Wilk wrote:> On Fri, Feb 17, 2012 at 08:56:43AM +0000, Liu, Jinsong wrote:
>>> From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17 00:00:00
>>> 2001 
>> From: Liu, Jinsong <jinsong.liu@intel.com>
>> Date: Fri, 10 Feb 2012 20:32:50 +0800
>> Subject: [PATCH 1/3] PAD helper for native and paravirt platform
>> 
>> This patch is PAD (Processor Aggregator Device) helper.
>> It provides a native interface for natvie platform, and a template
>> for paravirt platform, so that os can implicitly hook to proper ops
>> accordingly. The paravirt template will further redirect to Xen pv
>>  ops in later patch for Xen core parking.
> 
> Liu,
> 
> With this patch: "  xen/enlighten: Expose MWAIT and MWAIT_LEAF if
> hypervisor OKs it." which is now in 3.4-rc0:
>
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blobdiff;f=arch/x86/xen/enlighten.c;h=b132ade26f778f2cfec7c2d5c7b6db48afe424d5;hp=4172af8ceeb363d06912af15bf89e8508752b794;hb=d4c6fa73fe984e504d52f3d6bba291fd76fe49f7;hpb=aab008db8063364dc3c8ccf4981c21124866b395)
> it means that now that the drivers/acpi/acpi_pad.c can run
> as is under Xen (as the MWAIT_LEAF is exposed) What is the impact
> of that? Is the monitor call causing a trap to the hypervisor which
> will ignore the call? Or will it have some more worrysome
> consequences? 
> 
IMO this patch doesn''t affect acpi_pad logic (both native and xen
acpi_pad).
For native acpi_pad, it need mwait to enter deep Cx (but irrelative to this
patch);
For xen acpi_pad, it doesn''t depend on whether hypervisor expose mwait
or not. It simply parse ''pur'' obj and then hypercall to
hypervisor to do rest core_parking things (BTW, hypervisor core parking patches
have checkin in as c/s 25095/25096).

Thanks,
Jinsong--
To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Konrad Rzeszutek Wilk

2012-Mar-26 16:35 UTC

head link

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

On Mon, Mar 26, 2012 at 02:50:50AM +0000, Liu, Jinsong
wrote:> Konrad Rzeszutek Wilk wrote:
> > On Fri, Feb 17, 2012 at 08:56:43AM +0000, Liu, Jinsong wrote:
> >>> From f66a2df1392bbe69426387657a220177be50d58a Mon Sep 17
00:00:00
> >>> 2001 
> >> From: Liu, Jinsong <jinsong.liu@intel.com>
> >> Date: Fri, 10 Feb 2012 20:32:50 +0800
> >> Subject: [PATCH 1/3] PAD helper for native and paravirt platform
> >> 
> >> This patch is PAD (Processor Aggregator Device) helper.
> >> It provides a native interface for natvie platform, and a template
> >> for paravirt platform, so that os can implicitly hook to proper
ops
> >> accordingly. The paravirt template will further redirect to Xen pv
> >>  ops in later patch for Xen core parking.
> > 
> > Liu,
> > 
> > With this patch: "  xen/enlighten: Expose MWAIT and MWAIT_LEAF if
> > hypervisor OKs it." which is now in 3.4-rc0:
> >
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blobdiff;f=arch/x86/xen/enlighten.c;h=b132ade26f778f2cfec7c2d5c7b6db48afe424d5;hp=4172af8ceeb363d06912af15bf89e8508752b794;hb=d4c6fa73fe984e504d52f3d6bba291fd76fe49f7;hpb=aab008db8063364dc3c8ccf4981c21124866b395)
> > it means that now that the drivers/acpi/acpi_pad.c can run
> > as is under Xen (as the MWAIT_LEAF is exposed) What is the impact
> > of that? Is the monitor call causing a trap to the hypervisor which
> > will ignore the call? Or will it have some more worrysome
> > consequences? 
> > 
> 
> IMO this patch doesn''t affect acpi_pad logic (both native and xen
acpi_pad).
You are sure? The acpi_pad logic will now be activated so the native driver
will run under Xen. My question is - what is the impact of that?

My assumption is that the __monitor call will trap and we end up in the
hypervisor -
so that is not so bad, but not sure.

But what I wonder is if what is the impact of the _OST call by the native
driver?

Say the firmware tells us - please offline 4 CPUS (we have eight). We enter
''acpi_pad_handle_notify'' -  create four threads, and each
thread calls __monitor
(which ends up in the hypervisor - and the hypervisor might not persue the
__monitor call).

During this time, the Linux kernel calls the _OST with 4 CPUs and ..

what then? What happens if the _OST values are actually ignored (as it seems
it would be in this case?) Is that OK? Or is that going to lead to the
firmware turning off some of the cores anyhow?

> For native acpi_pad, it need mwait to enter deep Cx (but irrelative to this
patch);
The patch I pointed you to will expose the MWAIT_LEAF in the initial domain.
Meaning that the native acpi_pad code will run.
> For xen acpi_pad, it doesn''t depend on whether hypervisor expose
mwait or not. It simply parse ''pur'' obj and then hypercall to
hypervisor to do rest core_parking things (BTW, hypervisor core parking patches
have checkin in as c/s 25095/25096).
I get that, but for right now lets just focus on the native driver. I would like
to understand not only how it should function in baremetal but also in the
native case.
> 
> Thanks,
> Jinsong--
> To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Liu, Jinsong

2012-Mar-28 10:48 UTC

head link

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

>>> 
>>> Liu,
>>> 
>>> With this patch: "  xen/enlighten: Expose MWAIT and MWAIT_LEAF
if
>>> hypervisor OKs it." which is now in 3.4-rc0:
>>>
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blobdiff;f=arch/x86/xen/enlighten.c;h=b132ade26f778f2cfec7c2d5c7b6db48afe424d5;hp=4172af8ceeb363d06912af15bf89e8508752b794;hb=d4c6fa73fe984e504d52f3d6bba291fd76fe49f7;hpb=aab008db8063364dc3c8ccf4981c21124866b395)
>>> it means that now that the drivers/acpi/acpi_pad.c can run
>>> as is under Xen (as the MWAIT_LEAF is exposed) What is the impact
>>> of that? Is the monitor call causing a trap to the hypervisor which
>>> will ignore the call? Or will it have some more worrysome
>>> consequences? 
>>> 
>> 
>> IMO this patch doesn''t affect acpi_pad logic (both native and
xen
>> acpi_pad). 
> 
> You are sure? The acpi_pad logic will now be activated so the native
> driver 
> will run under Xen. My question is - what is the impact of that?
I know what you mean now. What I mean is, w/ xen_acpi_pad patches, native
acpi_pad only work under baremetal and xen_acpi_pad work under Xen (so no
problem exposing mwait). What you mean is, w/o xen_acpi_pad patches, native
acpi_pad will be actived under Xen and then risk occur ... I agree.

But just curious, what''s the purpose and benefit of exposing mwait to
dom0? I remember xen against doing so before.
> 
> My assumption is that the __monitor call will trap and we end up in
> the hypervisor - so that is not so bad, but not sure.
Have you added code to hypervisor side (do_invalid_op)? if not, I think it would
be problem (break dom0). Dom0 __monitor would trigger UD, then not handled by
hypervisor, and bounce back to dom0 kernel, and kill itself.

But the point is, if exposing mwait, it would be risk for all logic which
executed __monitor. So need add native_monitor/ xen_monitor.
> 
> But what I wonder is if what is the impact of the _OST call by the
> native driver? 
> 
> Say the firmware tells us - please offline 4 CPUS (we have eight). We
> enter ''acpi_pad_handle_notify'' -  create four threads,
and each
> thread calls __monitor (which ends up in the hypervisor - and the
> hypervisor might not persue the __monitor call).
> 
> During this time, the Linux kernel calls the _OST with 4 CPUs and ..
> 
> what then? What happens if the _OST values are actually ignored (as
> it seems 
> it would be in this case?) Is that OK? Or is that going to lead to the
> firmware turning off some of the cores anyhow?
Hmm, if __monitor was tolerated silently as you assume, it would bring problem
for _OST.

Thanks,
Jinsong

Jan Beulich

2012-Mar-28 12:42 UTC

head link

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

>>> On 28.03.12 at 12:48, "Liu, Jinsong"
<jinsong.liu@intel.com> wrote:
> But just curious, what''s the purpose and benefit of exposing mwait
to dom0?
> I remember xen against doing so before.
And I don''t recall anything having changed in that regard.

Jan

Konrad Rzeszutek Wilk

2012-Mar-28 14:27 UTC

head link

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

On Wed, Mar 28, 2012 at 01:42:45PM +0100, Jan Beulich
wrote:> >>> On 28.03.12 at 12:48, "Liu, Jinsong"
<jinsong.liu@intel.com> wrote:
> > But just curious, what''s the purpose and benefit of exposing
mwait to dom0?
So that cstate.c can evaluate properly the deeper C-states and
xen-acpi-processor
can upload them to the hypervisor.
> > I remember xen against doing so before.
> 
> And I don''t recall anything having changed in that regard.
Jan, you Acked the patch in question: https://lkml.org/lkml/2012/2/24/129
> 
> Jan
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Konrad Rzeszutek Wilk

2012-Mar-28 14:29 UTC

head link

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

On Wed, Mar 28, 2012 at 10:48:53AM +0000, Liu, Jinsong
wrote:> >>> 
> >>> Liu,
> >>> 
> >>> With this patch: "  xen/enlighten: Expose MWAIT and
MWAIT_LEAF if
> >>> hypervisor OKs it." which is now in 3.4-rc0:
> >>>
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blobdiff;f=arch/x86/xen/enlighten.c;h=b132ade26f778f2cfec7c2d5c7b6db48afe424d5;hp=4172af8ceeb363d06912af15bf89e8508752b794;hb=d4c6fa73fe984e504d52f3d6bba291fd76fe49f7;hpb=aab008db8063364dc3c8ccf4981c21124866b395)
> >>> it means that now that the drivers/acpi/acpi_pad.c can run
> >>> as is under Xen (as the MWAIT_LEAF is exposed) What is the
impact
> >>> of that? Is the monitor call causing a trap to the hypervisor
which
> >>> will ignore the call? Or will it have some more worrysome
> >>> consequences? 
> >>> 
> >> 
> >> IMO this patch doesn''t affect acpi_pad logic (both native
and xen
> >> acpi_pad). 
> > 
> > You are sure? The acpi_pad logic will now be activated so the native
> > driver 
> > will run under Xen. My question is - what is the impact of that?
> 
> I know what you mean now. What I mean is, w/ xen_acpi_pad patches, native
acpi_pad only work under baremetal and xen_acpi_pad work under Xen (so no
problem exposing mwait). What you mean is, w/o xen_acpi_pad patches, native
acpi_pad will be actived under Xen and then risk occur ... I agree.
Can you test that? And see what happens please? I don''t have the
hardware
with _PUD.
> 
> But just curious, what''s the purpose and benefit of exposing mwait
to dom0? I remember xen against doing so before.
To expose deeper C-states to cstate.c so that xen-acpi-processor can then upload
said states to the hypervisor.
> 
> > 
> > My assumption is that the __monitor call will trap and we end up in
> > the hypervisor - so that is not so bad, but not sure.
> 
> Have you added code to hypervisor side (do_invalid_op)? if not, I think it
would be problem (break dom0). Dom0 __monitor would trigger UD, then not handled
by hypervisor, and bounce back to dom0 kernel, and kill itself.
No, that is why I am asking you.> 
> But the point is, if exposing mwait, it would be risk for all logic which
executed __monitor. So need add native_monitor/ xen_monitor.
Argh.> 
> > 
> > But what I wonder is if what is the impact of the _OST call by the
> > native driver? 
> > 
> > Say the firmware tells us - please offline 4 CPUS (we have eight). We
> > enter ''acpi_pad_handle_notify'' -  create four
threads, and each
> > thread calls __monitor (which ends up in the hypervisor - and the
> > hypervisor might not persue the __monitor call).
> > 
> > During this time, the Linux kernel calls the _OST with 4 CPUs and ..
> > 
> > what then? What happens if the _OST values are actually ignored (as
> > it seems 
> > it would be in this case?) Is that OK? Or is that going to lead to the
> > firmware turning off some of the cores anyhow?
> 
> Hmm, if __monitor was tolerated silently as you assume, it would bring
problem for _OST.
What kind of problems?> 
> Thanks,
> Jinsong
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Jan Beulich

2012-Mar-28 14:52 UTC

head link

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

>>> On 28.03.12 at 16:27, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Wed, Mar 28, 2012 at 01:42:45PM +0100, Jan Beulich wrote:
>> >>> On 28.03.12 at 12:48, "Liu, Jinsong"
<jinsong.liu@intel.com> wrote:
>> > But just curious, what''s the purpose and benefit of
exposing mwait to dom0?
> 
> 
> So that cstate.c can evaluate properly the deeper C-states and 
> xen-acpi-processor
> can upload them to the hypervisor.
> 
>> > I remember xen against doing so before.
>> 
>> And I don''t recall anything having changed in that regard.
> 
> Jan, you Acked the patch in question: https://lkml.org/lkml/2012/2/24/129 
But that isn''t a Xen patch. Xen isn''t (and shouldn''t
be) exposing mwait.

Jan

Liu, Jinsong

2012-Mar-29 05:28 UTC

head link

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Konrad Rzeszutek Wilk wrote:> On Wed, Mar 28, 2012 at 10:48:53AM +0000, Liu, Jinsong wrote:
>>>>> 
>>>>> Liu,
>>>>> 
>>>>> With this patch: "  xen/enlighten: Expose MWAIT and
MWAIT_LEAF if
>>>>> hypervisor OKs it." which is now in 3.4-rc0:
>>>>>
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blobdiff;f=arch/x86/xen/enlighten.c;h=b132ade26f778f2cfec7c2d5c7b6db48afe424d5;hp=4172af8ceeb363d06912af15bf89e8508752b794;hb=d4c6fa73fe984e504d52f3d6bba291fd76fe49f7;hpb=aab008db8063364dc3c8ccf4981c21124866b395)
>>>>> it means that now that the drivers/acpi/acpi_pad.c can run
>>>>> as is under Xen (as the MWAIT_LEAF is exposed) What is the
impact
>>>>> of that? Is the monitor call causing a trap to the
hypervisor
>>>>> which will ignore the call? Or will it have some more
worrysome
>>>>> consequences? 
>>>>> 
>>>> 
>>>> IMO this patch doesn''t affect acpi_pad logic (both
native and xen
>>>> acpi_pad).
>>> 
>>> You are sure? The acpi_pad logic will now be activated so the
>>> native driver will run under Xen. My question is - what is the
>>> impact of that? 
>> 
>> I know what you mean now. What I mean is, w/ xen_acpi_pad patches,
>> native acpi_pad only work under baremetal and xen_acpi_pad work
>> under Xen (so no problem exposing mwait). What you mean is, w/o
>> xen_acpi_pad patches, native acpi_pad will be actived under Xen and
>> then risk occur ... I agree.    
> 
> Can you test that? And see what happens please? I don''t have the
> hardware 
> with _PUD.
I don''t have this hardware neither. We test core parking by software
simulation.
> 
>> 
>> But just curious, what''s the purpose and benefit of exposing
mwait
>> to dom0? I remember xen against doing so before. 
> 
> To expose deeper C-states to cstate.c so that xen-acpi-processor can
> then upload said states to the hypervisor.
> 
>> 
>>> 
>>> My assumption is that the __monitor call will trap and we end up in
>>> the hypervisor - so that is not so bad, but not sure.
>> 
>> Have you added code to hypervisor side (do_invalid_op)? if not, I
>> think it would be problem (break dom0). Dom0 __monitor would trigger
>> UD, then not handled by hypervisor, and bounce back to dom0 kernel,
>> and kill itself.   
> 
> No, that is why I am asking you.
>> 
>> But the point is, if exposing mwait, it would be risk for all logic
>> which executed __monitor. So need add native_monitor/ xen_monitor. 
> 
> Argh.
>> 
>>> 
>>> But what I wonder is if what is the impact of the _OST call by the
>>> native driver? 
>>> 
>>> Say the firmware tells us - please offline 4 CPUS (we have eight).
>>> We enter ''acpi_pad_handle_notify'' -  create four
threads, and each
>>> thread calls __monitor (which ends up in the hypervisor - and the
>>> hypervisor might not persue the __monitor call).
>>> 
>>> During this time, the Linux kernel calls the _OST with 4 CPUs and
..
>>> 
>>> what then? What happens if the _OST values are actually ignored (as
>>> it seems it would be in this case?) Is that OK? Or is that going to
>>> lead to the firmware turning off some of the cores anyhow?
>> 
>> Hmm, if __monitor was tolerated silently as you assume, it would
>> bring problem for _OST. 
> 
> What kind of problems?
_OST report that there are X cpus take action but in fact not guaranteed.

Thanks,
Jinsong--
To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Xen devel - Feb 2012 - [PATCH 1/3] PAD helper for native and paravirt platform

[PATCH 1/3] PAD helper for native and paravirt platform

Re: [PATCH 1/3] PAD helper for native and paravirt platform

Re: [PATCH 1/3] PAD helper for native and paravirt platform

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Re: [PATCH 1/3] PAD helper for native and paravirt platform

Re: [PATCH 1/3] PAD helper for native and paravirt platform

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Re: [PATCH 1/3] PAD helper for native and paravirt platform

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

Re: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform