[PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Yu Zhiguo]

routines 'xen_register_gsi' and 'xen_teardown_msi_dev' cannot be used
unless macro 'CONFIG_XEN' is defined, otherwise build error occurs.

Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>
---
 arch/x86/kernel/acpi/boot.c    |    2 ++
 arch/x86/kernel/apic/io_apic.c |    4 ++++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 144b7d7..e2cd426 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -472,9 +472,11 @@ int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
 	int irq;
 	unsigned int plat_gsi = gsi;
 
+#ifdef CONFIG_XEN
 	irq = xen_register_gsi(gsi, trigger, polarity);
 	if (irq >= 0)
 		return irq;
+#endif
 
 #ifdef CONFIG_PCI
 	/*
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index eb263ec..123e554 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3564,8 +3564,10 @@ int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 	if (type == PCI_CAP_ID_MSI && nvec > 1)
 		return 1;
 
+#ifdef CONFIG_XEN
 	if (xen_domain())
 		return xen_setup_msi_irqs(dev, nvec, type);
+#endif
 
 	node = dev_to_node(&dev->dev);
 	irq_want = nr_irqs_gsi;
@@ -3626,10 +3628,12 @@ void arch_teardown_msi_irqs(struct pci_dev *dev)
 {
 	struct msi_desc *entry;
 
+#ifdef CONFIG_XEN
 	/* If we are non-privileged PV domain, we have to
 	* to call xen_teardown_msi_dev first. */
 	if (xen_domain())
 		xen_teardown_msi_dev(dev);
+#endif
 
 	list_for_each_entry(entry, &dev->msi_list, list) {
 		int i, nvec;
-- 
1.5.4.2

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Konrad Rzeszutek Wilk]

On Fri, Apr 16, 2010 at 10:07:19AM +0800, Yu Zhiguo wrote:
> 
> routines 'xen_register_gsi' and 'xen_teardown_msi_dev' cannot be used
> unless macro 'CONFIG_XEN' is defined, otherwise build error occurs.

There has to be a better of doing this. Aren't the
xen_register_gsi defined in the header files? How about making in the
header file the #ifdef CONFIG_XEN there?

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Yu Zhiguo]

Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 16, 2010 at 10:07:19AM +0800, Yu Zhiguo wrote:
>> routines 'xen_register_gsi' and 'xen_teardown_msi_dev' cannot be used
>> unless macro 'CONFIG_XEN' is defined, otherwise build error occurs.
> 
> There has to be a better of doing this. Aren't the
> xen_register_gsi defined in the header files? How about making in the
> header file the #ifdef CONFIG_XEN there?
> 
> 

In fact, 'xen_register_gsi' is declared in header file 'asm/xen/pci.h'
with '#ifdef CONFIG_XEN', please refer to the following code.

So 'acpi/boot.c' can use it but should check '#ifdef CONFIG_XEN'.
What's your opinion?

-----------------------asm/xen/pci.h----------------------
#ifdef CONFIG_XEN
...
#ifdef CONFIG_XEN_DOM0_PCI
int xen_register_gsi(u32 gsi, int triggering, int polarity);
...
#else
static inline int xen_register_gsi(u32 gsi, int triggering, int polarity)
{
        return -1;
}
...
#endif



Regards
Yu Zhiguo

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Jeremy Fitzhardinge]

On 04/17/2010 08:56 PM, Yu Zhiguo wrote:
> Konrad Rzeszutek Wilk wrote:
>   
>> On Fri, Apr 16, 2010 at 10:07:19AM +0800, Yu Zhiguo wrote:
>>     
>>> routines 'xen_register_gsi' and 'xen_teardown_msi_dev' cannot be used
>>> unless macro 'CONFIG_XEN' is defined, otherwise build error occurs.
>>>       
>> There has to be a better of doing this. Aren't the
>> xen_register_gsi defined in the header files? How about making in the
>> header file the #ifdef CONFIG_XEN there?
>>
>>
>>     
> In fact, 'xen_register_gsi' is declared in header file 'asm/xen/pci.h'
> with '#ifdef CONFIG_XEN', please refer to the following code.
>
> So 'acpi/boot.c' can use it but should check '#ifdef CONFIG_XEN'.
> What's your opinion?
>
> -----------------------asm/xen/pci.h----------------------
> #ifdef CONFIG_XEN
> ...
> #ifdef CONFIG_XEN_DOM0_PCI
> int xen_register_gsi(u32 gsi, int triggering, int polarity);
> ...
> #else
> static inline int xen_register_gsi(u32 gsi, int triggering, int polarity)
> {
>         return -1;
> }
> ...
>   

This is a good way of handling it.

    J

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Konrad Rzeszutek Wilk]

