diff mbox

[v6,22/22] xen/arm64: Add ACPI support

Message ID 1458207668-12012-23-git-send-email-zhaoshenglong@huawei.com (mailing list archive)
State New, archived
Headers show

Commit Message

Shannon Zhao March 17, 2016, 9:41 a.m. UTC 
From: Naresh Bhat <naresh.bhat@linaro.org>

Add ACPI support on arm64 xen hypervisor. Enable EFI support on ARM.

Cc: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
v6: make CONFIG_ACPI depends on EXPERT
---
 xen/arch/arm/Kconfig         |  9 +++++++++
 xen/common/efi/runtime.c     | 12 +++++++-----
 xen/include/asm-arm/config.h |  4 ++++
 3 files changed, 20 insertions(+), 5 deletions(-)

Comments

Jan Beulich March 17, 2016, 10:52 a.m. UTC | #1 
>>> On 17.03.16 at 10:41, <zhaoshenglong@huawei.com> wrote:
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -31,6 +31,10 @@
>  
>  #define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
>  
> +#ifdef CONFIG_ACPI
> +#define CONFIG_ACPI_BOOT 1
> +#endif

Do we think that ACPI without ACPI_BOOT is useful for anything?
If not, I think we should just get rid of the latter in common code
(x86 could be cleaned up separately), and hence ARM wouldn't
have a need for this ugliness. If however we do, then this should
be switched to Kconfig (at once on x86 then).

Jan
Shannon Zhao March 17, 2016, 11:03 a.m. UTC | #2 
On 2016/3/17 18:52, Jan Beulich wrote:
>>>> On 17.03.16 at 10:41, <zhaoshenglong@huawei.com> wrote:
>> > --- a/xen/include/asm-arm/config.h
>> > +++ b/xen/include/asm-arm/config.h
>> > @@ -31,6 +31,10 @@
>> >  
>> >  #define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
>> >  
>> > +#ifdef CONFIG_ACPI
>> > +#define CONFIG_ACPI_BOOT 1
>> > +#endif
> Do we think that ACPI without ACPI_BOOT is useful for anything?
> If not, I think we should just get rid of the latter in common code
> (x86 could be cleaned up separately), and hence ARM wouldn't
> have a need for this ugliness. If however we do, then this should
> be switched to Kconfig (at once on x86 then).
I think we could replace CONFIG_ACPI_BOOT with CONFIG_ACPI. Maybe we
could clean up them on top this of patch.

Thanks,
Jan Beulich March 17, 2016, 11:31 a.m. UTC | #3 
>>> On 17.03.16 at 12:03, <zhaoshenglong@huawei.com> wrote:
> On 2016/3/17 18:52, Jan Beulich wrote:
>>>>> On 17.03.16 at 10:41, <zhaoshenglong@huawei.com> wrote:
>>> > --- a/xen/include/asm-arm/config.h
>>> > +++ b/xen/include/asm-arm/config.h
>>> > @@ -31,6 +31,10 @@
>>> >  
>>> >  #define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
>>> >  
>>> > +#ifdef CONFIG_ACPI
>>> > +#define CONFIG_ACPI_BOOT 1
>>> > +#endif
>> Do we think that ACPI without ACPI_BOOT is useful for anything?
>> If not, I think we should just get rid of the latter in common code
>> (x86 could be cleaned up separately), and hence ARM wouldn't
>> have a need for this ugliness. If however we do, then this should
>> be switched to Kconfig (at once on x86 then).
> I think we could replace CONFIG_ACPI_BOOT with CONFIG_ACPI. Maybe we
> could clean up them on top this of patch.

Cleaning up the sole common code use should be done as a prereq,
or even inside this patch. Doing such cleanup on top is a bad idea:
We should aim at not introducing any further CONFIG_* #define-s
in headers, now that we have the Kconfig machinery in place.

