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

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

[Konrad Rzeszutek Wilk]

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

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

[Konrad Rzeszutek Wilk]

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

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

[Liu, Jinsong]

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

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

[Konrad Rzeszutek Wilk]

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

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

[Liu, Jinsong]

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?

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

[Konrad Rzeszutek Wilk]

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?

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

[Liu, Jinsong]

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?

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

[Konrad Rzeszutek Wilk]

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.

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

[Liu, Jinsong]

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