On Sat, Apr 17, 2010 at 09:46:18PM -0700, Jeremy Fitzhardinge wrote:
> On 04/17/2010 08:56 PM, Yu Zhiguo wrote:
> > Konrad Rzeszutek Wilk wrote:
> >   
> >> On Fri, Apr 16, 2010 at 10:07:19AM +0800, Yu Zhiguo wrote:
> >>     
> >>> routines 'xen_register_gsi' and 'xen_teardown_msi_dev' cannot be used
> >>> unless macro 'CONFIG_XEN' is defined, otherwise build error occurs.
> >>>       
> >> There has to be a better of doing this. Aren't the
> >> xen_register_gsi defined in the header files? How about making in the
> >> header file the #ifdef CONFIG_XEN there?
> >>
> >>
> >>     
> > In fact, 'xen_register_gsi' is declared in header file 'asm/xen/pci.h'
> > with '#ifdef CONFIG_XEN', please refer to the following code.
> >
> > So 'acpi/boot.c' can use it but should check '#ifdef CONFIG_XEN'.
> > What's your opinion?
> >
> > -----------------------asm/xen/pci.h----------------------
> > #ifdef CONFIG_XEN
> > ...
> > #ifdef CONFIG_XEN_DOM0_PCI
> > int xen_register_gsi(u32 gsi, int triggering, int polarity);
> > ...
> > #else

So this #else is for the CONFIG_XEN_DOM0_PCI..
> > static inline int xen_register_gsi(u32 gsi, int triggering, int polarity)
> > {
> >         return -1;
> > }

perhaps add:

#else /* This is for CONFIG_XEN */

static inline int xen_register_gsi(...)
{

}
#endif

Or maybe better take out the xen_register_gsi out of this double
#ifdef and move it to its own. Say:


#if !defined(CONFIG_XEN)
static int xen_register_gsi(..)

#endif


> > ...
> >   
> 
> This is a good way of handling it.

The header file change or the #ifdef in the acpi/boot.c file?
> 
>     J
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Jeremy Fitzhardinge]

On 04/19/2010 06:30 AM, Konrad Rzeszutek Wilk wrote:
>>> ...
>>>   
>>>       
>> This is a good way of handling it.
>>     
> The header file change or the #ifdef in the acpi/boot.c file?
>   

Adding stub static inlines is almost always preferable to open-coded
#ifdefs in .c files.  But we're growing a bit of an #ifdef thicket in
there...

    J

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Yu Zhiguo]

Hi, Konrad 

Konrad Rzeszutek Wilk wrote:
> 
> perhaps add:
> 
> #else /* This is for CONFIG_XEN */
> 
> static inline int xen_register_gsi(...)
> {
> 
> }
> #endif
> 
> Or maybe better take out the xen_register_gsi out of this double
> #ifdef and move it to its own. Say:
> 
> 
> #if !defined(CONFIG_XEN)
> static int xen_register_gsi(..)
> 
> #endif
> 
> 
>>> ...
>>>   
>> This is a good way of handling it.
> 
> The header file change or the #ifdef in the acpi/boot.c file?

 Thanks for your explanation, I agree it is also a good idea.
But if jeremy think adding #ifdef is ok, I will not fix this patch.


-- 
Regards
Yu Zhiguo

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Konrad Rzeszutek Wilk]

> >> This is a good way of handling it.
> > 
> > The header file change or the #ifdef in the acpi/boot.c file?
> 
>  Thanks for your explanation, I agree it is also a good idea.
> But if jeremy think adding #ifdef is ok, I will not fix this patch.

Huh? I thought that Jeremy mentioned that the #ifdef in the header file
is the way to go. I was anticipating a patch from you for this... since
I figured it isn't just as easy as that but there is probably some edge
case I hadn't thought of.

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Yu Zhiguo]

Konrad Rzeszutek Wilk wrote:
>>>> This is a good way of handling it.
>>> The header file change or the #ifdef in the acpi/boot.c file?
>>  Thanks for your explanation, I agree it is also a good idea.
>> But if jeremy think adding #ifdef is ok, I will not fix this patch.
> 
> Huh? I thought that Jeremy mentioned that the #ifdef in the header file
> is the way to go. I was anticipating a patch from you for this... since
> I figured it isn't just as easy as that but there is probably some edge
> case I hadn't thought of.
> 

But what about #if defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)?

method-1) fix it in *.c

method-2)
> perhaps add:
> 
> #else /* This is for CONFIG_XEN */
> 
> static inline int xen_register_gsi(...)
> {
> 
> }
> #endif
> 

Do you mean duplicate codes are ok?
It will be more complex if there are more macros.

method-3)
> Or maybe better take out the xen_register_gsi out of this double
> #ifdef and move it to its own. Say:
> 
> 
> #if !defined(CONFIG_XEN)
> static int xen_register_gsi(..)
> 
> #endif