Jan
Shannon Zhao March 17, 2016, 1:10 p.m. UTC | #4 
On 2016/3/17 19:31, Jan Beulich wrote:
>>>> On 17.03.16 at 12:03, <zhaoshenglong@huawei.com> wrote:
>> > On 2016/3/17 18:52, Jan Beulich wrote:
>>>>>> >>>>> On 17.03.16 at 10:41, <zhaoshenglong@huawei.com> wrote:
>>>>> >>> > --- a/xen/include/asm-arm/config.h
>>>>> >>> > +++ b/xen/include/asm-arm/config.h
>>>>> >>> > @@ -31,6 +31,10 @@
>>>>> >>> >  
>>>>> >>> >  #define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
>>>>> >>> >  
>>>>> >>> > +#ifdef CONFIG_ACPI
>>>>> >>> > +#define CONFIG_ACPI_BOOT 1
>>>>> >>> > +#endif
>>> >> Do we think that ACPI without ACPI_BOOT is useful for anything?
>>> >> If not, I think we should just get rid of the latter in common code
>>> >> (x86 could be cleaned up separately), and hence ARM wouldn't
>>> >> have a need for this ugliness. If however we do, then this should
>>> >> be switched to Kconfig (at once on x86 then).
>> > I think we could replace CONFIG_ACPI_BOOT with CONFIG_ACPI. Maybe we
>> > could clean up them on top this of patch.
> Cleaning up the sole common code use should be done as a prereq,
> or even inside this patch. Doing such cleanup on top is a bad idea:
> We should aim at not introducing any further CONFIG_* #define-s
> in headers, now that we have the Kconfig machinery in place.
Ok, so it's fine to you that replace CONFIG_ACPI_BOOT with CONFIG_ACPI
in common and x86 codes, right? If so, I'll add a patch to that before
thia patch.

Thanks,
Jan Beulich March 17, 2016, 1:24 p.m. UTC | #5 
>>> On 17.03.16 at 14:10, <zhaoshenglong@huawei.com> wrote:

> 
> On 2016/3/17 19:31, Jan Beulich wrote:
>>>>> On 17.03.16 at 12:03, <zhaoshenglong@huawei.com> wrote:
>>> > On 2016/3/17 18:52, Jan Beulich wrote:
>>>>>>> >>>>> On 17.03.16 at 10:41, <zhaoshenglong@huawei.com> wrote:
>>>>>> >>> > --- a/xen/include/asm-arm/config.h
>>>>>> >>> > +++ b/xen/include/asm-arm/config.h
>>>>>> >>> > @@ -31,6 +31,10 @@
>>>>>> >>> >  
>>>>>> >>> >  #define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
>>>>>> >>> >  
>>>>>> >>> > +#ifdef CONFIG_ACPI
>>>>>> >>> > +#define CONFIG_ACPI_BOOT 1
>>>>>> >>> > +#endif
>>>> >> Do we think that ACPI without ACPI_BOOT is useful for anything?
>>>> >> If not, I think we should just get rid of the latter in common code
>>>> >> (x86 could be cleaned up separately), and hence ARM wouldn't
>>>> >> have a need for this ugliness. If however we do, then this should
>>>> >> be switched to Kconfig (at once on x86 then).
>>> > I think we could replace CONFIG_ACPI_BOOT with CONFIG_ACPI. Maybe we
>>> > could clean up them on top this of patch.
>> Cleaning up the sole common code use should be done as a prereq,
>> or even inside this patch. Doing such cleanup on top is a bad idea:
>> We should aim at not introducing any further CONFIG_* #define-s
>> in headers, now that we have the Kconfig machinery in place.
> Ok, so it's fine to you that replace CONFIG_ACPI_BOOT with CONFIG_ACPI
> in common and x86 codes, right? If so, I'll add a patch to that before
> thia patch.

Yes - I certainly welcome if you want to clean up x86 at once.

Jan
diff mbox

Patch

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index cb99df5..6231cd5 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -33,6 +33,15 @@  menu "Architecture Features"
 
 source "arch/Kconfig"
 
+config ACPI
+	bool
+	prompt "ACPI (Advanced Configuration and Power Interface) Support" if EXPERT = "y"
+	depends on ARM_64
+	---help---
+
+	  Advanced Configuration and Power Interface (ACPI) support for Xen is
+	  an alternative to device tree on ARM64.
+
 # Select HAS_GICV3 if GICv3 is supported
 config HAS_GICV3
 	bool
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index ae87557..c256814 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -10,14 +10,16 @@  DEFINE_XEN_GUEST_HANDLE(CHAR16);
 
 #ifndef COMPAT
 
-#ifdef CONFIG_ARM  /* Disabled until runtime services implemented */
-const bool_t efi_enabled = 0;
-#else
+/*
+ * Currently runtime services are not implemented on ARM. To boot Xen with ACPI,
+ * set efi_enabled to 1, so that Xen can get the ACPI root pointer from EFI.
+ */
+const bool_t efi_enabled = 1;
+
+#ifndef CONFIG_ARM
 # include <asm/i387.h>
 # include <asm/xstate.h>
 # include <public/platform.h>
-
-const bool_t efi_enabled = 1;
 #endif
 
 unsigned int __read_mostly efi_num_ct;
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 7ceb5c5..5fc9aa2 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -31,6 +31,10 @@ 
 
 #define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
 
+#ifdef CONFIG_ACPI
+#define CONFIG_ACPI_BOOT 1
+#endif
+
 #define CONFIG_SMP 1
 
 #define CONFIG_IRQ_HAS_MULTIPLE_ACTION 1