We must use #if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)).
It is ugly, especially if there are more macros.

method-4)
If we perfer to fix it in header file, another method, we can use weak attribute of gcc.

So there are four method to fix this bug now, I think the fix *.c is easiest.
What's your opinion?

-- 
Regards
Yu Zhiguo

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Konrad Rzeszutek Wilk]

> method-3)
> > Or maybe better take out the xen_register_gsi out of this double
> > #ifdef and move it to its own. Say:
> > 
> > 
> > #if !defined(CONFIG_XEN)
> > static int xen_register_gsi(..)
> > 
> > #endif
> 
> We must use #if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)).
> It is ugly, especially if there are more macros.

Lets go with this one. Maybe after this is done there will be a way to
unmangle this spaghetti mess.

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Yu Zhiguo]

Konrad Rzeszutek Wilk wrote:
>> method-3)
>>> Or maybe better take out the xen_register_gsi out of this double
>>> #ifdef and move it to its own. Say:
>>>
>>>
>>> #if !defined(CONFIG_XEN)
>>> static int xen_register_gsi(..)
>>>
>>> #endif
>> We must use #if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)).
>> It is ugly, especially if there are more macros.
> 
> Lets go with this one. Maybe after this is done there will be a way to
> unmangle this spaghetti mess.
> 
> 
> 

OK, please refer to this new version:

----------------

routines 'xen_register_gsi' and 'xen_setup_msi_irqs' cannot be used
unless macro 'CONFIG_XEN' is defined, otherwise build error occurs.
So fix them in the header file.

Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>
---
 arch/x86/include/asm/xen/pci.h |   55 +++++++++++++++++++++------------------
 1 files changed, 30 insertions(+), 25 deletions(-)

diff --git a/arch/x86/include/asm/xen/pci.h b/arch/x86/include/asm/xen/pci.h
index 650645d..27e0667 100644
--- a/arch/x86/include/asm/xen/pci.h
+++ b/arch/x86/include/asm/xen/pci.h
@@ -14,36 +14,12 @@ void xen_teardown_msi_dev(struct pci_dev *dev);
 int xen_find_device_domain_owner(struct pci_dev *dev);
 int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t domain);
 int xen_unregister_device_domain_owner(struct pci_dev *dev);
-
-#else
-static inline int xen_register_gsi(u32 gsi, int triggering, int polarity)
-{
-	return -1;
-}
-static inline int xen_find_device_domain_owner(struct pci_dev *dev)
-{
-	return -1;
-}
-static inline int xen_register_device_domain_owner(struct pci_dev *dev,
-						   uint16_t domain)
-{
- 	return -1;
-}
-static inline int xen_unregister_device_domain_owner(struct pci_dev *dev)
-{
- 	return -1;
-}
-static inline void xen_teardown_msi_dev(struct pci_dev *dev) { }
 #endif
 
 #if defined(CONFIG_PCI_MSI) && defined(CONFIG_XEN_DOM0_PCI)
 int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
-#else
-static inline int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
-{
-	return -1;
-}
 #endif
+
 #if defined(CONFIG_PCI_MSI)
 
 /* The drivers/pci/xen-pcifront.c sets this structure to
@@ -97,4 +73,33 @@ static inline int xen_create_msi_irq(struct pci_dev *dev,
 	return -1;
 }
 #endif
+
+#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI))
+static inline int xen_register_gsi(u32 gsi, int triggering, int polarity)
+{
+	return -1;
+}
+static inline int xen_find_device_domain_owner(struct pci_dev *dev)
+{
+	return -1;
+}
+static inline int xen_register_device_domain_owner(struct pci_dev *dev,
+						   uint16_t domain)
+{
+ 	return -1;
+}
+static inline int xen_unregister_device_domain_owner(struct pci_dev *dev)
+{
+ 	return -1;
+}
+static inline void xen_teardown_msi_dev(struct pci_dev *dev) { }
+#endif
+
+#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && \
+	(!defined(CONFIG_PCI_MSI) || !defined(CONFIG_XEN_DOM0_PCI)))
+static inline int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+	return -1;
+}
+#endif
 #endif	/* _ASM_X86_XEN_PCI_H */
-- 
1.5.4.2

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Jeremy Fitzhardinge]

On 04/21/2010 06:53 AM, Yu Zhiguo wrote:
> Konrad Rzeszutek Wilk wrote:
>   
>>> method-3)
>>>       
>>>> Or maybe better take out the xen_register_gsi out of this double
>>>> #ifdef and move it to its own. Say:
>>>>
>>>>
>>>> #if !defined(CONFIG_XEN)
>>>> static int xen_register_gsi(..)
>>>>
>>>> #endif
>>>>         
>>> We must use #if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)).
>>> It is ugly, especially if there are more macros.
>>>       
>> Lets go with this one. Maybe after this is done there will be a way to
>> unmangle this spaghetti mess.
>>
>>
>>
>>     
> OK, please refer to this new version:
>
> ----------------
>
> routines 'xen_register_gsi' and 'xen_setup_msi_irqs' cannot be used
> unless macro 'CONFIG_XEN' is defined, otherwise build error occurs.
> So fix them in the header file.
>
> Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>
> ---
>  arch/x86/include/asm/xen/pci.h |   55 +++++++++++++++++++++------------------
>  1 files changed, 30 insertions(+), 25 deletions(-)
>
> diff --git a/arch/x86/include/asm/xen/pci.h b/arch/x86/include/asm/xen/pci.h
> index 650645d..27e0667 100644
> --- a/arch/x86/include/asm/xen/pci.h
> +++ b/arch/x86/include/asm/xen/pci.h
> @@ -14,36 +14,12 @@ void xen_teardown_msi_dev(struct pci_dev *dev);
>  int xen_find_device_domain_owner(struct pci_dev *dev);
>  int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t domain);
>  int xen_unregister_device_domain_owner(struct pci_dev *dev);
> -
> -#else
> -static inline int xen_register_gsi(u32 gsi, int triggering, int polarity)
> -{
> -	return -1;
> -}
> -static inline int xen_find_device_domain_owner(struct pci_dev *dev)
> -{
> -	return -1;
> -}
> -static inline int xen_register_device_domain_owner(struct pci_dev *dev,
> -						   uint16_t domain)
> -{
> - 	return -1;
> -}
> -static inline int xen_unregister_device_domain_owner(struct pci_dev *dev)
> -{
> - 	return -1;
> -}
> -static inline void xen_teardown_msi_dev(struct pci_dev *dev) { }
>  #endif
>  
>  #if defined(CONFIG_PCI_MSI) && defined(CONFIG_XEN_DOM0_PCI)
>  int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
> -#else
> -static inline int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> -{
> -	return -1;
> -}
>  #endif
> +
>  #if defined(CONFIG_PCI_MSI)
>  
>  /* The drivers/pci/xen-pcifront.c sets this structure to
> @@ -97,4 +73,33 @@ static inline int xen_create_msi_irq(struct pci_dev *dev,
>  	return -1;
>  }
>  #endif
> +
> +#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI))
>   

As I mentioned in the other mail, there's no need to test CONFIG_XEN.

> +static inline int xen_register_gsi(u32 gsi, int triggering, int polarity)
> +{
> +	return -1;
> +}
> +static inline int xen_find_device_domain_owner(struct pci_dev *dev)
> +{
> +	return -1;
> +}
> +static inline int xen_register_device_domain_owner(struct pci_dev *dev,
> +						   uint16_t domain)
> +{
> + 	return -1;
> +}
> +static inline int xen_unregister_device_domain_owner(struct pci_dev *dev)
> +{
> + 	return -1;
> +}
> +static inline void xen_teardown_msi_dev(struct pci_dev *dev) { }
> +#endif
> +
> +#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && \
> +	(!defined(CONFIG_PCI_MSI) || !defined(CONFIG_XEN_DOM0_PCI)))
>   

Likewise.

    J

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Yu Zhiguo]

Hi jeremy,

Jeremy Fitzhardinge wrote:
>>  #endif
>> +
>> +#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI))
>>   
> 
> As I mentioned in the other mail, there's no need to test CONFIG_XEN.
> 

Indeed, thanks for your hint.
Correct now, please refer to the following.

------------------------

routines 'xen_register_gsi' and 'xen_setup_msi_irqs' cannot be used
unless macro 'CONFIG_XEN' is defined, otherwise build error occurs.
So fix them in the header file.

Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>
---
 arch/x86/include/asm/xen/pci.h |   54 +++++++++++++++++++++------------------
 1 files changed, 29 insertions(+), 25 deletions(-)

diff --git a/arch/x86/include/asm/xen/pci.h b/arch/x86/include/asm/xen/pci.h
index 650645d..56b15d1 100644
--- a/arch/x86/include/asm/xen/pci.h
+++ b/arch/x86/include/asm/xen/pci.h
@@ -14,36 +14,12 @@ void xen_teardown_msi_dev(struct pci_dev *dev);
 int xen_find_device_domain_owner(struct pci_dev *dev);
 int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t domain);
 int xen_unregister_device_domain_owner(struct pci_dev *dev);
-
-#else
-static inline int xen_register_gsi(u32 gsi, int triggering, int polarity)
-{
-	return -1;
-}
-static inline int xen_find_device_domain_owner(struct pci_dev *dev)
-{
-	return -1;
-}
-static inline int xen_register_device_domain_owner(struct pci_dev *dev,
-						   uint16_t domain)
-{
- 	return -1;
-}
-static inline int xen_unregister_device_domain_owner(struct pci_dev *dev)
-{
- 	return -1;
-}
-static inline void xen_teardown_msi_dev(struct pci_dev *dev) { }
 #endif
 
 #if defined(CONFIG_PCI_MSI) && defined(CONFIG_XEN_DOM0_PCI)
 int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
-#else
-static inline int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
-{
-	return -1;
-}
 #endif
+
 #if defined(CONFIG_PCI_MSI)
 
 /* The drivers/pci/xen-pcifront.c sets this structure to
@@ -97,4 +73,32 @@ static inline int xen_create_msi_irq(struct pci_dev *dev,
 	return -1;
 }
 #endif
+
+#ifndef CONFIG_XEN_DOM0_PCI
+static inline int xen_register_gsi(u32 gsi, int triggering, int polarity)
+{
+	return -1;
+}
+static inline int xen_find_device_domain_owner(struct pci_dev *dev)
+{
+	return -1;
+}
+static inline int xen_register_device_domain_owner(struct pci_dev *dev,
+						   uint16_t domain)
+{
+ 	return -1;
+}
+static inline int xen_unregister_device_domain_owner(struct pci_dev *dev)
+{
+ 	return -1;
+}
+static inline void xen_teardown_msi_dev(struct pci_dev *dev) { }
+#endif
+
+#if (!defined(CONFIG_PCI_MSI) || !defined(CONFIG_XEN_DOM0_PCI))
+static inline int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+	return -1;
+}
+#endif
 #endif	/* _ASM_X86_XEN_PCI_H */
-- 
1.5.4.2

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Jeremy Fitzhardinge]

On 04/21/2010 09:05 PM, Yu Zhiguo wrote:
> Hi jeremy,
>
> Jeremy Fitzhardinge wrote:
>   
>>>  #endif
>>> +
>>> +#if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI))
>>>   
>>>       
>> As I mentioned in the other mail, there's no need to test CONFIG_XEN.
>>
>>     
> Indeed, thanks for your hint.
> Correct now, please refer to the following.
>   

Better, but:

> -
> +#if (!defined(CONFIG_PCI_MSI) || !defined(CONFIG_XEN_DOM0_PCI))
>   

Isn't there already a XEN MSI CONFIG variable?

    J

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Yu Zhiguo]

Hi, jeremy

Jeremy Fitzhardinge wrote:
>>   
> 
> Better, but:
> 
>> -
>> +#if (!defined(CONFIG_PCI_MSI) || !defined(CONFIG_XEN_DOM0_PCI))
>>   
> 
> Isn't there already a XEN MSI CONFIG variable?
> 

 I'm sorry I cannot understand what you mean.
 I looked up menuconfig, it seems than there is no relation between 
CONFIG_PCI_MSI and CONFIG_XEN_DOM0_PCI, I don't know to simplify this line.
 Please tell me what I missed.

-- 
Regards
Yu Zhiguo

Re: [PATCH] pv-ops: Fix missing 'ifdef CONFIG_XEN' in acpi

[Jeremy Fitzhardinge]

On 04/20/2010 08:29 PM, Yu Zhiguo wrote:
> We must use #if !defined(CONFIG_XEN) || (defined(CONFIG_XEN) && !defined(CONFIG_XEN_DOM0_PCI)).
>   

CONFIG_XEN_DOM0_PCI depends on CONFIG_XEN, so there's no need to test
that separately, right?  "#ifndef CONFIG_XEN_DOM0_PCI" is enough.

> method-4)
> If we perfer to fix it in header file, another method, we can use weak attribute of gcc.
>   

"weak" has its place, but I'm not sure its the right answer here.  The
main problem is that it is a link-time binding, so the generated code
still has the calls out to the functions.   With static inline
functions, the compiler will likely completely remove all the code.

    J

Failure to load the most recent kernel 2.6.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 157 bytes --]

Before child_rip word "acpi" shows pretty often. In particular "acpi_xen_processor"
Kernels been built about 2 weeks ago still loads fine.

Boris.




      

[-- Attachment #1.2: Type: text/html, Size: 294 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 1214 bytes --]

ASUS P5Q-E  2.6.31.13 under Xen 4.0 loads fine
ASUS P5Q-E  2.6.32.9 under   Xen 4.0 loads fine
ASUS P5Q-E  2.6.32.10 under Xen 4.0 doesn't load

ASUS P5Q3 all kernels work fine

I believe that the issue is connected with outdated ( ACPI 2 Enabled) BIOS
on first board. This question is mostly addressed to Yu Ke. What BIOS upgrade is required (exact version) ,  if ever possible.  

Boris.



--- On Mon, 4/19/10, Boris Derzhavets <bderzhavets@yahoo.com> wrote:

From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: [Xen-devel] Failure to load the most recent kernel 2.6.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Monday, April 19, 2010, 7:23 AM

Before child_rip word "acpi" shows pretty often. In particular "acpi_xen_processor"
Kernels been built about 2 weeks ago still loads fine.

Boris.










      
-----Inline Attachment Follows-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 2130 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 1993 bytes --]

I also noticed that ../acpi/processor_xen.c gets updated when 2.6.32.9 -> git pull -> 2.6.32.10 (xen/stable) . Just a guess.

Boris.

--- On Tue, 4/20/10, Boris Derzhavets <bderzhavets@yahoo.com> wrote:

From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tuesday, April 20, 2010, 6:44 AM

ASUS P5Q-E  2.6.31.13 under Xen 4.0 loads fine
ASUS P5Q-E  2.6.32.9 under   Xen 4.0 loads fine
ASUS P5Q-E  2.6.32.10 under Xen 4.0 doesn't load

ASUS P5Q3 all kernels work fine

I believe that the issue is connected with outdated ( ACPI 2 Enabled) BIOS
on first board. This question is mostly addressed to Yu Ke. What BIOS upgrade is required (exact version) ,  if ever possible.  

Boris.



--- On Mon, 4/19/10, Boris Derzhavets <bderzhavets@yahoo.com> wrote:

From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: [Xen-devel] Failure to load the most recent kernel 2.6.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
To: "Konrad Rzeszutek Wilk"
 <konrad.wilk@oracle.com>, "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Monday, April 19, 2010, 7:23 AM

Before child_rip word "acpi" shows pretty often. In particular "acpi_xen_processor"
Kernels been built about 2 weeks ago still loads fine.

Boris.










      
-----Inline Attachment Follows-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      
-----Inline Attachment Follows-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 3566 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

[Jeremy Fitzhardinge]

On 04/20/2010 03:44 AM, Boris Derzhavets wrote:
> ASUS P5Q-E  2.6.31.13 under Xen 4.0 loads fine
> ASUS P5Q-E  2.6.32.9 under   Xen 4.0 loads fine
> ASUS P5Q-E  2.6.32.10 under Xen 4.0 doesn't load
>
> ASUS P5Q3 all kernels work fine
>
> I believe that the issue is connected with outdated ( ACPI 2 Enabled) BIOS
> on first board. This question is mostly addressed to Yu Ke. What BIOS
> upgrade is required (exact version) ,  if ever possible. 
>

It would probably help him if you 1. address your mail to him, and 2.
provide more specific information about what the failure is, beyond
``Before child_rip word "acpi" shows pretty often. In particular
"acpi_xen_processor"''.

    J

Re: Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 2226 bytes --]

If it would not help, i will set up serial console ( a bit painful for me to move boxes )
Tail of sreen output on ASUS P5Q-E +C2D E8400 for 2.6.32.11 kernel :-

acpi_processor_set_pdc + 0x3c/0x3e
xen_acpi_processor_add + 0x2ef/0x426
acpi_device_probe + 0x4b/0x11d
driver_probe_device + 0x86/0x180
__diver_attach + 0x86/0x180 
__diver_attach + 0x86/0xa0
bus_for_each_dev 0x64/0x90
driver_attach + 0x71/0x140
bus_add_driver + 0x3e/0x140
driver_register + 0x71/0x140
?acpi_processor_init 0x3e/0x140
?acpi_processor_init 0x71/0x140
acpi_bus_register_driver +0x3e/0x12
xen_acpi_processor_init 0xae/0x128
acpi_processor_init  + 0x3e/0x12
? acpi_pci_slot_init 0x0/0x20
? acpi_pci_slot_init 0x0/0x20
do_one_init_call + 0x37/0x1xa0
kernel_init 0x148/0x196
child_rip + 0xa/0x20
? init_ret_from_sys_call 0x7/0x16
? retint_restore_args 0x5/0x5
? child_rip 0x0/0x20

Screen output stopped.

Thanks.
Boris.
P.S. Nothing similar happens on ASUS P5Q3 + Q9550
Dom0 loads smoothly. Tested on F12 and Ubuntu 9.10.
Same picture.

--- On Tue, 4/20/10, Jeremy Fitzhardinge <jeremy@goop.org> wrote:

From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Yu, Ke" <ke.yu@intel.com>
Date: Tuesday, April 20, 2010, 2:21 PM

On 04/20/2010 03:44 AM, Boris Derzhavets wrote:
> ASUS P5Q-E  2.6.31.13 under Xen 4.0 loads fine
> ASUS P5Q-E  2.6.32.9 under   Xen 4.0 loads fine
> ASUS P5Q-E  2.6.32.10 under Xen 4.0 doesn't load
>
> ASUS P5Q3 all kernels work fine
>
> I believe that the issue is connected with outdated ( ACPI 2 Enabled) BIOS
> on first board. This question is mostly addressed to Yu Ke. What BIOS
> upgrade is required (exact version) ,  if ever possible. 
>

It would probably help him if you 1. address your mail to him, and 2.
provide more specific information about what the failure is, beyond
``Before child_rip word "acpi" shows pretty often. In particular
"acpi_xen_processor"''.

    J



      

[-- Attachment #1.2: Type: text/html, Size: 2737 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

[Yu, Ke]

Yes, it would be helpful if you can provide more complete serial console log. From the below log, I can see acpi_processor_set_pdc-> acpi_evaluate_object(pr->handle, "_PDC", pdc_in, NULL) cause the system panic. However, it cannot tell why _PDC evaluation cause panic. It may be BIOS issue as you suggested, but we need more log to decide if this is true. And if true, ASUS should be the right place to get updated BIOS.

Also, how is the 2.6.32.11 kernel working in bare mental environment? acpi_processor_set_pdc is not xen specific code, so this issue is likely also occurring in bare mental environment.

And according to your test result, 2.6.32.9  works while 2.6.32.10 not. This remind me change we made recently made, i.e. "re-enable mwait for xen cpuidle", I am not sure if this cause the panic. So could you please try the grub kernel option "idle=nomwait"? This option will revert the effect of that patch. If "idle=nomwait" works, then we can dig more in this direction.

Best Regards
Ke

===============================
From: Boris Derzhavets [mailto:bderzhavets@yahoo.com] 
Sent: Wednesday, April 21, 2010 5:26 AM
To: Yu, Ke
Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com; Yu, Ke; Jeremy Fitzhardinge
Subject: Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

If it would not help, i will set up serial console ( a bit painful for me to move boxes )
Tail of sreen output on ASUS P5Q-E +C2D E8400 for 2.6.32.11 kernel :-

acpi_processor_set_pdc + 0x3c/0x3e
xen_acpi_processor_add + 0x2ef/0x426
acpi_device_probe + 0x4b/0x11d
driver_probe_device + 0x86/0x180
__diver_attach + 0x86/0x180 
__diver_attach + 0x86/0xa0
bus_for_each_dev 0x64/0x90
driver_attach + 0x71/0x140
bus_add_driver + 0x3e/0x140
driver_register + 0x71/0x140
?acpi_processor_init 0x3e/0x140
?acpi_processor_init 0x71/0x140
acpi_bus_register_driver +0x3e/0x12
xen_acpi_processor_init 0xae/0x128
acpi_processor_init  + 0x3e/0x12
? acpi_pci_slot_init 0x0/0x20
? acpi_pci_slot_init 0x0/0x20
do_one_init_call + 0x37/0x1xa0
kernel_init 0x148/0x196
child_rip + 0xa/0x20
? init_ret_from_sys_call 0x7/0x16
? retint_restore_args 0x5/0x5
? child_rip 0x0/0x20

Screen output stopped.

Thanks.
Boris.
P.S. Nothing similar happens on ASUS P5Q3 + Q9550
Dom0 loads smoothly. Tested on F12 and Ubuntu 9.10.
Same picture.

--- On Tue, 4/20/10, Jeremy Fitzhardinge <jeremy@goop.org> wrote:

From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Yu, Ke" <ke.yu@intel.com>
Date: Tuesday, April 20, 2010, 2:21 PM
On 04/20/2010 03:44 AM, Boris Derzhavets wrote:
> ASUS P5Q-E  2.6.31.13 under Xen 4.0 loads fine
> ASUS P5Q-E  2.6.32.9 under   Xen 4.0 loads fine
> ASUS P5Q-E  2.6.32.10 under Xen 4.0 doesn't load
>
> ASUS P5Q3 all kernels work fine
>
> I believe that the issue is connected with outdated ( ACPI 2 Enabled) BIOS
> on first board. This question is mostly addressed to Yu Ke. What BIOS
> upgrade is required (exact version) ,  if ever possible. 
>

It would probably help him if you 1. address your mail to him, and 2.
provide more specific information about what the failure is, beyond
``Before child_rip word "acpi" shows pretty often. In particular
"acpi_xen_processor"''.

    J

RE: Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 4642 bytes --]

This entry works:-

menuentry "Ubuntu, Linux 2.6.32.10" {
        insmod ext2
        set root=(hd1,1)
        linux   /boot/vmlinuz-2.6.32.10  root=/dev/sdb1 ro   quiet splash
        initrd  /boot/initrd-2.6.32.10.img
}

This one still doesn't :-

menuentry "Xen 4 / Ubuntu 9.10 kernel 2.6.32.10" {
insmod ext2
set root=(hd1,1)
multiboot (hd1,1)/boot/xen.gz
module (hd1,1)/boot/vmlinuz-2.6.32.10 dummy=dummy  idle=nomwait root=/dev/sdb1 ro console=tty0
module (hd1,1)/boot/initrd-2.6.32.10.img
}

Issues starts since :-
   acpi_processor_set_pdc + 0x3c/0x3e
again


Boris
--- On Wed, 4/21/10, Yu, Ke <ke.yu@intel.com> wrote:

From: Yu, Ke <ke.yu@intel.com>
Subject: RE: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Jeremy Fitzhardinge" <jeremy@goop.org>
Date: Wednesday, April 21, 2010, 4:05 AM

Yes, it would be helpful if you can provide more complete serial console log. From the below log, I can see acpi_processor_set_pdc-> acpi_evaluate_object(pr->handle, "_PDC", pdc_in, NULL) cause the system panic. However, it cannot tell why _PDC evaluation cause panic. It may be BIOS issue as you suggested, but we need more log to decide if this is true. And if true, ASUS should be the right place to get updated BIOS.

Also, how is the 2.6.32.11 kernel working in bare mental environment? acpi_processor_set_pdc is not xen specific code, so this issue is likely also occurring in bare mental environment.

And according to your test result, 2.6.32.9  works while 2.6.32.10 not. This remind me change we made recently made, i.e. "re-enable mwait for xen cpuidle", I am not sure if this cause the panic. So could you please try the grub kernel option "idle=nomwait"? This option will revert the effect of that patch. If "idle=nomwait" works, then we can dig more in this direction.

Best Regards
Ke

===============================
From: Boris Derzhavets [mailto:bderzhavets@yahoo.com] 
Sent: Wednesday, April 21, 2010 5:26 AM
To: Yu, Ke
Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com; Yu, Ke; Jeremy Fitzhardinge
Subject: Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10

If it would not help, i will set up serial console ( a bit painful for me to move boxes )
Tail of sreen output on ASUS P5Q-E +C2D E8400 for 2.6.32.11 kernel :-

acpi_processor_set_pdc + 0x3c/0x3e
xen_acpi_processor_add + 0x2ef/0x426
acpi_device_probe + 0x4b/0x11d
driver_probe_device + 0x86/0x180
__diver_attach + 0x86/0x180 
__diver_attach + 0x86/0xa0
bus_for_each_dev 0x64/0x90
driver_attach + 0x71/0x140
bus_add_driver + 0x3e/0x140
driver_register + 0x71/0x140
?acpi_processor_init 0x3e/0x140
?acpi_processor_init 0x71/0x140
acpi_bus_register_driver +0x3e/0x12
xen_acpi_processor_init 0xae/0x128
acpi_processor_init  + 0x3e/0x12
? acpi_pci_slot_init 0x0/0x20
? acpi_pci_slot_init 0x0/0x20
do_one_init_call + 0x37/0x1xa0
kernel_init 0x148/0x196
child_rip + 0xa/0x20
? init_ret_from_sys_call 0x7/0x16
? retint_restore_args 0x5/0x5
? child_rip 0x0/0x20

Screen output stopped.

Thanks.
Boris.
P.S. Nothing similar happens on ASUS P5Q3 + Q9550
Dom0 loads smoothly. Tested on F12 and Ubuntu 9.10.
Same picture.

--- On Tue, 4/20/10, Jeremy Fitzhardinge <jeremy@goop.org> wrote:

From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] Failure to load the most recent kernel 2.6.32.10 ( xen/stable) under Xen 4.0 on Ubuntu 9.10
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Yu, Ke" <ke.yu@intel.com>
Date: Tuesday, April 20, 2010, 2:21 PM
On 04/20/2010 03:44 AM, Boris Derzhavets wrote:
> ASUS P5Q-E  2.6.31.13 under Xen 4.0 loads fine
> ASUS P5Q-E  2.6.32.9 under   Xen 4.0 loads fine
> ASUS P5Q-E  2.6.32.10 under Xen 4.0 doesn't load
>
> ASUS P5Q3 all kernels work fine
>
> I believe that the issue is connected with outdated ( ACPI 2 Enabled) BIOS
> on first board. This question is mostly addressed to Yu Ke. What BIOS
> upgrade is required (exact version) ,  if ever possible. 
>

It would probably help him if you 1. address your mail to him, and 2.
provide more specific information about what the failure is, beyond
``Before child_rip word "acpi" shows pretty often. In particular
"acpi_xen_processor"''.

    J




      

[-- Attachment #1.2: Type: text/html, Size: 6315 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel