* [PATCH RFC 01/35] xen: acpi: Build numa and pmstate x86 only
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-04 17:03 ` Julien Grall
2015-02-04 14:01 ` [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers parth.dixit
` (34 subsequent siblings)
35 siblings, 1 reply; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
Configure and build numa, pmstate for x86 architecture only.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/drivers/acpi/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index bbb06a7..009fe5a 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -3,9 +3,9 @@ subdir-y += utilities
subdir-$(x86) += apei
obj-bin-y += tables.init.o
-obj-y += numa.o
+obj-$(x86) += numa.o
obj-y += osl.o
-obj-y += pmstat.o
+obj-$(x86) += pmstat.o
obj-$(x86) += hwregs.o
obj-$(x86) += reboot.o
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 01/35] xen: acpi: Build numa and pmstate x86 only
2015-02-04 14:01 ` [PATCH RFC 01/35] xen: acpi: Build numa and pmstate x86 only parth.dixit
@ 2015-02-04 17:03 ` Julien Grall
0 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-04 17:03 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, stefano.stabellini, jbeulich,
christoffer.dall
Hi Parth,
On 04/02/2015 14:01, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Configure and build numa, pmstate for x86 architecture only.
Can you explain why you need to disable them?
I.e this code is contains some x86 dependencies and both feature are not
supported on ARM right now.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
2015-02-04 14:01 ` [PATCH RFC 01/35] xen: acpi: Build numa and pmstate x86 only parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-04 17:34 ` Stefano Stabellini
2015-02-04 17:36 ` Julien Grall
2015-02-04 14:01 ` [PATCH RFC 03/35] xen: arm64: ACPI: Add basic ACPI initialization parth.dixit
` (33 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
xen hypervisor will use ACPI for initialisation in the same manner that
current x86/x86_64 ones do. Add the calls to initialise the ACPI tables
and load devices using the xen/drivers/acpi subsytem.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/common/sysctl.c | 2 +
xen/drivers/acpi/osl.c | 6 ++
xen/drivers/acpi/utilities/utglobal.c | 1 +
xen/include/asm-arm/acpi.h | 106 ++++++++++++++++++++++++++++++++++
xen/include/asm-arm/arm64/page.h | 2 +
5 files changed, 117 insertions(+)
create mode 100644 xen/include/asm-arm/acpi.h
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 0cb6ee1..a700a16 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -170,6 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
op->u.availheap.avail_bytes <<= PAGE_SHIFT;
break;
+#ifdef CONFIG_X86
#ifdef HAS_ACPI
case XEN_SYSCTL_get_pmstat:
ret = do_get_pm_info(&op->u.get_pmstat);
@@ -181,6 +182,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
copyback = 1;
break;
#endif
+#endif
case XEN_SYSCTL_page_offline_op:
{
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index 93c983c..73da9d9 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -96,7 +96,11 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
return __va(phys);
return __vmap(&pfn, PFN_UP(offs + size), 1, 1, PAGE_HYPERVISOR_NOCACHE) + offs;
}
+#ifdef CONFIG_X86
return __acpi_map_table(phys, size);
+#else
+ return __va(phys);
+#endif
}
void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
@@ -105,6 +109,7 @@ void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
vunmap((void *)((unsigned long)virt & PAGE_MASK));
}
+#ifdef CONFIG_X86
acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width)
{
u32 dummy;
@@ -140,6 +145,7 @@ acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width)
return AE_OK;
}
+#endif
acpi_status
acpi_os_read_memory(acpi_physical_address phys_addr, u32 * value, u32 width)
diff --git a/xen/drivers/acpi/utilities/utglobal.c b/xen/drivers/acpi/utilities/utglobal.c
index 7dbc964..65c918e 100644
--- a/xen/drivers/acpi/utilities/utglobal.c
+++ b/xen/drivers/acpi/utilities/utglobal.c
@@ -43,6 +43,7 @@
#define DEFINE_ACPI_GLOBALS
+#include <asm/system.h>
#include <xen/config.h>
#include <xen/init.h>
#include <xen/lib.h>
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
new file mode 100644
index 0000000..f6284b5
--- /dev/null
+++ b/xen/include/asm-arm/acpi.h
@@ -0,0 +1,106 @@
+/*
+ * Copyright (C) 2014, Naresh Bhat <naresh.bhat@linaro.org>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#ifndef _ASM_ARM64_ACPI_H
+#define _ASM_ARM64_ACPI_H
+
+#include <xen/init.h>
+
+#define COMPILER_DEPENDENT_INT64 long long
+#define COMPILER_DEPENDENT_UINT64 unsigned long long
+
+#define MAX_LOCAL_APIC 256
+#define MAX_IO_APICS 64
+
+/*
+ * Calling conventions:
+ *
+ * ACPI_SYSTEM_XFACE - Interfaces to host OS (handlers, threads)
+ * ACPI_EXTERNAL_XFACE - External ACPI interfaces
+ * ACPI_INTERNAL_XFACE - Internal ACPI interfaces
+ * ACPI_INTERNAL_VAR_XFACE - Internal variable-parameter list interfaces
+ */
+#define ACPI_SYSTEM_XFACE
+#define ACPI_EXTERNAL_XFACE
+#define ACPI_INTERNAL_XFACE
+#define ACPI_INTERNAL_VAR_XFACE
+
+/* Asm macros */
+#define ACPI_ASM_MACROS
+#define BREAKPOINT3
+#define ACPI_DISABLE_IRQS() local_irq_disable()
+#define ACPI_ENABLE_IRQS() local_irq_enable()
+#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()
+
+/* Blob handling macros */
+#define ACPI_BLOB_HEADER_SIZE 8
+
+/* Basic configuration for ACPI */
+#ifdef CONFIG_ACPI
+extern int acpi_disabled;
+extern int acpi_noirq;
+extern int acpi_pci_disabled;
+extern int acpi_strict;
+
+/* map logic cpu id to physical APIC id
+ * APIC = GIC cpu interface on ARM
+ */
+extern volatile int arm_cpu_to_apicid[NR_CPUS];
+extern int boot_cpu_apic_id;
+#define cpu_physical_id(cpu) arm_cpu_to_apicid[cpu]
+
+struct acpi_arm_root {
+ paddr_t phys_address;
+ unsigned long size;
+};
+extern struct acpi_arm_root acpi_arm_rsdp_info;
+
+void arm_acpi_reserve_memory(void);
+
+/* Low-level suspend routine. */
+extern int (*acpi_suspend_lowlevel)(void);
+
+extern void prefill_possible_map(void);
+
+#define acpi_wakeup_address (0)
+
+static inline void disable_acpi(void)
+{
+ acpi_disabled = 1;
+ acpi_pci_disabled = 1;
+ acpi_noirq = 1;
+}
+static inline void acpi_noirq_set(void) { acpi_noirq = 1; }
+static inline void acpi_disable_pci(void)
+{
+ acpi_pci_disabled = 1;
+ acpi_noirq_set();
+}
+
+#else /* !CONFIG_ACPI */
+#define acpi_disabled 1 /* ACPI sometimes enabled on ARM */
+#define acpi_noirq 1 /* ACPI sometimes enabled on ARM */
+#define acpi_pci_disabled 1 /* ACPI PCI sometimes enabled on ARM */
+#define acpi_strict 1 /* no ACPI spec workarounds on ARM */
+#endif
+
+#endif /*_ASM_ARM_ACPI_H*/
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 1fd416d..13b0ea1 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -1,6 +1,8 @@
#ifndef __ARM_ARM64_PAGE_H__
#define __ARM_ARM64_PAGE_H__
+#include <asm-arm/system.h>
+
#ifndef __ASSEMBLY__
/* Write a pagetable entry */
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers
2015-02-04 14:01 ` [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers parth.dixit
@ 2015-02-04 17:34 ` Stefano Stabellini
2015-02-04 17:36 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-04 17:34 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> xen hypervisor will use ACPI for initialisation in the same manner that
> current x86/x86_64 ones do. Add the calls to initialise the ACPI tables
> and load devices using the xen/drivers/acpi subsytem.
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/common/sysctl.c | 2 +
> xen/drivers/acpi/osl.c | 6 ++
> xen/drivers/acpi/utilities/utglobal.c | 1 +
> xen/include/asm-arm/acpi.h | 106 ++++++++++++++++++++++++++++++++++
> xen/include/asm-arm/arm64/page.h | 2 +
> 5 files changed, 117 insertions(+)
> create mode 100644 xen/include/asm-arm/acpi.h
>
> diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
> index 0cb6ee1..a700a16 100644
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -170,6 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
> op->u.availheap.avail_bytes <<= PAGE_SHIFT;
> break;
>
> +#ifdef CONFIG_X86
Could you please explain in the commit message why you are ifdef'ing
the following?
> #ifdef HAS_ACPI
> case XEN_SYSCTL_get_pmstat:
> ret = do_get_pm_info(&op->u.get_pmstat);
> @@ -181,6 +182,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
> copyback = 1;
> break;
> #endif
> +#endif
>
> case XEN_SYSCTL_page_offline_op:
> {
> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
> index 93c983c..73da9d9 100644
> --- a/xen/drivers/acpi/osl.c
> +++ b/xen/drivers/acpi/osl.c
> @@ -96,7 +96,11 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
> return __va(phys);
> return __vmap(&pfn, PFN_UP(offs + size), 1, 1, PAGE_HYPERVISOR_NOCACHE) + offs;
> }
> +#ifdef CONFIG_X86
> return __acpi_map_table(phys, size);
same here: please explain
> +#else
> + return __va(phys);
> +#endif
> }
>
> void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
> @@ -105,6 +109,7 @@ void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
> vunmap((void *)((unsigned long)virt & PAGE_MASK));
> }
>
> +#ifdef CONFIG_X86
same here: please explain
> acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width)
> {
> u32 dummy;
> @@ -140,6 +145,7 @@ acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width)
>
> return AE_OK;
> }
> +#endif
>
> acpi_status
> acpi_os_read_memory(acpi_physical_address phys_addr, u32 * value, u32 width)
> diff --git a/xen/drivers/acpi/utilities/utglobal.c b/xen/drivers/acpi/utilities/utglobal.c
> index 7dbc964..65c918e 100644
> --- a/xen/drivers/acpi/utilities/utglobal.c
> +++ b/xen/drivers/acpi/utilities/utglobal.c
> @@ -43,6 +43,7 @@
>
> #define DEFINE_ACPI_GLOBALS
>
> +#include <asm/system.h>
> #include <xen/config.h>
> #include <xen/init.h>
> #include <xen/lib.h>
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> new file mode 100644
> index 0000000..f6284b5
> --- /dev/null
> +++ b/xen/include/asm-arm/acpi.h
The addition of this new file should be moved to the next patch.
> @@ -0,0 +1,106 @@
> +/*
> + * Copyright (C) 2014, Naresh Bhat <naresh.bhat@linaro.org>
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + */
> +
> +#ifndef _ASM_ARM64_ACPI_H
> +#define _ASM_ARM64_ACPI_H
> +
> +#include <xen/init.h>
> +
> +#define COMPILER_DEPENDENT_INT64 long long
> +#define COMPILER_DEPENDENT_UINT64 unsigned long long
> +
> +#define MAX_LOCAL_APIC 256
> +#define MAX_IO_APICS 64
> +
> +/*
> + * Calling conventions:
> + *
> + * ACPI_SYSTEM_XFACE - Interfaces to host OS (handlers, threads)
> + * ACPI_EXTERNAL_XFACE - External ACPI interfaces
> + * ACPI_INTERNAL_XFACE - Internal ACPI interfaces
> + * ACPI_INTERNAL_VAR_XFACE - Internal variable-parameter list interfaces
> + */
> +#define ACPI_SYSTEM_XFACE
> +#define ACPI_EXTERNAL_XFACE
> +#define ACPI_INTERNAL_XFACE
> +#define ACPI_INTERNAL_VAR_XFACE
> +
> +/* Asm macros */
> +#define ACPI_ASM_MACROS
> +#define BREAKPOINT3
> +#define ACPI_DISABLE_IRQS() local_irq_disable()
> +#define ACPI_ENABLE_IRQS() local_irq_enable()
> +#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()
> +
> +/* Blob handling macros */
> +#define ACPI_BLOB_HEADER_SIZE 8
> +
> +/* Basic configuration for ACPI */
> +#ifdef CONFIG_ACPI
> +extern int acpi_disabled;
> +extern int acpi_noirq;
> +extern int acpi_pci_disabled;
> +extern int acpi_strict;
> +
> +/* map logic cpu id to physical APIC id
> + * APIC = GIC cpu interface on ARM
> + */
> +extern volatile int arm_cpu_to_apicid[NR_CPUS];
> +extern int boot_cpu_apic_id;
> +#define cpu_physical_id(cpu) arm_cpu_to_apicid[cpu]
> +
> +struct acpi_arm_root {
> + paddr_t phys_address;
> + unsigned long size;
> +};
> +extern struct acpi_arm_root acpi_arm_rsdp_info;
> +
> +void arm_acpi_reserve_memory(void);
> +
> +/* Low-level suspend routine. */
> +extern int (*acpi_suspend_lowlevel)(void);
> +
> +extern void prefill_possible_map(void);
> +
> +#define acpi_wakeup_address (0)
> +
> +static inline void disable_acpi(void)
> +{
> + acpi_disabled = 1;
> + acpi_pci_disabled = 1;
> + acpi_noirq = 1;
> +}
> +static inline void acpi_noirq_set(void) { acpi_noirq = 1; }
> +static inline void acpi_disable_pci(void)
> +{
> + acpi_pci_disabled = 1;
> + acpi_noirq_set();
> +}
> +
> +#else /* !CONFIG_ACPI */
> +#define acpi_disabled 1 /* ACPI sometimes enabled on ARM */
> +#define acpi_noirq 1 /* ACPI sometimes enabled on ARM */
> +#define acpi_pci_disabled 1 /* ACPI PCI sometimes enabled on ARM */
> +#define acpi_strict 1 /* no ACPI spec workarounds on ARM */
Please explain the meaning of these options on more details.
> +#endif
> +
> +#endif /*_ASM_ARM_ACPI_H*/
> diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
> index 1fd416d..13b0ea1 100644
> --- a/xen/include/asm-arm/arm64/page.h
> +++ b/xen/include/asm-arm/arm64/page.h
> @@ -1,6 +1,8 @@
> #ifndef __ARM_ARM64_PAGE_H__
> #define __ARM_ARM64_PAGE_H__
>
> +#include <asm-arm/system.h>
Why?
> #ifndef __ASSEMBLY__
>
> /* Write a pagetable entry */
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers
2015-02-04 14:01 ` [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers parth.dixit
2015-02-04 17:34 ` Stefano Stabellini
@ 2015-02-04 17:36 ` Julien Grall
2015-02-05 11:04 ` Ian Campbell
2015-02-05 11:34 ` Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-04 17:36 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, stefano.stabellini, jbeulich,
christoffer.dall
Hi Parth,
On 04/02/2015 14:01, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> xen hypervisor will use ACPI for initialisation in the same manner that
> current x86/x86_64 ones do. Add the calls to initialise the ACPI tables
> and load devices using the xen/drivers/acpi subsytem.
All changes in this patch are mostly unrelated, and most of them
requires an explanation why we need to it.
I would split this patch in small chunk.
See below for others comment.
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/common/sysctl.c | 2 +
> xen/drivers/acpi/osl.c | 6 ++
> xen/drivers/acpi/utilities/utglobal.c | 1 +
> xen/include/asm-arm/acpi.h | 106 ++++++++++++++++++++++++++++++++++
> xen/include/asm-arm/arm64/page.h | 2 +
> 5 files changed, 117 insertions(+)
> create mode 100644 xen/include/asm-arm/acpi.h
>
> diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
> index 0cb6ee1..a700a16 100644
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -170,6 +170,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
> op->u.availheap.avail_bytes <<= PAGE_SHIFT;
> break;
>
> +#ifdef CONFIG_X86
> #ifdef HAS_ACPI
#if defined(CONFIG_X86) && defined(HAS_ACPI) ?
Also, this change seems to be related to the patch #1.
I would make sense to create a separate patch which will disable the
compilation of pmstate and adding this #ifdef.
> case XEN_SYSCTL_get_pmstat:
> ret = do_get_pm_info(&op->u.get_pmstat);
> @@ -181,6 +182,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
> copyback = 1;
> break;
> #endif
> +#endif
>
> case XEN_SYSCTL_page_offline_op:
> {
> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
> index 93c983c..73da9d9 100644
> --- a/xen/drivers/acpi/osl.c
> +++ b/xen/drivers/acpi/osl.c
> @@ -96,7 +96,11 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
> return __va(phys);
> return __vmap(&pfn, PFN_UP(offs + size), 1, 1, PAGE_HYPERVISOR_NOCACHE) + offs;
> }
> +#ifdef CONFIG_X86
> return __acpi_map_table(phys, size);
> +#else
> + return __va(phys);
I remembered to have a discussion about this change with Naresh few
month ago.
__va should only be used when the memory is direct-mapped to Xen (i.e
accessible directly). On ARM64, this only the case for the RAM. Can you
confirm that ACPI will always reside to the RAM?
Futhermore, the code of this function seems x86-specific. The low 1MB
may not be mapped on ARM64.
I would move the whole function (acpi_os_map_memory) per-architecture.
> +#endif
> }
> void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
> @@ -105,6 +109,7 @@ void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
> vunmap((void *)((unsigned long)virt & PAGE_MASK));
> }
>
> +#ifdef CONFIG_X86
> acpi_status acpi_os_read_port(acpi_io_address port, u32 * value, u32 width)
> {
> u32 dummy;
> @@ -140,6 +145,7 @@ acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width)
>
> return AE_OK;
> }
> +#endif
Why only x86? Linux seems to define it also for ARM64.
> acpi_status
> acpi_os_read_memory(acpi_physical_address phys_addr, u32 * value, u32 width)
> diff --git a/xen/drivers/acpi/utilities/utglobal.c b/xen/drivers/acpi/utilities/utglobal.c
> index 7dbc964..65c918e 100644
> --- a/xen/drivers/acpi/utilities/utglobal.c
> +++ b/xen/drivers/acpi/utilities/utglobal.c
> @@ -43,6 +43,7 @@
>
> #define DEFINE_ACPI_GLOBALS
>
> +#include <asm/system.h>
Why it's necessary?
> #include <xen/config.h>
> #include <xen/init.h>
> #include <xen/lib.h>
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> new file mode 100644
> index 0000000..f6284b5
> --- /dev/null
> +++ b/xen/include/asm-arm/acpi.h
> @@ -0,0 +1,106 @@
> +/*
> + * Copyright (C) 2014, Naresh Bhat <naresh.bhat@linaro.org>
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + */
> +
> +#ifndef _ASM_ARM64_ACPI_H
> +#define _ASM_ARM64_ACPI_H
> +
> +#include <xen/init.h>
> +
> +#define COMPILER_DEPENDENT_INT64 long long
> +#define COMPILER_DEPENDENT_UINT64 unsigned long long
> +
> +#define MAX_LOCAL_APIC 256
> +#define MAX_IO_APICS 64
> +
> +/*
> + * Calling conventions:
> + *
> + * ACPI_SYSTEM_XFACE - Interfaces to host OS (handlers, threads)
> + * ACPI_EXTERNAL_XFACE - External ACPI interfaces
> + * ACPI_INTERNAL_XFACE - Internal ACPI interfaces
> + * ACPI_INTERNAL_VAR_XFACE - Internal variable-parameter list interfaces
> + */
> +#define ACPI_SYSTEM_XFACE
> +#define ACPI_EXTERNAL_XFACE
> +#define ACPI_INTERNAL_XFACE
> +#define ACPI_INTERNAL_VAR_XFACE
> +
> +/* Asm macros */
> +#define ACPI_ASM_MACROS
> +#define BREAKPOINT3
It's never used on common code.
> +#define ACPI_DISABLE_IRQS() local_irq_disable()
> +#define ACPI_ENABLE_IRQS() local_irq_enable()
> +#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()
> +
> +/* Blob handling macros */
> +#define ACPI_BLOB_HEADER_SIZE 8
> +
> +/* Basic configuration for ACPI */
> +#ifdef CONFIG_ACPI
> +extern int acpi_disabled;
> +extern int acpi_noirq;
> +extern int acpi_pci_disabled;
> +extern int acpi_strict;
I think it would be better to define common external variable in a
common headers. Although I'm an ACPI maintainers...
> +/* map logic cpu id to physical APIC id
> + * APIC = GIC cpu interface on ARM
> + */
> +extern volatile int arm_cpu_to_apicid[NR_CPUS];
> +extern int boot_cpu_apic_id;
> +#define cpu_physical_id(cpu) arm_cpu_to_apicid[cpu]
> +
> +struct acpi_arm_root {
> + paddr_t phys_address;
> + unsigned long size;
> +};
Can you document this structure?
> +extern struct acpi_arm_root acpi_arm_rsdp_info;
This external variable is defined but seem to never be used in the whole
series.
> +void arm_acpi_reserve_memory(void);
> +
> +/* Low-level suspend routine. */
> +extern int (*acpi_suspend_lowlevel)(void);
> +
> +extern void prefill_possible_map(void);
Those 3 functions are never implemented neither used.
> +#define acpi_wakeup_address (0)
This macro is never used.
> +static inline void disable_acpi(void)
> +{
> + acpi_disabled = 1;
> + acpi_pci_disabled = 1;
> + acpi_noirq = 1;
> +}
> +static inline void acpi_noirq_set(void) { acpi_noirq = 1; }
> +static inline void acpi_disable_pci(void)
> +{
> + acpi_pci_disabled = 1;
> + acpi_noirq_set();
> +}
Ditto for acpi_noirq_set and acpi_disable_pci
> +#else /* !CONFIG_ACPI */
> +#define acpi_disabled 1 /* ACPI sometimes enabled on ARM */
> +#define acpi_noirq 1 /* ACPI sometimes enabled on ARM */
> +#define acpi_pci_disabled 1 /* ACPI PCI sometimes enabled on ARM */
> +#define acpi_strict 1 /* no ACPI spec workarounds on ARM */
The comments are unclear to me here.
> +#endif
> +
> +#endif /*_ASM_ARM_ACPI_H*/
> diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
> index 1fd416d..13b0ea1 100644
> --- a/xen/include/asm-arm/arm64/page.h
> +++ b/xen/include/asm-arm/arm64/page.h
> @@ -1,6 +1,8 @@
> #ifndef __ARM_ARM64_PAGE_H__
> #define __ARM_ARM64_PAGE_H__
>
> +#include <asm-arm/system.h>
> +
Why?
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers
2015-02-04 17:36 ` Julien Grall
@ 2015-02-05 11:04 ` Ian Campbell
2015-02-05 11:35 ` Jan Beulich
2015-02-05 14:05 ` Julien Grall
2015-02-05 11:34 ` Jan Beulich
1 sibling, 2 replies; 166+ messages in thread
From: Ian Campbell @ 2015-02-05 11:04 UTC (permalink / raw)
To: Julien Grall
Cc: Naresh Bhat, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
On Wed, 2015-02-04 at 17:36 +0000, Julien Grall wrote:
> I remembered to have a discussion about this change with Naresh few
> month ago.
>
> __va should only be used when the memory is direct-mapped to Xen (i.e
> accessible directly). On ARM64, this only the case for the RAM. Can you
> confirm that ACPI will always reside to the RAM?
Even if the answer is yes then rather than adding loads of ifdefs it
seems like the right thing would be to implement __acpi_map_table on
ARM, even if the implementation ends up being only return __va(phys).
> Futhermore, the code of this function seems x86-specific. The low 1MB
> may not be mapped on ARM64.
>
> I would move the whole function (acpi_os_map_memory) per-architecture.
That's an option too, since once the "/* The low first Mb is always
mapped. */" bit is removed (which it should be since it is x86 specific)
then there isn't much left.
Ian.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers
2015-02-05 11:04 ` Ian Campbell
@ 2015-02-05 11:35 ` Jan Beulich
2015-02-05 11:57 ` Ian Campbell
2015-02-05 14:05 ` Julien Grall
1 sibling, 1 reply; 166+ messages in thread
From: Jan Beulich @ 2015-02-05 11:35 UTC (permalink / raw)
To: Ian Campbell, Julien Grall
Cc: Naresh Bhat, tim, xen-devel, stefano.stabellini, parth.dixit,
christoffer.dall
>>> On 05.02.15 at 12:04, <Ian.Campbell@citrix.com> wrote:
> On Wed, 2015-02-04 at 17:36 +0000, Julien Grall wrote:
>> I would move the whole function (acpi_os_map_memory) per-architecture.
>
> That's an option too, since once the "/* The low first Mb is always
> mapped. */" bit is removed (which it should be since it is x86 specific)
> then there isn't much left.
But it's an OS interface function ACPI CA wants, and as such it
belongs into osl.c.
Jan
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers
2015-02-05 11:35 ` Jan Beulich
@ 2015-02-05 11:57 ` Ian Campbell
2015-02-05 12:01 ` Jan Beulich
0 siblings, 1 reply; 166+ messages in thread
From: Ian Campbell @ 2015-02-05 11:57 UTC (permalink / raw)
To: Jan Beulich
Cc: Naresh Bhat, Julien Grall, tim, xen-devel, stefano.stabellini,
parth.dixit, christoffer.dall
On Thu, 2015-02-05 at 11:35 +0000, Jan Beulich wrote:
> >>> On 05.02.15 at 12:04, <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2015-02-04 at 17:36 +0000, Julien Grall wrote:
> >> I would move the whole function (acpi_os_map_memory) per-architecture.
> >
> > That's an option too, since once the "/* The low first Mb is always
> > mapped. */" bit is removed (which it should be since it is x86 specific)
> > then there isn't much left.
>
> But it's an OS interface function ACPI CA wants, and as such it
> belongs into osl.c.
OK, then it certainly needs an X86 ifdef around the first-Mb stuff, and
for the __acpi_map thing to be arch specific rather than ifdef'd.
Ian
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers
2015-02-05 11:57 ` Ian Campbell
@ 2015-02-05 12:01 ` Jan Beulich
0 siblings, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-05 12:01 UTC (permalink / raw)
To: Ian Campbell
Cc: Naresh Bhat, Julien Grall, tim, xen-devel, stefano.stabellini,
parth.dixit, christoffer.dall
>>> On 05.02.15 at 12:57, <Ian.Campbell@citrix.com> wrote:
> On Thu, 2015-02-05 at 11:35 +0000, Jan Beulich wrote:
>> >>> On 05.02.15 at 12:04, <Ian.Campbell@citrix.com> wrote:
>> > On Wed, 2015-02-04 at 17:36 +0000, Julien Grall wrote:
>> >> I would move the whole function (acpi_os_map_memory) per-architecture.
>> >
>> > That's an option too, since once the "/* The low first Mb is always
>> > mapped. */" bit is removed (which it should be since it is x86 specific)
>> > then there isn't much left.
>>
>> But it's an OS interface function ACPI CA wants, and as such it
>> belongs into osl.c.
>
> OK, then it certainly needs an X86 ifdef around the first-Mb stuff, and
> for the __acpi_map thing to be arch specific rather than ifdef'd.
The function could do with some better abstraction anyway.
Jan
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers
2015-02-05 11:04 ` Ian Campbell
2015-02-05 11:35 ` Jan Beulich
@ 2015-02-05 14:05 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-05 14:05 UTC (permalink / raw)
To: Ian Campbell
Cc: Naresh Bhat, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
Hi Ian,
On 05/02/2015 19:04, Ian Campbell wrote:
> On Wed, 2015-02-04 at 17:36 +0000, Julien Grall wrote:
>> I remembered to have a discussion about this change with Naresh few
>> month ago.
>>
>> __va should only be used when the memory is direct-mapped to Xen (i.e
>> accessible directly). On ARM64, this only the case for the RAM. Can you
>> confirm that ACPI will always reside to the RAM?
>
> Even if the answer is yes then rather than adding loads of ifdefs it
> seems like the right thing would be to implement __acpi_map_table on
> ARM, even if the implementation ends up being only return __va(phys).
>
>> Futhermore, the code of this function seems x86-specific. The low 1MB
>> may not be mapped on ARM64.
>>
>> I would move the whole function (acpi_os_map_memory) per-architecture.
>
> That's an option too, since once the "/* The low first Mb is always
> mapped. */" bit is removed (which it should be since it is x86 specific)
> then there isn't much left.
Assuming that the ACPI always resides in RAM, the vmap would be
irrelevant for ARM64, and a waste of memory.
So it would be better to move the acp_os_map_memory per-architecture.
IIRC it's what they choose in the ACPI series.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers
2015-02-04 17:36 ` Julien Grall
2015-02-05 11:04 ` Ian Campbell
@ 2015-02-05 11:34 ` Jan Beulich
2015-02-05 11:56 ` Ian Campbell
1 sibling, 1 reply; 166+ messages in thread
From: Jan Beulich @ 2015-02-05 11:34 UTC (permalink / raw)
To: Julien Grall, parth.dixit, xen-devel
Cc: Naresh Bhat, stefano.stabellini, ian.campbell, christoffer.dall,
tim
>>> On 04.02.15 at 18:36, <julien.grall@linaro.org> wrote:
>> --- a/xen/drivers/acpi/osl.c
>> +++ b/xen/drivers/acpi/osl.c
>> @@ -96,7 +96,11 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>> return __va(phys);
>> return __vmap(&pfn, PFN_UP(offs + size), 1, 1, PAGE_HYPERVISOR_NOCACHE) + offs;
>> }
>> +#ifdef CONFIG_X86
>> return __acpi_map_table(phys, size);
>> +#else
>> + return __va(phys);
>
> I remembered to have a discussion about this change with Naresh few
> month ago.
>
> __va should only be used when the memory is direct-mapped to Xen (i.e
> accessible directly). On ARM64, this only the case for the RAM. Can you
> confirm that ACPI will always reside to the RAM?
>
> Futhermore, the code of this function seems x86-specific. The low 1MB
> may not be mapped on ARM64.
>
> I would move the whole function (acpi_os_map_memory) per-architecture.
You mean __acpi_map_table() I suppose. acpi_os_map_memory()
should remain here.
>> @@ -140,6 +145,7 @@ acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width)
>>
>> return AE_OK;
>> }
>> +#endif
>
> Why only x86? Linux seems to define it also for ARM64.
What is a port on ARM?
>> +#define ACPI_DISABLE_IRQS() local_irq_disable()
>> +#define ACPI_ENABLE_IRQS() local_irq_enable()
>> +#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()
>> +
>> +/* Blob handling macros */
>> +#define ACPI_BLOB_HEADER_SIZE 8
>> +
>> +/* Basic configuration for ACPI */
>> +#ifdef CONFIG_ACPI
>> +extern int acpi_disabled;
>> +extern int acpi_noirq;
>> +extern int acpi_pci_disabled;
>> +extern int acpi_strict;
>
> I think it would be better to define common external variable in a
> common headers. Although I'm an ACPI maintainers...
I fully agree. I any such cleanup opportunities are noticed, they
should go into a prereq patch.
Jan
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers
2015-02-05 11:34 ` Jan Beulich
@ 2015-02-05 11:56 ` Ian Campbell
0 siblings, 0 replies; 166+ messages in thread
From: Ian Campbell @ 2015-02-05 11:56 UTC (permalink / raw)
To: Jan Beulich
Cc: Naresh Bhat, Julien Grall, tim, xen-devel, stefano.stabellini,
parth.dixit, christoffer.dall
On Thu, 2015-02-05 at 11:34 +0000, Jan Beulich wrote:
> >> @@ -140,6 +145,7 @@ acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width)
> >>
> >> return AE_OK;
> >> }
> >> +#endif
> >
> > Why only x86? Linux seems to define it also for ARM64.
>
> What is a port on ARM?
I don't know how common it is now, but on older ARM systems it wasn't
uncommon to reuse ISA type peripherals and the port space would be
mapped to a specific hardcoded MMIO region.
Even on modern h/w PCI host controllers have an MMIO region associated
with the I/O ports of the PCI cards on the bus.
All that said, I think it would be good to avoid doing anything with I/O
ports without a specific requirement arising from some h/w or the spec,
at least initially.
Ian.
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 03/35] xen: arm64: ACPI: Add basic ACPI initialization
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
2015-02-04 14:01 ` [PATCH RFC 01/35] xen: acpi: Build numa and pmstate x86 only parth.dixit
2015-02-04 14:01 ` [PATCH RFC 02/35] xen: arm64: ACPI: Support common ACPI drivers parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-04 17:40 ` Stefano Stabellini
2015-02-04 21:00 ` Julien Grall
2015-02-04 14:01 ` [PATCH RFC 04/35] ACPI / ACPICA: Introduce ARM Boot Architecture Flags in FADT parth.dixit
` (32 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
This patch introduce arm-core.c and its related header file
- asm/acpi.h for arch specific variables and functions needed by
ACPI driver core;
- arm-core.c for ARM64 related ACPI implementation for ACPI driver
core;
acpi_boot_table_init() will be called in setup_arch()
to get the RSDP and all the table pointers. with this patch,
we can get ACPI boot-time tables from firmware on ARM64.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/arch/arm/arm64/Makefile | 1 +
xen/arch/arm/arm64/acpi/Makefile | 1 +
xen/arch/arm/arm64/acpi/arm-core.c | 97 ++++++++++++++++++++++++++++++++++++++
xen/arch/arm/setup.c | 14 +++++-
xen/include/xen/acpi.h | 11 +++++
5 files changed, 123 insertions(+), 1 deletion(-)
create mode 100644 xen/arch/arm/arm64/acpi/Makefile
create mode 100644 xen/arch/arm/arm64/acpi/arm-core.c
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index c7243f5..49d135f 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,4 +1,5 @@
subdir-y += lib
+subdir-y += acpi
obj-y += entry.o
diff --git a/xen/arch/arm/arm64/acpi/Makefile b/xen/arch/arm/arm64/acpi/Makefile
new file mode 100644
index 0000000..07e3c44
--- /dev/null
+++ b/xen/arch/arm/arm64/acpi/Makefile
@@ -0,0 +1 @@
+obj-y += arm-core.o
diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
new file mode 100644
index 0000000..50a83d6
--- /dev/null
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -0,0 +1,97 @@
+/*
+ * ARM64 Specific Low-Level ACPI Boot Support
+ *
+ * Copyright (C) 2014, Naresh Bhat <naresh.bhat@linaro.org>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+#include <xen/init.h>
+#include <xen/acpi.h>
+
+#include <asm/acpi.h>
+
+/*
+ * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
+ * variable is still required by the ACPI core
+ */
+u32 acpi_rsdt_forced;
+
+int acpi_noirq; /* skip ACPI IRQ initialization */
+int acpi_strict;
+int acpi_disabled;
+EXPORT_SYMBOL(acpi_disabled);
+
+int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
+EXPORT_SYMBOL(acpi_pci_disabled);
+
+enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
+
+struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
+
+int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
+{
+ *irq = -1;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
+
+/*
+ * success: return IRQ number (>0)
+ * failure: return =< 0
+ */
+//int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
+unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low)
+{
+ return -1;
+}
+EXPORT_SYMBOL_GPL(acpi_register_gsi);
+
+void acpi_unregister_gsi(u32 gsi)
+{
+}
+EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
+
+/*
+ * acpi_boot_table_init() called from setup_arch(), always.
+ * 1. find RSDP and get its address, and then find XSDT
+ * 2. extract all tables and checksums them all
+ *
+ * We can parse ACPI boot-time tables such as FADT, MADT after
+ * this function is called.
+ */
+int __init acpi_boot_table_init(void)
+{
+ int error;
+ /* If acpi_disabled, bail out */
+ if (acpi_disabled)
+ return 1;
+
+ /* Initialize the ACPI boot-time table parser. */
+ error = acpi_table_init();
+ if (error)
+ {
+ disable_acpi();
+ return error;
+ }
+
+ return 0;
+}
+#endif
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 3991d64..7ae126b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -45,6 +45,8 @@
#include <asm/procinfo.h>
#include <asm/setup.h>
#include <xsm/xsm.h>
+#include <xen/acpi.h>
+#include <asm/acpi.h>
struct bootinfo __initdata bootinfo;
@@ -737,7 +739,18 @@ void __init start_xen(unsigned long boot_phys_offset,
setup_mm(fdt_paddr, fdt_size);
+ system_state = SYS_STATE_boot;
+
vm_init();
+
+/*
+ * Parse the ACPI tables for possible boot-time configuration
+ */
+
+#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
+ acpi_boot_table_init();
+#endif
+
dt_unflatten_host_device_tree();
dt_irq_xlate = gic_irq_xlate;
@@ -802,7 +815,6 @@ void __init start_xen(unsigned long boot_phys_offset,
printk("Failed to bring up CPU %u (error %d)\n", i, ret);
}
}
-
printk("Brought up %ld CPUs\n", (long)num_online_cpus());
/* TODO: smp_cpus_done(); */
diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
index 3aeba4a..ff96336 100644
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -42,6 +42,17 @@
#ifdef CONFIG_ACPI_BOOT
+enum acpi_irq_model_id {
+ ACPI_IRQ_MODEL_PIC = 0,
+ ACPI_IRQ_MODEL_IOAPIC,
+ ACPI_IRQ_MODEL_IOSAPIC,
+ ACPI_IRQ_MODEL_PLATFORM,
+ ACPI_IRQ_MODEL_GIC,
+ ACPI_IRQ_MODEL_COUNT
+};
+
+extern enum acpi_irq_model_id acpi_irq_model;
+
enum acpi_interrupt_id {
ACPI_INTERRUPT_PMI = 1,
ACPI_INTERRUPT_INIT,
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 03/35] xen: arm64: ACPI: Add basic ACPI initialization
2015-02-04 14:01 ` [PATCH RFC 03/35] xen: arm64: ACPI: Add basic ACPI initialization parth.dixit
@ 2015-02-04 17:40 ` Stefano Stabellini
2015-02-04 21:00 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-04 17:40 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> This patch introduce arm-core.c and its related header file
>
> - asm/acpi.h for arch specific variables and functions needed by
> ACPI driver core;
> - arm-core.c for ARM64 related ACPI implementation for ACPI driver
> core;
>
> acpi_boot_table_init() will be called in setup_arch()
> to get the RSDP and all the table pointers. with this patch,
> we can get ACPI boot-time tables from firmware on ARM64.
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/arch/arm/arm64/Makefile | 1 +
> xen/arch/arm/arm64/acpi/Makefile | 1 +
> xen/arch/arm/arm64/acpi/arm-core.c | 97 ++++++++++++++++++++++++++++++++++++++
> xen/arch/arm/setup.c | 14 +++++-
> xen/include/xen/acpi.h | 11 +++++
> 5 files changed, 123 insertions(+), 1 deletion(-)
> create mode 100644 xen/arch/arm/arm64/acpi/Makefile
> create mode 100644 xen/arch/arm/arm64/acpi/arm-core.c
>
> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> index c7243f5..49d135f 100644
> --- a/xen/arch/arm/arm64/Makefile
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -1,4 +1,5 @@
> subdir-y += lib
> +subdir-y += acpi
>
> obj-y += entry.o
>
> diff --git a/xen/arch/arm/arm64/acpi/Makefile b/xen/arch/arm/arm64/acpi/Makefile
> new file mode 100644
> index 0000000..07e3c44
> --- /dev/null
> +++ b/xen/arch/arm/arm64/acpi/Makefile
> @@ -0,0 +1 @@
> +obj-y += arm-core.o
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> new file mode 100644
> index 0000000..50a83d6
> --- /dev/null
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -0,0 +1,97 @@
> +/*
> + * ARM64 Specific Low-Level ACPI Boot Support
> + *
> + * Copyright (C) 2014, Naresh Bhat <naresh.bhat@linaro.org>
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + */
> +
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> +#include <xen/init.h>
> +#include <xen/acpi.h>
> +
> +#include <asm/acpi.h>
> +
> +/*
> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> + * variable is still required by the ACPI core
> + */
> +u32 acpi_rsdt_forced;
> +
> +int acpi_noirq; /* skip ACPI IRQ initialization */
> +int acpi_strict;
> +int acpi_disabled;
> +EXPORT_SYMBOL(acpi_disabled);
> +
> +int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
> +EXPORT_SYMBOL(acpi_pci_disabled);
As I wrote in the previous email, all these options need a comment that
explain what they mean.
The EXPORT_SYMBOL are unnecessary.
> +enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
> +
> +struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
> +
> +int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
> +{
> + *irq = -1;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
> +
> +/*
> + * success: return IRQ number (>0)
> + * failure: return =< 0
> + */
> +//int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
> +unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low)
> +{
> + return -1;
> +}
> +EXPORT_SYMBOL_GPL(acpi_register_gsi);
> +
> +void acpi_unregister_gsi(u32 gsi)
> +{
> +}
> +EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
> +
> +/*
> + * acpi_boot_table_init() called from setup_arch(), always.
> + * 1. find RSDP and get its address, and then find XSDT
> + * 2. extract all tables and checksums them all
> + *
> + * We can parse ACPI boot-time tables such as FADT, MADT after
> + * this function is called.
> + */
> +int __init acpi_boot_table_init(void)
> +{
> + int error;
> + /* If acpi_disabled, bail out */
> + if (acpi_disabled)
> + return 1;
> +
> + /* Initialize the ACPI boot-time table parser. */
> + error = acpi_table_init();
> + if (error)
> + {
> + disable_acpi();
> + return error;
> + }
> +
> + return 0;
> +}
> +#endif
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 3991d64..7ae126b 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -45,6 +45,8 @@
> #include <asm/procinfo.h>
> #include <asm/setup.h>
> #include <xsm/xsm.h>
> +#include <xen/acpi.h>
> +#include <asm/acpi.h>
>
> struct bootinfo __initdata bootinfo;
>
> @@ -737,7 +739,18 @@ void __init start_xen(unsigned long boot_phys_offset,
>
> setup_mm(fdt_paddr, fdt_size);
>
> + system_state = SYS_STATE_boot;
> +
> vm_init();
> +
> +/*
> + * Parse the ACPI tables for possible boot-time configuration
> + */
> +
> +#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
> + acpi_boot_table_init();
> +#endif
> +
> dt_unflatten_host_device_tree();
> dt_irq_xlate = gic_irq_xlate;
>
> @@ -802,7 +815,6 @@ void __init start_xen(unsigned long boot_phys_offset,
> printk("Failed to bring up CPU %u (error %d)\n", i, ret);
> }
> }
> -
> printk("Brought up %ld CPUs\n", (long)num_online_cpus());
> /* TODO: smp_cpus_done(); */
spurious change
> diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
> index 3aeba4a..ff96336 100644
> --- a/xen/include/xen/acpi.h
> +++ b/xen/include/xen/acpi.h
> @@ -42,6 +42,17 @@
>
> #ifdef CONFIG_ACPI_BOOT
>
> +enum acpi_irq_model_id {
> + ACPI_IRQ_MODEL_PIC = 0,
> + ACPI_IRQ_MODEL_IOAPIC,
> + ACPI_IRQ_MODEL_IOSAPIC,
> + ACPI_IRQ_MODEL_PLATFORM,
> + ACPI_IRQ_MODEL_GIC,
> + ACPI_IRQ_MODEL_COUNT
> +};
> +
> +extern enum acpi_irq_model_id acpi_irq_model;
> +
> enum acpi_interrupt_id {
> ACPI_INTERRUPT_PMI = 1,
> ACPI_INTERRUPT_INIT,
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 03/35] xen: arm64: ACPI: Add basic ACPI initialization
2015-02-04 14:01 ` [PATCH RFC 03/35] xen: arm64: ACPI: Add basic ACPI initialization parth.dixit
2015-02-04 17:40 ` Stefano Stabellini
@ 2015-02-04 21:00 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-04 21:00 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, stefano.stabellini, jbeulich,
christoffer.dall
Hi Parth,
On 04/02/2015 14:01, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> This patch introduce arm-core.c and its related header file
>
> - asm/acpi.h for arch specific variables and functions needed by
> ACPI driver core;
> - arm-core.c for ARM64 related ACPI implementation for ACPI driver
> core;
>
> acpi_boot_table_init() will be called in setup_arch()
> to get the RSDP and all the table pointers. with this patch,
> we can get ACPI boot-time tables from firmware on ARM64.
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/arch/arm/arm64/Makefile | 1 +
> xen/arch/arm/arm64/acpi/Makefile | 1 +
> xen/arch/arm/arm64/acpi/arm-core.c | 97 ++++++++++++++++++++++++++++++++++++++
> xen/arch/arm/setup.c | 14 +++++-
> xen/include/xen/acpi.h | 11 +++++
> 5 files changed, 123 insertions(+), 1 deletion(-)
> create mode 100644 xen/arch/arm/arm64/acpi/Makefile
> create mode 100644 xen/arch/arm/arm64/acpi/arm-core.c
>
> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> index c7243f5..49d135f 100644
> --- a/xen/arch/arm/arm64/Makefile
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -1,4 +1,5 @@
> subdir-y += lib
> +subdir-y += acpi
It would be more logic to include this directory only when HAS_ACPI is
defined.
It would be smth like:
subdir-$(HAS_ACPI) += acpi
[...]
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
I think "arm" is pointless in the filename. Maybe core.c would be a
better name?
> new file mode 100644
> index 0000000..50a83d6
> --- /dev/null
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -0,0 +1,97 @@
[..]
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
Compiling the directory only when HAS_ACPI is enabled would avoid a
pointless #ifdef here.
> +#include <xen/init.h>
> +#include <xen/acpi.h>
> +
> +#include <asm/acpi.h>
You should be consistent here, the acpi.h headers is in asm so generic
to all ARM architecture but the ACPI code actually reside in an ARM64
directory.
Even though ACPI is only ARM64, this code doesn't seem ARM64 specific.
So I would move the directory in arch/arm/
> +
> +/*
> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> + * variable is still required by the ACPI core
> + */
> +u32 acpi_rsdt_forced;
I didn't find any usage for this in Xen.
> +int acpi_noirq; /* skip ACPI IRQ initialization */
This is set but never used.
> +int acpi_strict;
I didn't find any usage for this in Xen.
> +int acpi_disabled;
> +EXPORT_SYMBOL(acpi_disabled);
> +
> +int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
> +EXPORT_SYMBOL(acpi_pci_disabled);
This is set but never used.
> +enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
Why do you define acpi_irq_model to ACPI_IRQ_MODEL_PLATFORM here and in
patch #15, change to ACPI_IRQ_MODEL_PLATFORM?
Furthermore, you set it, but never use it.
> +
> +struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
I didn't find any usage in Xen.
> +
> +int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
> +{
> + *irq = -1;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
This function is never used. I found a prototype defined in the headers
(xen/acpi.h) few years ago but not implemented on x86.
I suspect that we forgot to drop the prototype at some point. Can you
send a patch to remove it?
> +
> +/*
> + * success: return IRQ number (>0)
> + * failure: return =< 0
> + */
> +//int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
> +unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low)
> +{
> + return -1;
> +}
> +EXPORT_SYMBOL_GPL(acpi_register_gsi);
> +
> +void acpi_unregister_gsi(u32 gsi)
> +{
> +}
> +EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
Ditto for these 2 functions.
> +/*
> + * acpi_boot_table_init() called from setup_arch(), always.
> + * 1. find RSDP and get its address, and then find XSDT
> + * 2. extract all tables and checksums them all
> + *
> + * We can parse ACPI boot-time tables such as FADT, MADT after
> + * this function is called.
> + */
> +int __init acpi_boot_table_init(void)
> +{
> + int error;
> + /* If acpi_disabled, bail out */
> + if (acpi_disabled)
> + return 1;
> +
> + /* Initialize the ACPI boot-time table parser. */
> + error = acpi_table_init();
> + if (error)
> + {
> + disable_acpi();
> + return error;
> + }
> +
> + return 0;
> +}
> +#endif
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 3991d64..7ae126b 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -45,6 +45,8 @@
> #include <asm/procinfo.h>
> #include <asm/setup.h>
> #include <xsm/xsm.h>
> +#include <xen/acpi.h>
> +#include <asm/acpi.h>
>
> struct bootinfo __initdata bootinfo;
>
> @@ -737,7 +739,18 @@ void __init start_xen(unsigned long boot_phys_offset,
>
> setup_mm(fdt_paddr, fdt_size);
>
> + system_state = SYS_STATE_boot;
> +
Hmmm why? Is it because of the memory allocator in ACPI? If so, you
should justify a such change and drop the other system_state =
SYS_STATE_boot within this function.
> vm_init();
> +
> +/*
> + * Parse the ACPI tables for possible boot-time configuration
> + */
> +
> +#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
No need to check CONFIG_ARM_64 here, CONFIG_ACPI is only defined for ARM64.
Although, a stub exist when CONFIG_ACPI_BOOT (implicitly enabled with
CONFIG_ACPI) is not enabled. So maybe we should just drop the #ifdef.
> + acpi_boot_table_init();
Should not we return try to use the device tree when ACPI return an
error. What about the Linux boot protocol? I.e prefer DT when it's present?
> +#endif
> +
> dt_unflatten_host_device_tree();
> dt_irq_xlate = gic_irq_xlate;
This 2 lines should not be necessary when ACPI is used. Please make sure
that we never used the device tree in this case. This would help us to
catch possible error later.
>
> @@ -802,7 +815,6 @@ void __init start_xen(unsigned long boot_phys_offset,
> printk("Failed to bring up CPU %u (error %d)\n", i, ret);
> }
> }
> -
Spurious change
> printk("Brought up %ld CPUs\n", (long)num_online_cpus());
> /* TODO: smp_cpus_done(); */
>
> diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
> index 3aeba4a..ff96336 100644
> --- a/xen/include/xen/acpi.h
> +++ b/xen/include/xen/acpi.h
> @@ -42,6 +42,17 @@
>
> #ifdef CONFIG_ACPI_BOOT
>
> +enum acpi_irq_model_id {
> + ACPI_IRQ_MODEL_PIC = 0,
> + ACPI_IRQ_MODEL_IOAPIC,
> + ACPI_IRQ_MODEL_IOSAPIC,
> + ACPI_IRQ_MODEL_PLATFORM,
> + ACPI_IRQ_MODEL_GIC,
> + ACPI_IRQ_MODEL_COUNT
> +};
> +
> +extern enum acpi_irq_model_id acpi_irq_model;
> +
If we still need it (see my comment on the declaration above). Then this
should be moved in asm/acpi.h.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 04/35] ACPI / ACPICA: Introduce ARM Boot Architecture Flags in FADT
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (2 preceding siblings ...)
2015-02-04 14:01 ` [PATCH RFC 03/35] xen: arm64: ACPI: Add basic ACPI initialization parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-04 17:42 ` Stefano Stabellini
2015-02-04 21:03 ` Julien Grall
2015-02-04 14:01 ` [PATCH RFC 05/35] ARM64 / ACPI: Parse FADT table to get PSCI flags parth.dixit
` (31 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
The Power State Coordination Interface (PSCI) defines an API that
can be used to coordinate power control amongst the various supervisory
systems concurrently running on a device. ACPI support for this
technology would require the addition of two flags: PSCI_COMPLIANT and
PSCI_USE_HVC. When set, the former signals to the OS that the hardware
is PSCI compliant. The latter selects the appropriate conduit for PSCI
calls by toggling between Hypervisor Calls (HVC) and Secure Monitor
Calls (SMC).
An ARM Boot Architecture Flags structure to support new ARM hardware
was introduced in FADT in ACPI 5.1, add the code accordingly to
implement that in ACPICA core.
Since ACPI 5.1 doesn't support self defined PSCI function IDs,
which means that only PSCI 0.2+ is supported in ACPI.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/include/acpi/actbl.h | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/xen/include/acpi/actbl.h b/xen/include/acpi/actbl.h
index 856945d..34e8673 100644
--- a/xen/include/acpi/actbl.h
+++ b/xen/include/acpi/actbl.h
@@ -244,7 +244,8 @@ struct acpi_table_fadt {
u32 flags; /* Miscellaneous flag bits (see below for individual flags) */
struct acpi_generic_address reset_register; /* 64-bit address of the Reset register */
u8 reset_value; /* Value to write to the reset_register port to reset the system */
- u8 reserved4[3]; /* Reserved, must be zero */
+ u16 arm_boot_flags; /* ARM Boot Architecture Flags (see below for individual flags) */
+ u8 minor_version; /* Minor version of this FADT structure */
u64 Xfacs; /* 64-bit physical address of FACS */
u64 Xdsdt; /* 64-bit physical address of DSDT */
struct acpi_generic_address xpm1a_event_block; /* 64-bit Extended Power Mgt 1a Event Reg Blk address */
@@ -259,7 +260,7 @@ struct acpi_table_fadt {
struct acpi_generic_address sleep_status; /* 64-bit Sleep Status register */
};
-/* Masks for FADT Boot Architecture Flags (boot_flags) */
+/* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced in this FADT revision */
#define ACPI_FADT_LEGACY_DEVICES (1) /* 00: [V2] System has LPC or ISA bus devices */
#define ACPI_FADT_8042 (1<<1) /* 01: [V3] System has an 8042 controller on port 60/64 */
@@ -270,6 +271,11 @@ struct acpi_table_fadt {
#define FADT2_REVISION_ID 3
+/* Masks for FADT ARM Boot Architecture Flags (arm_boot_flags) */
+
+#define ACPI_FADT_PSCI_COMPLIANT (1) /* 00: PSCI 0.2+ is implemented */
+#define ACPI_FADT_PSCI_USE_HVC (1<<1) /* 01: HVC must be used instead of SMC as the PSCI conduit */
+
/* Masks for FADT flags */
#define ACPI_FADT_WBINVD (1) /* 00: [V1] The wbinvd instruction works properly */
@@ -345,7 +351,7 @@ enum acpi_prefered_pm_profiles {
* FADT V5 size: 0x10C
*/
#define ACPI_FADT_V1_SIZE (u32) (ACPI_FADT_OFFSET (flags) + 4)
-#define ACPI_FADT_V2_SIZE (u32) (ACPI_FADT_OFFSET (reserved4[0]) + 3)
+#define ACPI_FADT_V2_SIZE (u32) (ACPI_FADT_OFFSET (arm_boot_flags) + 3)
#define ACPI_FADT_V3_SIZE (u32) (ACPI_FADT_OFFSET (sleep_control))
#define ACPI_FADT_V5_SIZE (u32) (sizeof (struct acpi_table_fadt))
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 04/35] ACPI / ACPICA: Introduce ARM Boot Architecture Flags in FADT
2015-02-04 14:01 ` [PATCH RFC 04/35] ACPI / ACPICA: Introduce ARM Boot Architecture Flags in FADT parth.dixit
@ 2015-02-04 17:42 ` Stefano Stabellini
2015-02-04 21:03 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-04 17:42 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> The Power State Coordination Interface (PSCI) defines an API that
> can be used to coordinate power control amongst the various supervisory
> systems concurrently running on a device. ACPI support for this
> technology would require the addition of two flags: PSCI_COMPLIANT and
> PSCI_USE_HVC. When set, the former signals to the OS that the hardware
> is PSCI compliant. The latter selects the appropriate conduit for PSCI
> calls by toggling between Hypervisor Calls (HVC) and Secure Monitor
> Calls (SMC).
>
> An ARM Boot Architecture Flags structure to support new ARM hardware
> was introduced in FADT in ACPI 5.1, add the code accordingly to
> implement that in ACPICA core.
>
> Since ACPI 5.1 doesn't support self defined PSCI function IDs,
> which means that only PSCI 0.2+ is supported in ACPI.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/include/acpi/actbl.h | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/xen/include/acpi/actbl.h b/xen/include/acpi/actbl.h
> index 856945d..34e8673 100644
> --- a/xen/include/acpi/actbl.h
> +++ b/xen/include/acpi/actbl.h
> @@ -244,7 +244,8 @@ struct acpi_table_fadt {
> u32 flags; /* Miscellaneous flag bits (see below for individual flags) */
> struct acpi_generic_address reset_register; /* 64-bit address of the Reset register */
> u8 reset_value; /* Value to write to the reset_register port to reset the system */
> - u8 reserved4[3]; /* Reserved, must be zero */
> + u16 arm_boot_flags; /* ARM Boot Architecture Flags (see below for individual flags) */
> + u8 minor_version; /* Minor version of this FADT structure */
indentation
> u64 Xfacs; /* 64-bit physical address of FACS */
> u64 Xdsdt; /* 64-bit physical address of DSDT */
> struct acpi_generic_address xpm1a_event_block; /* 64-bit Extended Power Mgt 1a Event Reg Blk address */
> @@ -259,7 +260,7 @@ struct acpi_table_fadt {
> struct acpi_generic_address sleep_status; /* 64-bit Sleep Status register */
> };
>
> -/* Masks for FADT Boot Architecture Flags (boot_flags) */
> +/* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced in this FADT revision */
>
> #define ACPI_FADT_LEGACY_DEVICES (1) /* 00: [V2] System has LPC or ISA bus devices */
> #define ACPI_FADT_8042 (1<<1) /* 01: [V3] System has an 8042 controller on port 60/64 */
> @@ -270,6 +271,11 @@ struct acpi_table_fadt {
>
> #define FADT2_REVISION_ID 3
>
> +/* Masks for FADT ARM Boot Architecture Flags (arm_boot_flags) */
> +
> +#define ACPI_FADT_PSCI_COMPLIANT (1) /* 00: PSCI 0.2+ is implemented */
> +#define ACPI_FADT_PSCI_USE_HVC (1<<1) /* 01: HVC must be used instead of SMC as the PSCI conduit */
> +
> /* Masks for FADT flags */
>
> #define ACPI_FADT_WBINVD (1) /* 00: [V1] The wbinvd instruction works properly */
> @@ -345,7 +351,7 @@ enum acpi_prefered_pm_profiles {
> * FADT V5 size: 0x10C
> */
> #define ACPI_FADT_V1_SIZE (u32) (ACPI_FADT_OFFSET (flags) + 4)
> -#define ACPI_FADT_V2_SIZE (u32) (ACPI_FADT_OFFSET (reserved4[0]) + 3)
> +#define ACPI_FADT_V2_SIZE (u32) (ACPI_FADT_OFFSET (arm_boot_flags) + 3)
> #define ACPI_FADT_V3_SIZE (u32) (ACPI_FADT_OFFSET (sleep_control))
> #define ACPI_FADT_V5_SIZE (u32) (sizeof (struct acpi_table_fadt))
>
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 04/35] ACPI / ACPICA: Introduce ARM Boot Architecture Flags in FADT
2015-02-04 14:01 ` [PATCH RFC 04/35] ACPI / ACPICA: Introduce ARM Boot Architecture Flags in FADT parth.dixit
2015-02-04 17:42 ` Stefano Stabellini
@ 2015-02-04 21:03 ` Julien Grall
2015-02-05 11:06 ` Ian Campbell
1 sibling, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-04 21:03 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, stefano.stabellini, jbeulich,
christoffer.dall
Hi Parth,
On 04/02/2015 14:01, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> The Power State Coordination Interface (PSCI) defines an API that
> can be used to coordinate power control amongst the various supervisory
> systems concurrently running on a device. ACPI support for this
> technology would require the addition of two flags: PSCI_COMPLIANT and
> PSCI_USE_HVC. When set, the former signals to the OS that the hardware
> is PSCI compliant. The latter selects the appropriate conduit for PSCI
> calls by toggling between Hypervisor Calls (HVC) and Secure Monitor
> Calls (SMC).
>
> An ARM Boot Architecture Flags structure to support new ARM hardware
> was introduced in FADT in ACPI 5.1, add the code accordingly to
> implement that in ACPICA core.
>
> Since ACPI 5.1 doesn't support self defined PSCI function IDs,
> which means that only PSCI 0.2+ is supported in ACPI.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/include/acpi/actbl.h | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/xen/include/acpi/actbl.h b/xen/include/acpi/actbl.h
> index 856945d..34e8673 100644
> --- a/xen/include/acpi/actbl.h
> +++ b/xen/include/acpi/actbl.h
> @@ -244,7 +244,8 @@ struct acpi_table_fadt {
> u32 flags; /* Miscellaneous flag bits (see below for individual flags) */
> struct acpi_generic_address reset_register; /* 64-bit address of the Reset register */
> u8 reset_value; /* Value to write to the reset_register port to reset the system */
> - u8 reserved4[3]; /* Reserved, must be zero */
> + u16 arm_boot_flags; /* ARM Boot Architecture Flags (see below for individual flags) */
> + u8 minor_version; /* Minor version of this FADT structure */
The indentation is wrong. Beware that Xen is using space rather than tab
for the indentation.
> u64 Xfacs; /* 64-bit physical address of FACS */
> u64 Xdsdt; /* 64-bit physical address of DSDT */
> struct acpi_generic_address xpm1a_event_block; /* 64-bit Extended Power Mgt 1a Event Reg Blk address */
> @@ -259,7 +260,7 @@ struct acpi_table_fadt {
> struct acpi_generic_address sleep_status; /* 64-bit Sleep Status register */
> };
>
> -/* Masks for FADT Boot Architecture Flags (boot_flags) */
> +/* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced in this FADT revision */
What does "this FADT revision" means? Please be more specific by giving
the version.
>
> #define ACPI_FADT_LEGACY_DEVICES (1) /* 00: [V2] System has LPC or ISA bus devices */
> #define ACPI_FADT_8042 (1<<1) /* 01: [V3] System has an 8042 controller on port 60/64 */
> @@ -270,6 +271,11 @@ struct acpi_table_fadt {
>
> #define FADT2_REVISION_ID 3
>
> +/* Masks for FADT ARM Boot Architecture Flags (arm_boot_flags) */
> +
> +#define ACPI_FADT_PSCI_COMPLIANT (1) /* 00: PSCI 0.2+ is implemented */
> +#define ACPI_FADT_PSCI_USE_HVC (1<<1) /* 01: HVC must be used instead of SMC as the PSCI conduit */
> +
> /* Masks for FADT flags */
>
> #define ACPI_FADT_WBINVD (1) /* 00: [V1] The wbinvd instruction works properly */
> @@ -345,7 +351,7 @@ enum acpi_prefered_pm_profiles {
> * FADT V5 size: 0x10C
> */
> #define ACPI_FADT_V1_SIZE (u32) (ACPI_FADT_OFFSET (flags) + 4)
> -#define ACPI_FADT_V2_SIZE (u32) (ACPI_FADT_OFFSET (reserved4[0]) + 3)
> +#define ACPI_FADT_V2_SIZE (u32) (ACPI_FADT_OFFSET (arm_boot_flags) + 3)
> #define ACPI_FADT_V3_SIZE (u32) (ACPI_FADT_OFFSET (sleep_control))
> #define ACPI_FADT_V5_SIZE (u32) (sizeof (struct acpi_table_fadt))
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 04/35] ACPI / ACPICA: Introduce ARM Boot Architecture Flags in FADT
2015-02-04 21:03 ` Julien Grall
@ 2015-02-05 11:06 ` Ian Campbell
2015-02-05 14:09 ` Julien Grall
2015-02-05 14:10 ` Julien Grall
0 siblings, 2 replies; 166+ messages in thread
From: Ian Campbell @ 2015-02-05 11:06 UTC (permalink / raw)
To: Julien Grall
Cc: Naresh Bhat, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
On Wed, 2015-02-04 at 21:03 +0000, Julien Grall wrote:
> > -/* Masks for FADT Boot Architecture Flags (boot_flags) */
> > +/* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced in this FADT revision */
>
> What does "this FADT revision" means? Please be more specific by giving
> the version.
Isn't it a reference to the comments on each of the following entries
which start [V2], [V3], etc?
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 04/35] ACPI / ACPICA: Introduce ARM Boot Architecture Flags in FADT
2015-02-05 11:06 ` Ian Campbell
@ 2015-02-05 14:09 ` Julien Grall
2015-02-05 14:10 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-05 14:09 UTC (permalink / raw)
To: Ian Campbell
Cc: Naresh Bhat, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
Hi Ian,
On 05/02/2015 19:06, Ian Campbell wrote:
> On Wed, 2015-02-04 at 21:03 +0000, Julien Grall wrote:
>>> -/* Masks for FADT Boot Architecture Flags (boot_flags) */
>>> +/* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced in this FADT revision */
>>
>> What does "this FADT revision" means? Please be more specific by giving
>> the version.
>
> Isn't it a reference to the comments on each of the following entries
> which start [V2], [V3], etc?
Ah right, I was confused because this patch doesn't add any [Vx], but
only update the comment. The commit message should be updated to reflex
this thing.
BTW, shouldn't we precise the version of the PSCI flags?
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 04/35] ACPI / ACPICA: Introduce ARM Boot Architecture Flags in FADT
2015-02-05 11:06 ` Ian Campbell
2015-02-05 14:09 ` Julien Grall
@ 2015-02-05 14:10 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-05 14:10 UTC (permalink / raw)
To: Ian Campbell
Cc: Naresh Bhat, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
Hi Ian,
On 05/02/2015 19:06, Ian Campbell wrote:
> On Wed, 2015-02-04 at 21:03 +0000, Julien Grall wrote:
>>> -/* Masks for FADT Boot Architecture Flags (boot_flags) */
>>> +/* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced in this FADT revision */
>>
>> What does "this FADT revision" means? Please be more specific by giving
>> the version.
>
> Isn't it a reference to the comments on each of the following entries
> which start [V2], [V3], etc?
Ah right, I was confused because this patch doesn't add any [Vx], but
only update the comment. The commit message should be updated to reflex
this thing.
BTW, shouldn't we precise the version of the PSCI flags?
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 05/35] ARM64 / ACPI: Parse FADT table to get PSCI flags
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (3 preceding siblings ...)
2015-02-04 14:01 ` [PATCH RFC 04/35] ACPI / ACPICA: Introduce ARM Boot Architecture Flags in FADT parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-04 17:45 ` Stefano Stabellini
2015-02-04 21:14 ` Julien Grall
2015-02-04 14:01 ` [PATCH RFC 06/35] ACPI: Add Generic Interrupt and Distributor struct parth.dixit
` (30 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
Hanjun Guo, jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
the former signals to the OS that the hardware is PSCI compliant.
The latter selects the appropriate conduit for PSCI calls by
toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
(SMC).
FADT table contains such information, parse FADT to get the flags
for furture usage. At the same time, only ACPI 5.1 or higher verison
supports PSCI, and FADT Major.Minor version was introduced in ACPI
5.1, so we will check the version and only parse FADT table with
version >= 5.1.
If firmware provides ACPI tables with ACPI version less than 5.1,
OS will be messed up with those information, so disable ACPI if we
get an FADT table with version less that 5.1.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/arch/arm/arm64/acpi/arm-core.c | 54 +++++++++++++++++++++++++++++++++++---
xen/arch/arm/setup.c | 1 +
xen/include/asm-arm/acpi.h | 2 ++
3 files changed, 54 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
index 50a83d6..2b7e2ef 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -25,6 +25,7 @@
#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
#include <xen/init.h>
#include <xen/acpi.h>
+#include <xen/errno.h>
#include <asm/acpi.h>
@@ -42,6 +43,12 @@ EXPORT_SYMBOL(acpi_disabled);
int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
EXPORT_SYMBOL(acpi_pci_disabled);
+/* 1 to indicate PSCI is implemented */
+int acpi_psci_present;
+
+/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
+int acpi_psci_use_hvc;
+
enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
@@ -58,7 +65,7 @@ EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
* failure: return =< 0
*/
//int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
-unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low)
+unsigned int acpi_register_gsi(u32 gsi, int edge_level, int active_high_low)
{
return -1;
}
@@ -69,6 +76,33 @@ void acpi_unregister_gsi(u32 gsi)
}
EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
+static int __init acpi_parse_fadt(struct acpi_table_header *table)
+{
+ struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
+
+ /*
+ * Revision in table header is the FADT Major version,
+ * and there is a minor version of FADT which was introduced
+ * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
+ * to get arm boot flags, or we will disable ACPI.
+ */
+ if ( table->revision < 5 || fadt->minor_version < 1 ) {
+ printk("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
+ table->revision, fadt->minor_version);
+ acpi_psci_present = 0;
+ disable_acpi();
+ return -EINVAL;
+ }
+
+ if ( acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT )
+ acpi_psci_present = 1;
+
+ if ( acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC )
+ acpi_psci_use_hvc = 1;
+
+ return 0;
+}
+
/*
* acpi_boot_table_init() called from setup_arch(), always.
* 1. find RSDP and get its address, and then find XSDT
@@ -81,12 +115,12 @@ int __init acpi_boot_table_init(void)
{
int error;
/* If acpi_disabled, bail out */
- if (acpi_disabled)
+ if ( acpi_disabled )
return 1;
/* Initialize the ACPI boot-time table parser. */
error = acpi_table_init();
- if (error)
+ if ( error )
{
disable_acpi();
return error;
@@ -94,4 +128,18 @@ int __init acpi_boot_table_init(void)
return 0;
}
+
+int __init acpi_boot_init(void)
+{
+ int err = 0;
+ /* If acpi_disabled, bail out */
+ if (acpi_disabled)
+ return -ENODEV;
+
+ err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
+ if ( err )
+ printk("Can't find FADT\n");
+
+ return err;
+}
#endif
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7ae126b..3531d47 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -749,6 +749,7 @@ void __init start_xen(unsigned long boot_phys_offset,
#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
acpi_boot_table_init();
+ acpi_boot_init();
#endif
dt_unflatten_host_device_tree();
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index f6284b5..03051ef 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -60,6 +60,8 @@ extern int acpi_disabled;
extern int acpi_noirq;
extern int acpi_pci_disabled;
extern int acpi_strict;
+extern int acpi_psci_present;
+extern int acpi_psci_use_hvc;
/* map logic cpu id to physical APIC id
* APIC = GIC cpu interface on ARM
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 05/35] ARM64 / ACPI: Parse FADT table to get PSCI flags
2015-02-04 14:01 ` [PATCH RFC 05/35] ARM64 / ACPI: Parse FADT table to get PSCI flags parth.dixit
@ 2015-02-04 17:45 ` Stefano Stabellini
2015-02-05 3:56 ` Hanjun Guo
2015-02-05 11:09 ` Ian Campbell
2015-02-04 21:14 ` Julien Grall
1 sibling, 2 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-04 17:45 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, Hanjun Guo, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> the former signals to the OS that the hardware is PSCI compliant.
> The latter selects the appropriate conduit for PSCI calls by
> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> (SMC).
>
> FADT table contains such information, parse FADT to get the flags
> for furture usage. At the same time, only ACPI 5.1 or higher verison
> supports PSCI, and FADT Major.Minor version was introduced in ACPI
> 5.1, so we will check the version and only parse FADT table with
> version >= 5.1.
>
> If firmware provides ACPI tables with ACPI version less than 5.1,
> OS will be messed up with those information, so disable ACPI if we
> get an FADT table with version less that 5.1.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 54 +++++++++++++++++++++++++++++++++++---
> xen/arch/arm/setup.c | 1 +
> xen/include/asm-arm/acpi.h | 2 ++
> 3 files changed, 54 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index 50a83d6..2b7e2ef 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -25,6 +25,7 @@
> #if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> #include <xen/init.h>
> #include <xen/acpi.h>
> +#include <xen/errno.h>
>
> #include <asm/acpi.h>
>
> @@ -42,6 +43,12 @@ EXPORT_SYMBOL(acpi_disabled);
> int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
> EXPORT_SYMBOL(acpi_pci_disabled);
>
> +/* 1 to indicate PSCI is implemented */
> +int acpi_psci_present;
> +
> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> +int acpi_psci_use_hvc;
Can they be static?
Also it might be better to define an enum with values: PSCI_ABSENT, PSCI_HVC, PSCI_SMC.
> enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
>
> struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
> @@ -58,7 +65,7 @@ EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
> * failure: return =< 0
> */
> //int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
> -unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low)
> +unsigned int acpi_register_gsi(u32 gsi, int edge_level, int active_high_low)
> {
> return -1;
> }
> @@ -69,6 +76,33 @@ void acpi_unregister_gsi(u32 gsi)
> }
> EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
>
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> + struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> +
> + /*
> + * Revision in table header is the FADT Major version,
> + * and there is a minor version of FADT which was introduced
> + * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
> + * to get arm boot flags, or we will disable ACPI.
> + */
> + if ( table->revision < 5 || fadt->minor_version < 1 ) {
> + printk("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
> + table->revision, fadt->minor_version);
> + acpi_psci_present = 0;
> + disable_acpi();
> + return -EINVAL;
> + }
> +
> + if ( acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT )
> + acpi_psci_present = 1;
> +
> + if ( acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC )
> + acpi_psci_use_hvc = 1;
> +
> + return 0;
> +}
> +
> /*
> * acpi_boot_table_init() called from setup_arch(), always.
> * 1. find RSDP and get its address, and then find XSDT
> @@ -81,12 +115,12 @@ int __init acpi_boot_table_init(void)
> {
> int error;
> /* If acpi_disabled, bail out */
> - if (acpi_disabled)
> + if ( acpi_disabled )
> return 1;
>
> /* Initialize the ACPI boot-time table parser. */
> error = acpi_table_init();
> - if (error)
> + if ( error )
> {
> disable_acpi();
> return error;
> @@ -94,4 +128,18 @@ int __init acpi_boot_table_init(void)
>
> return 0;
> }
> +
> +int __init acpi_boot_init(void)
> +{
> + int err = 0;
> + /* If acpi_disabled, bail out */
> + if (acpi_disabled)
> + return -ENODEV;
> +
> + err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
> + if ( err )
> + printk("Can't find FADT\n");
> +
> + return err;
> +}
> #endif
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 7ae126b..3531d47 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -749,6 +749,7 @@ void __init start_xen(unsigned long boot_phys_offset,
>
> #if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
> acpi_boot_table_init();
> + acpi_boot_init();
> #endif
>
> dt_unflatten_host_device_tree();
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> index f6284b5..03051ef 100644
> --- a/xen/include/asm-arm/acpi.h
> +++ b/xen/include/asm-arm/acpi.h
> @@ -60,6 +60,8 @@ extern int acpi_disabled;
> extern int acpi_noirq;
> extern int acpi_pci_disabled;
> extern int acpi_strict;
> +extern int acpi_psci_present;
> +extern int acpi_psci_use_hvc;
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 05/35] ARM64 / ACPI: Parse FADT table to get PSCI flags
2015-02-04 17:45 ` Stefano Stabellini
@ 2015-02-05 3:56 ` Hanjun Guo
2015-02-05 11:09 ` Ian Campbell
1 sibling, 0 replies; 166+ messages in thread
From: Hanjun Guo @ 2015-02-05 3:56 UTC (permalink / raw)
To: Stefano Stabellini, parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, jbeulich, christoffer.dall
On 2015年02月05日 01:45, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
>> From: Naresh Bhat <naresh.bhat@linaro.org>
>>
>> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
>> the former signals to the OS that the hardware is PSCI compliant.
>> The latter selects the appropriate conduit for PSCI calls by
>> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
>> (SMC).
>>
>> FADT table contains such information, parse FADT to get the flags
>> for furture usage. At the same time, only ACPI 5.1 or higher verison
>> supports PSCI, and FADT Major.Minor version was introduced in ACPI
>> 5.1, so we will check the version and only parse FADT table with
>> version >= 5.1.
>>
>> If firmware provides ACPI tables with ACPI version less than 5.1,
>> OS will be messed up with those information, so disable ACPI if we
>> get an FADT table with version less that 5.1.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
>> ---
>> xen/arch/arm/arm64/acpi/arm-core.c | 54 +++++++++++++++++++++++++++++++++++---
>> xen/arch/arm/setup.c | 1 +
>> xen/include/asm-arm/acpi.h | 2 ++
>> 3 files changed, 54 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
>> index 50a83d6..2b7e2ef 100644
>> --- a/xen/arch/arm/arm64/acpi/arm-core.c
>> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
>> @@ -25,6 +25,7 @@
>> #if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>> #include <xen/init.h>
>> #include <xen/acpi.h>
>> +#include <xen/errno.h>
>>
>> #include <asm/acpi.h>
>>
>> @@ -42,6 +43,12 @@ EXPORT_SYMBOL(acpi_disabled);
>> int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
>> EXPORT_SYMBOL(acpi_pci_disabled);
>>
>> +/* 1 to indicate PSCI is implemented */
>> +int acpi_psci_present;
>> +
>> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>> +int acpi_psci_use_hvc;
> Can they be static?
> Also it might be better to define an enum with values: PSCI_ABSENT, PSCI_HVC, PSCI_SMC.
This patch was changed a lot in the latest v8 patch set, I introduced
two static inline function in the head file to replace those two
variables.
Thanks
Hanjun
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 05/35] ARM64 / ACPI: Parse FADT table to get PSCI flags
2015-02-04 17:45 ` Stefano Stabellini
2015-02-05 3:56 ` Hanjun Guo
@ 2015-02-05 11:09 ` Ian Campbell
1 sibling, 0 replies; 166+ messages in thread
From: Ian Campbell @ 2015-02-05 11:09 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Naresh Bhat, julien.grall, tim, xen-devel, stefano.stabellini,
Hanjun Guo, jbeulich, parth.dixit, christoffer.dall
On Wed, 2015-02-04 at 17:45 +0000, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> > From: Naresh Bhat <naresh.bhat@linaro.org>
> >
> > There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> > the former signals to the OS that the hardware is PSCI compliant.
> > The latter selects the appropriate conduit for PSCI calls by
> > toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> > (SMC).
> >
> > FADT table contains such information, parse FADT to get the flags
> > for furture usage. At the same time, only ACPI 5.1 or higher verison
> > supports PSCI, and FADT Major.Minor version was introduced in ACPI
> > 5.1, so we will check the version and only parse FADT table with
> > version >= 5.1.
> >
> > If firmware provides ACPI tables with ACPI version less than 5.1,
> > OS will be messed up with those information, so disable ACPI if we
> > get an FADT table with version less that 5.1.
> >
> > Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> > Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> > ---
> > xen/arch/arm/arm64/acpi/arm-core.c | 54 +++++++++++++++++++++++++++++++++++---
> > xen/arch/arm/setup.c | 1 +
> > xen/include/asm-arm/acpi.h | 2 ++
> > 3 files changed, 54 insertions(+), 3 deletions(-)
> >
> > diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> > index 50a83d6..2b7e2ef 100644
> > --- a/xen/arch/arm/arm64/acpi/arm-core.c
> > +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> > @@ -25,6 +25,7 @@
> > #if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> > #include <xen/init.h>
> > #include <xen/acpi.h>
> > +#include <xen/errno.h>
> >
> > #include <asm/acpi.h>
> >
> > @@ -42,6 +43,12 @@ EXPORT_SYMBOL(acpi_disabled);
> > int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
> > EXPORT_SYMBOL(acpi_pci_disabled);
> >
> > +/* 1 to indicate PSCI is implemented */
> > +int acpi_psci_present;
> > +
> > +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> > +int acpi_psci_use_hvc;
>
> Can they be static?
> Also it might be better to define an enum with values: PSCI_ABSENT, PSCI_HVC, PSCI_SMC.
Why are they even needed in Xen?
The ACPI code should correctly configure the existing psci_ver variable
and any psci_FOO_nr during init.
Since HVC is an impossibility for Xen running on real firmware it should
do as psci_is_smc_method does and bail if HVC is found.
Ian.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 05/35] ARM64 / ACPI: Parse FADT table to get PSCI flags
2015-02-04 14:01 ` [PATCH RFC 05/35] ARM64 / ACPI: Parse FADT table to get PSCI flags parth.dixit
2015-02-04 17:45 ` Stefano Stabellini
@ 2015-02-04 21:14 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-04 21:14 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, stefano.stabellini, Hanjun Guo,
jbeulich, christoffer.dall
Hi Parth,
On 04/02/2015 14:01, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> the former signals to the OS that the hardware is PSCI compliant.
> The latter selects the appropriate conduit for PSCI calls by
> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> (SMC).
>
> FADT table contains such information, parse FADT to get the flags
> for furture usage. At the same time, only ACPI 5.1 or higher verison
> supports PSCI, and FADT Major.Minor version was introduced in ACPI
> 5.1, so we will check the version and only parse FADT table with
> version >= 5.1.
>
> If firmware provides ACPI tables with ACPI version less than 5.1,
> OS will be messed up with those information, so disable ACPI if we
> get an FADT table with version less that 5.1.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 54 +++++++++++++++++++++++++++++++++++---
> xen/arch/arm/setup.c | 1 +
> xen/include/asm-arm/acpi.h | 2 ++
> 3 files changed, 54 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index 50a83d6..2b7e2ef 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -25,6 +25,7 @@
> #if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> #include <xen/init.h>
> #include <xen/acpi.h>
> +#include <xen/errno.h>
>
> #include <asm/acpi.h>
>
> @@ -42,6 +43,12 @@ EXPORT_SYMBOL(acpi_disabled);
> int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
> EXPORT_SYMBOL(acpi_pci_disabled);
>
> +/* 1 to indicate PSCI is implemented */
> +int acpi_psci_present;
bool
> +
> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> +int acpi_psci_use_hvc;
bool
> +
> enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
>
> struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
> @@ -58,7 +65,7 @@ EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
> * failure: return =< 0
> */
> //int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
> -unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low)
> +unsigned int acpi_register_gsi(u32 gsi, int edge_level, int active_high_low)
Spurious change.
> {
> return -1;
> }
> @@ -69,6 +76,33 @@ void acpi_unregister_gsi(u32 gsi)
> }
> EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
>
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> + struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> +
> + /*
> + * Revision in table header is the FADT Major version,
> + * and there is a minor version of FADT which was introduced
> + * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
> + * to get arm boot flags, or we will disable ACPI.
> + */
> + if ( table->revision < 5 || fadt->minor_version < 1 ) {
> + printk("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
> + table->revision, fadt->minor_version);
> + acpi_psci_present = 0;
> + disable_acpi();
> + return -EINVAL;
> + }
> +
> + if ( acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT )
> + acpi_psci_present = 1;
You never use this function, so either something is wrong in this
series, or I may have miss a patch... Does SMP boot is supported with
ACPI on Xen? If so, how do you do it? All the PSCI code is based on the
device tree. So by any chance, does Xen still use the DT?
> +
> + if ( acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC )
> + acpi_psci_use_hvc = 1;
This flags should never be enabled when for SMP bring up in the
hypervisor. If it's the case, we should print an error.
> +
> + return 0;
> +}
> +
> /*
> * acpi_boot_table_init() called from setup_arch(), always.
> * 1. find RSDP and get its address, and then find XSDT
> @@ -81,12 +115,12 @@ int __init acpi_boot_table_init(void)
> {
> int error;
> /* If acpi_disabled, bail out */
> - if (acpi_disabled)
> + if ( acpi_disabled )
This coding style change should belong to the patch which add the code
(if I'm not mistaken patch #3).
> return 1;
>
> /* Initialize the ACPI boot-time table parser. */
> error = acpi_table_init();
> - if (error)
> + if ( error )
Ditto.
> {
> disable_acpi();
> return error;
> @@ -94,4 +128,18 @@ int __init acpi_boot_table_init(void)
>
> return 0;
> }
> +
> +int __init acpi_boot_init(void)
> +{
> + int err = 0;
> + /* If acpi_disabled, bail out */
> + if (acpi_disabled)
if ( acpi_disabled )
> + return -ENODEV;
> +
> + err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
> + if ( err )
> + printk("Can't find FADT\n");
> +
> + return err;
> +}
> #endif
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 7ae126b..3531d47 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -749,6 +749,7 @@ void __init start_xen(unsigned long boot_phys_offset,
>
> #if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
> acpi_boot_table_init();
> + acpi_boot_init();
Why didn't you merge the 2 functions? In fine, initialize the table is
part of the boot...
> #endif
>
> dt_unflatten_host_device_tree();
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> index f6284b5..03051ef 100644
> --- a/xen/include/asm-arm/acpi.h
> +++ b/xen/include/asm-arm/acpi.h
> @@ -60,6 +60,8 @@ extern int acpi_disabled;
> extern int acpi_noirq;
> extern int acpi_pci_disabled;
> extern int acpi_strict;
> +extern int acpi_psci_present;
> +extern int acpi_psci_use_hvc;
>
> /* map logic cpu id to physical APIC id
> * APIC = GIC cpu interface on ARM
>
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 06/35] ACPI: Add Generic Interrupt and Distributor struct
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (4 preceding siblings ...)
2015-02-04 14:01 ` [PATCH RFC 05/35] ARM64 / ACPI: Parse FADT table to get PSCI flags parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-04 17:52 ` Stefano Stabellini
2015-02-04 21:16 ` Julien Grall
2015-02-04 14:01 ` [PATCH RFC 07/35] ACPI / ACPICA: Add new features for MADT which introduced by ACPI 5.1 parth.dixit
` (29 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
Add Generic Interrupt and Distributor (ACPI 5.0) structure.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/include/acpi/actbl1.h | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
index 9311e3a..dd6dc27 100644
--- a/xen/include/acpi/actbl1.h
+++ b/xen/include/acpi/actbl1.h
@@ -639,7 +639,9 @@ enum acpi_madt_type {
ACPI_MADT_TYPE_INTERRUPT_SOURCE = 8,
ACPI_MADT_TYPE_LOCAL_X2APIC = 9,
ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
- ACPI_MADT_TYPE_RESERVED = 11 /* 11 and greater are reserved */
+ ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
+ ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
+ ACPI_MADT_TYPE_RESERVED = 13 /* 13 and greater are reserved */
};
/*
@@ -760,6 +762,31 @@ struct acpi_madt_local_x2apic_nmi {
u8 reserved[3];
};
+/* 11: Generic Interrupt (ACPI 5.0) */
+
+struct acpi_madt_generic_interrupt {
+ struct acpi_subtable_header header;
+ u16 reserved; /* reserved - must be zero */
+ u32 gic_id;
+ u32 uid;
+ u32 flags;
+ u32 parking_version;
+ u32 performance_interrupt;
+ u64 parked_address;
+ u64 base_address;
+};
+
+/* 12: Generic Distributor (ACPI 5.0) */
+
+struct acpi_madt_generic_distributor {
+ struct acpi_subtable_header header;
+ u16 reserved; /* reserved - must be zero */
+ u32 gic_id;
+ u64 base_address;
+ u32 global_irq_base;
+ u32 reserved2; /* reserved - must be zero */
+};
+
/*
* Common flags fields for MADT subtables
*/
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 06/35] ACPI: Add Generic Interrupt and Distributor struct
2015-02-04 14:01 ` [PATCH RFC 06/35] ACPI: Add Generic Interrupt and Distributor struct parth.dixit
@ 2015-02-04 17:52 ` Stefano Stabellini
2015-02-04 21:16 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-04 17:52 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Add Generic Interrupt and Distributor (ACPI 5.0) structure.
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/include/acpi/actbl1.h | 29 ++++++++++++++++++++++++++++-
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
> index 9311e3a..dd6dc27 100644
> --- a/xen/include/acpi/actbl1.h
> +++ b/xen/include/acpi/actbl1.h
> @@ -639,7 +639,9 @@ enum acpi_madt_type {
> ACPI_MADT_TYPE_INTERRUPT_SOURCE = 8,
> ACPI_MADT_TYPE_LOCAL_X2APIC = 9,
> ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
> - ACPI_MADT_TYPE_RESERVED = 11 /* 11 and greater are reserved */
> + ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
> + ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
> + ACPI_MADT_TYPE_RESERVED = 13 /* 13 and greater are reserved */
You might as well define the GICv2m and GICR types
> };
>
> /*
> @@ -760,6 +762,31 @@ struct acpi_madt_local_x2apic_nmi {
> u8 reserved[3];
> };
>
> +/* 11: Generic Interrupt (ACPI 5.0) */
Why not use the 5.1 struct?
> +struct acpi_madt_generic_interrupt {
acpi_madt_gicc?
> + struct acpi_subtable_header header;
> + u16 reserved; /* reserved - must be zero */
> + u32 gic_id;
> + u32 uid;
> + u32 flags;
> + u32 parking_version;
> + u32 performance_interrupt;
> + u64 parked_address;
> + u64 base_address;
> +};
> +
> +/* 12: Generic Distributor (ACPI 5.0) */
Why not use the most recent version here too?
> +struct acpi_madt_generic_distributor {
acpi_madt_gicd?
> + struct acpi_subtable_header header;
> + u16 reserved; /* reserved - must be zero */
> + u32 gic_id;
> + u64 base_address;
> + u32 global_irq_base;
> + u32 reserved2; /* reserved - must be zero */
> +};
> +
> /*
> * Common flags fields for MADT subtables
> */
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 06/35] ACPI: Add Generic Interrupt and Distributor struct
2015-02-04 14:01 ` [PATCH RFC 06/35] ACPI: Add Generic Interrupt and Distributor struct parth.dixit
2015-02-04 17:52 ` Stefano Stabellini
@ 2015-02-04 21:16 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-04 21:16 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, stefano.stabellini, jbeulich,
christoffer.dall
Hi Parth,
On 04/02/2015 14:01, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Add Generic Interrupt and Distributor (ACPI 5.0) structure.
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/include/acpi/actbl1.h | 29 ++++++++++++++++++++++++++++-
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
> index 9311e3a..dd6dc27 100644
> --- a/xen/include/acpi/actbl1.h
> +++ b/xen/include/acpi/actbl1.h
> @@ -639,7 +639,9 @@ enum acpi_madt_type {
> ACPI_MADT_TYPE_INTERRUPT_SOURCE = 8,
> ACPI_MADT_TYPE_LOCAL_X2APIC = 9,
> ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
> - ACPI_MADT_TYPE_RESERVED = 11 /* 11 and greater are reserved */
> + ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
> + ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
> + ACPI_MADT_TYPE_RESERVED = 13 /* 13 and greater are reserved */
> };
>
> /*
> @@ -760,6 +762,31 @@ struct acpi_madt_local_x2apic_nmi {
> u8 reserved[3];
> };
>
> +/* 11: Generic Interrupt (ACPI 5.0) */
> +
> +struct acpi_madt_generic_interrupt {
> + struct acpi_subtable_header header;
> + u16 reserved; /* reserved - must be zero */
> + u32 gic_id;
> + u32 uid;
> + u32 flags;
> + u32 parking_version;
> + u32 performance_interrupt;
> + u64 parked_address;
> + u64 base_address;
> +};
> +
> +/* 12: Generic Distributor (ACPI 5.0) */
> +
> +struct acpi_madt_generic_distributor {
> + struct acpi_subtable_header header;
> + u16 reserved; /* reserved - must be zero */
> + u32 gic_id;
> + u64 base_address;
> + u32 global_irq_base;
> + u32 reserved2; /* reserved - must be zero */
> +};
> +
This file is using tablutation rather than space for indent
> /*
> * Common flags fields for MADT subtables
> */
>
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 07/35] ACPI / ACPICA: Add new features for MADT which introduced by ACPI 5.1
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (5 preceding siblings ...)
2015-02-04 14:01 ` [PATCH RFC 06/35] ACPI: Add Generic Interrupt and Distributor struct parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-04 17:52 ` Stefano Stabellini
2015-02-08 14:27 ` Tomasz Nowicki
2015-02-04 14:01 ` [PATCH RFC 08/35] ACPI / table: Print GIC information when MADT is parsed parth.dixit
` (28 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, Tomasz Nowicki,
stefano.stabellini, Hanjun Guo, jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
Add new features for MADT which introduced by ACPI 5.1:
-comment on the GIC ID field of the GIC structure which is replaced
by CPU Interface Number.
-add new fields: Redistributor Base Address, GICV, GICH, and MPIDR.
-add new structures for GIC MSI frame and GICR.
-add flag definition for GICC flags.
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/include/acpi/actbl1.h | 38 ++++++++++++++++++++++++++++++++++----
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
index dd6dc27..d16670d 100644
--- a/xen/include/acpi/actbl1.h
+++ b/xen/include/acpi/actbl1.h
@@ -641,7 +641,9 @@ enum acpi_madt_type {
ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
- ACPI_MADT_TYPE_RESERVED = 13 /* 13 and greater are reserved */
+ ACPI_MADT_TYPE_GIC_MSI_FRAME = 13,
+ ACPI_MADT_TYPE_GIC_REDISTRIBUTOR = 14,
+ ACPI_MADT_TYPE_RESERVED = 15 /* 15 and greater are reserved */
};
/*
@@ -762,18 +764,23 @@ struct acpi_madt_local_x2apic_nmi {
u8 reserved[3];
};
-/* 11: Generic Interrupt (ACPI 5.0) */
+/* 11: Generic Interrupt (ACPI 5.1) */
struct acpi_madt_generic_interrupt {
struct acpi_subtable_header header;
u16 reserved; /* reserved - must be zero */
- u32 gic_id;
+ u32 gic_id; /* it was renamed to cpu interface number in ACPI 5.1 */
u32 uid;
u32 flags;
u32 parking_version;
u32 performance_interrupt;
u64 parked_address;
u64 base_address;
+ u64 gicv_base_address;
+ u64 gich_base_address;
+ u32 vgic_maintenance_interrupt;
+ u64 redist_base_address;
+ u64 mpidr;
};
/* 12: Generic Distributor (ACPI 5.0) */
@@ -787,14 +794,37 @@ struct acpi_madt_generic_distributor {
u32 reserved2; /* reserved - must be zero */
};
+/* 13: GIC MSI Frame (ACPI 5.1) */
+
+struct acpi_madt_gic_msi_frame {
+ struct acpi_subtable_header header;
+ u16 reserved; /* reserved - must be zero */
+ u32 gic_msi_frame_id;
+ u64 base_address;
+};
+
+/* 14: GIC Redistributor (ACPI 5.1) */
+
+struct acpi_madt_gic_redistributor {
+ struct acpi_subtable_header header;
+ u16 reserved; /* reserved - must be zero */
+ u64 base_address;
+ u32 region_size;
+};
+
/*
* Common flags fields for MADT subtables
*/
-/* MADT Local APIC flags (lapic_flags) */
+/* MADT Local APIC flags (lapic_flags) and GICC flags */
#define ACPI_MADT_ENABLED (1) /* 00: Processor is usable if set */
+/* MADT GICC flags only */
+
+#define ACPI_MADT_PERF_INT_MODE (1<<1) /* 01: Performance Interrupt Mode */
+#define ACPI_MADT_VGIC (1<<2) /* 02: VGIC Maintenance interrupt mode */
+
/* MADT MPS INTI flags (inti_flags) */
#define ACPI_MADT_POLARITY_MASK (3) /* 00-01: Polarity of APIC I/O input signals */
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 07/35] ACPI / ACPICA: Add new features for MADT which introduced by ACPI 5.1
2015-02-04 14:01 ` [PATCH RFC 07/35] ACPI / ACPICA: Add new features for MADT which introduced by ACPI 5.1 parth.dixit
@ 2015-02-04 17:52 ` Stefano Stabellini
2015-02-08 14:27 ` Tomasz Nowicki
1 sibling, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-04 17:52 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, Tomasz Nowicki,
xen-devel, stefano.stabellini, Hanjun Guo, jbeulich,
christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Add new features for MADT which introduced by ACPI 5.1:
> -comment on the GIC ID field of the GIC structure which is replaced
> by CPU Interface Number.
> -add new fields: Redistributor Base Address, GICV, GICH, and MPIDR.
> -add new structures for GIC MSI frame and GICR.
> -add flag definition for GICC flags.
>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
I see. I think you can safely merge this patch with the previous one.
> xen/include/acpi/actbl1.h | 38 ++++++++++++++++++++++++++++++++++----
> 1 file changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
> index dd6dc27..d16670d 100644
> --- a/xen/include/acpi/actbl1.h
> +++ b/xen/include/acpi/actbl1.h
> @@ -641,7 +641,9 @@ enum acpi_madt_type {
> ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
> ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
> ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
> - ACPI_MADT_TYPE_RESERVED = 13 /* 13 and greater are reserved */
> + ACPI_MADT_TYPE_GIC_MSI_FRAME = 13,
> + ACPI_MADT_TYPE_GIC_REDISTRIBUTOR = 14,
> + ACPI_MADT_TYPE_RESERVED = 15 /* 15 and greater are reserved */
> };
>
> /*
> @@ -762,18 +764,23 @@ struct acpi_madt_local_x2apic_nmi {
> u8 reserved[3];
> };
>
> -/* 11: Generic Interrupt (ACPI 5.0) */
> +/* 11: Generic Interrupt (ACPI 5.1) */
>
> struct acpi_madt_generic_interrupt {
> struct acpi_subtable_header header;
> u16 reserved; /* reserved - must be zero */
> - u32 gic_id;
> + u32 gic_id; /* it was renamed to cpu interface number in ACPI 5.1 */
> u32 uid;
> u32 flags;
> u32 parking_version;
> u32 performance_interrupt;
> u64 parked_address;
> u64 base_address;
> + u64 gicv_base_address;
> + u64 gich_base_address;
> + u32 vgic_maintenance_interrupt;
> + u64 redist_base_address;
> + u64 mpidr;
> };
>
> /* 12: Generic Distributor (ACPI 5.0) */
> @@ -787,14 +794,37 @@ struct acpi_madt_generic_distributor {
> u32 reserved2; /* reserved - must be zero */
> };
>
> +/* 13: GIC MSI Frame (ACPI 5.1) */
> +
> +struct acpi_madt_gic_msi_frame {
> + struct acpi_subtable_header header;
> + u16 reserved; /* reserved - must be zero */
> + u32 gic_msi_frame_id;
> + u64 base_address;
> +};
> +
> +/* 14: GIC Redistributor (ACPI 5.1) */
> +
> +struct acpi_madt_gic_redistributor {
> + struct acpi_subtable_header header;
> + u16 reserved; /* reserved - must be zero */
> + u64 base_address;
> + u32 region_size;
> +};
> +
> /*
> * Common flags fields for MADT subtables
> */
>
> -/* MADT Local APIC flags (lapic_flags) */
> +/* MADT Local APIC flags (lapic_flags) and GICC flags */
>
> #define ACPI_MADT_ENABLED (1) /* 00: Processor is usable if set */
>
> +/* MADT GICC flags only */
> +
> +#define ACPI_MADT_PERF_INT_MODE (1<<1) /* 01: Performance Interrupt Mode */
> +#define ACPI_MADT_VGIC (1<<2) /* 02: VGIC Maintenance interrupt mode */
> +
> /* MADT MPS INTI flags (inti_flags) */
>
> #define ACPI_MADT_POLARITY_MASK (3) /* 00-01: Polarity of APIC I/O input signals */
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 07/35] ACPI / ACPICA: Add new features for MADT which introduced by ACPI 5.1
2015-02-04 14:01 ` [PATCH RFC 07/35] ACPI / ACPICA: Add new features for MADT which introduced by ACPI 5.1 parth.dixit
2015-02-04 17:52 ` Stefano Stabellini
@ 2015-02-08 14:27 ` Tomasz Nowicki
1 sibling, 0 replies; 166+ messages in thread
From: Tomasz Nowicki @ 2015-02-08 14:27 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
Hanjun Guo, jbeulich, christoffer.dall
Hi Parth,
I see lots of old code where some of the issues were already solved in
latest one. Can you please rebase your patches on top of latest ACPI
core set and compose xen specific patches as separate? That would
simplify review process and allows to see the delta.
Regards,
Tomasz
On 02/04/2015 10:01 PM, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Add new features for MADT which introduced by ACPI 5.1:
> -comment on the GIC ID field of the GIC structure which is replaced
> by CPU Interface Number.
> -add new fields: Redistributor Base Address, GICV, GICH, and MPIDR.
> -add new structures for GIC MSI frame and GICR.
> -add flag definition for GICC flags.
>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/include/acpi/actbl1.h | 38 ++++++++++++++++++++++++++++++++++----
> 1 file changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
> index dd6dc27..d16670d 100644
> --- a/xen/include/acpi/actbl1.h
> +++ b/xen/include/acpi/actbl1.h
> @@ -641,7 +641,9 @@ enum acpi_madt_type {
> ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
> ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
> ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
> - ACPI_MADT_TYPE_RESERVED = 13 /* 13 and greater are reserved */
> + ACPI_MADT_TYPE_GIC_MSI_FRAME = 13,
> + ACPI_MADT_TYPE_GIC_REDISTRIBUTOR = 14,
> + ACPI_MADT_TYPE_RESERVED = 15 /* 15 and greater are reserved */
> };
>
> /*
> @@ -762,18 +764,23 @@ struct acpi_madt_local_x2apic_nmi {
> u8 reserved[3];
> };
>
> -/* 11: Generic Interrupt (ACPI 5.0) */
> +/* 11: Generic Interrupt (ACPI 5.1) */
>
> struct acpi_madt_generic_interrupt {
> struct acpi_subtable_header header;
> u16 reserved; /* reserved - must be zero */
> - u32 gic_id;
> + u32 gic_id; /* it was renamed to cpu interface number in ACPI 5.1 */
> u32 uid;
> u32 flags;
> u32 parking_version;
> u32 performance_interrupt;
> u64 parked_address;
> u64 base_address;
> + u64 gicv_base_address;
> + u64 gich_base_address;
> + u32 vgic_maintenance_interrupt;
> + u64 redist_base_address;
> + u64 mpidr;
> };
>
> /* 12: Generic Distributor (ACPI 5.0) */
> @@ -787,14 +794,37 @@ struct acpi_madt_generic_distributor {
> u32 reserved2; /* reserved - must be zero */
> };
>
> +/* 13: GIC MSI Frame (ACPI 5.1) */
> +
> +struct acpi_madt_gic_msi_frame {
> + struct acpi_subtable_header header;
> + u16 reserved; /* reserved - must be zero */
> + u32 gic_msi_frame_id;
> + u64 base_address;
> +};
> +
> +/* 14: GIC Redistributor (ACPI 5.1) */
> +
> +struct acpi_madt_gic_redistributor {
> + struct acpi_subtable_header header;
> + u16 reserved; /* reserved - must be zero */
> + u64 base_address;
> + u32 region_size;
> +};
> +
> /*
> * Common flags fields for MADT subtables
> */
>
> -/* MADT Local APIC flags (lapic_flags) */
> +/* MADT Local APIC flags (lapic_flags) and GICC flags */
>
> #define ACPI_MADT_ENABLED (1) /* 00: Processor is usable if set */
>
> +/* MADT GICC flags only */
> +
> +#define ACPI_MADT_PERF_INT_MODE (1<<1) /* 01: Performance Interrupt Mode */
> +#define ACPI_MADT_VGIC (1<<2) /* 02: VGIC Maintenance interrupt mode */
> +
> /* MADT MPS INTI flags (inti_flags) */
>
> #define ACPI_MADT_POLARITY_MASK (3) /* 00-01: Polarity of APIC I/O input signals */
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 08/35] ACPI / table: Print GIC information when MADT is parsed
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (6 preceding siblings ...)
2015-02-04 14:01 ` [PATCH RFC 07/35] ACPI / ACPICA: Add new features for MADT which introduced by ACPI 5.1 parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-04 14:01 ` [PATCH RFC 09/35] Add cpumask_next_zero set_cpu_present and possible parth.dixit
` (27 subsequent siblings)
35 siblings, 0 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, Tomasz Nowicki,
stefano.stabellini, Hanjun Guo, jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
When MADT is parsed, print GIC information to make the boot
log look pretty.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/drivers/acpi/tables.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index 1beca79..6754933 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -190,6 +190,45 @@ void __init acpi_table_print_madt_entry(struct acpi_subtable_header *header)
}
break;
+ case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
+ {
+ struct acpi_madt_generic_interrupt *p =
+ (struct acpi_madt_generic_interrupt *)header;
+ printk(KERN_INFO PREFIX
+ "GIC (acpi_id[0x%04x] gic_id[0x%04x] %s)\n",
+ p->uid, p->gic_id,
+ (p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
+ }
+ break;
+
+ case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
+ {
+ struct acpi_madt_generic_distributor *p =
+ (struct acpi_madt_generic_distributor *)header;
+ printk(KERN_INFO PREFIX
+ "GIC Distributor (id[0x%04x] address[0x%08llx] gsi_base[%d])\n",
+ p->gic_id, (long long unsigned int)p->base_address, p->global_irq_base);
+ }
+ break;
+
+ case ACPI_MADT_TYPE_GIC_MSI_FRAME:
+ {
+ struct acpi_madt_gic_msi_frame *p =
+ (struct acpi_madt_gic_msi_frame *)header;
+ printk("GIC MSI Frame (address[0x%08llx] msi_fame_id[%d])\n",
+ (long long unsigned int)p->base_address, p->gic_msi_frame_id);
+ }
+ break;
+
+ case ACPI_MADT_TYPE_GIC_REDISTRIBUTOR:
+ {
+ struct acpi_madt_gic_redistributor *p =
+ (struct acpi_madt_gic_redistributor *)header;
+ printk("GIC Redistributor (address[0x%08llx] region_size[0x%x])\n",
+ (long long unsigned int)p->base_address, p->region_size);
+ }
+ break;
+
default:
printk(KERN_WARNING PREFIX
"Found unsupported MADT entry (type = %#x)\n",
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* [PATCH RFC 09/35] Add cpumask_next_zero set_cpu_present and possible
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (7 preceding siblings ...)
2015-02-04 14:01 ` [PATCH RFC 08/35] ACPI / table: Print GIC information when MADT is parsed parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-04 18:47 ` Stefano Stabellini
2015-02-04 21:28 ` Julien Grall
2015-02-04 14:01 ` [PATCH RFC 10/35] asm / arm: Introduce cputype.h parth.dixit
` (26 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
Introduce and use cpumask_next_zero, set_cpu_present and set_cpu_possible.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/common/cpu.c | 18 ++++++++++++++++++
xen/include/xen/cpumask.h | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+)
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 630881e..da399c9 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -216,3 +216,21 @@ void enable_nonboot_cpus(void)
cpumask_clear(&frozen_cpus);
}
+
+static DECLARE_BITMAP(cpu_present_bits, NR_CPUS) __read_mostly;
+static DECLARE_BITMAP(cpu_possible_bits, NR_CPUS) __read_mostly;
+void set_cpu_possible(unsigned int cpu, bool possible)
+{
+ if ( possible )
+ cpumask_set_cpu(cpu, to_cpumask(cpu_possible_bits));
+ else
+ cpumask_clear_cpu(cpu, to_cpumask(cpu_possible_bits));
+}
+
+void set_cpu_present(unsigned int cpu, bool present)
+{
+ if ( present )
+ cpumask_set_cpu(cpu, to_cpumask(cpu_present_bits));
+ else
+ cpumask_clear_cpu(cpu, to_cpumask(cpu_present_bits));
+}
diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
index 850b4a2..209483e 100644
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -78,6 +78,7 @@
#include <xen/bitmap.h>
#include <xen/kernel.h>
#include <xen/random.h>
+#include <xen/stdbool.h>
typedef struct cpumask{ DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
@@ -295,6 +296,22 @@ static inline int cpulist_scnprintf(char *buf, int len,
}
/*
+ * cpumask_next_zero - get the next unset cpu in a cpumask
+ * @n: the cpu prior to the place to search (ie. return will be > @n)
+ * @srcp: the cpumask pointer
+ *
+ * Returns >= nr_cpu_ids if no further cpus unset.
+ */
+static inline unsigned int cpumask_next_zero(int n, const cpumask_t *srcp)
+{
+ /* -1 is a legal arg here. */
+ if (n != -1)
+ cpumask_check(n);
+
+ return find_next_zero_bit(srcp->bits, nr_cpu_ids, n+1);
+}
+
+/*
* cpumask_var_t: struct cpumask for stack usage.
*
* Oh, the wicked games we play! In order to make kernel coding a
@@ -440,6 +457,29 @@ extern cpumask_t cpu_present_map;
#define for_each_online_cpu(cpu) for_each_cpu(cpu, &cpu_online_map)
#define for_each_present_cpu(cpu) for_each_cpu(cpu, &cpu_present_map)
+/* Wrappers for arch boot code to manipulate normally-constant masks */
+void set_cpu_possible(unsigned int cpu, bool possible);
+void set_cpu_present(unsigned int cpu, bool present);
+
+/*
+ * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
+ * @bitmap: the bitmap
+ *
+ * There are a few places where cpumask_var_t isn't appropriate and
+ * static cpumasks must be used (eg. very early boot), yet we don't
+ * expose the definition of 'struct cpumask'.
+ *
+ * This does the conversion, and can be used as a constant initializer.
+ */
+#define to_cpumask(bitmap) \
+ ((struct cpumask *)(1 ? (bitmap) \
+ : (void *)sizeof(__check_is_bitmap(bitmap))))
+
+static inline int __check_is_bitmap(const unsigned long *bitmap)
+{
+ return 1;
+}
+
/* Copy to/from cpumap provided by control tools. */
struct xenctl_bitmap;
int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *, const cpumask_t *);
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 09/35] Add cpumask_next_zero set_cpu_present and possible
2015-02-04 14:01 ` [PATCH RFC 09/35] Add cpumask_next_zero set_cpu_present and possible parth.dixit
@ 2015-02-04 18:47 ` Stefano Stabellini
2015-02-05 11:47 ` Jan Beulich
2015-02-04 21:28 ` Julien Grall
1 sibling, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-04 18:47 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Introduce and use cpumask_next_zero, set_cpu_present and set_cpu_possible.
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/common/cpu.c | 18 ++++++++++++++++++
> xen/include/xen/cpumask.h | 40 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 58 insertions(+)
>
> diff --git a/xen/common/cpu.c b/xen/common/cpu.c
> index 630881e..da399c9 100644
> --- a/xen/common/cpu.c
> +++ b/xen/common/cpu.c
> @@ -216,3 +216,21 @@ void enable_nonboot_cpus(void)
>
> cpumask_clear(&frozen_cpus);
> }
> +
> +static DECLARE_BITMAP(cpu_present_bits, NR_CPUS) __read_mostly;
We already have cpu_present_map on both x86 and ARM.
Does it make sense to use that instead?
> +static DECLARE_BITMAP(cpu_possible_bits, NR_CPUS) __read_mostly;
ARM already has cpu_possible_map. x86 seems to be able to cope with
having ACPI without this map.
If you want to introduce it, you should explain why x86 needs this map.
> +void set_cpu_possible(unsigned int cpu, bool possible)
> +{
> + if ( possible )
> + cpumask_set_cpu(cpu, to_cpumask(cpu_possible_bits));
> + else
> + cpumask_clear_cpu(cpu, to_cpumask(cpu_possible_bits));
> +}
> +
> +void set_cpu_present(unsigned int cpu, bool present)
> +{
> + if ( present )
> + cpumask_set_cpu(cpu, to_cpumask(cpu_present_bits));
> + else
> + cpumask_clear_cpu(cpu, to_cpumask(cpu_present_bits));
> +}
> diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
> index 850b4a2..209483e 100644
> --- a/xen/include/xen/cpumask.h
> +++ b/xen/include/xen/cpumask.h
> @@ -78,6 +78,7 @@
> #include <xen/bitmap.h>
> #include <xen/kernel.h>
> #include <xen/random.h>
> +#include <xen/stdbool.h>
>
> typedef struct cpumask{ DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
>
> @@ -295,6 +296,22 @@ static inline int cpulist_scnprintf(char *buf, int len,
> }
>
> /*
> + * cpumask_next_zero - get the next unset cpu in a cpumask
> + * @n: the cpu prior to the place to search (ie. return will be > @n)
> + * @srcp: the cpumask pointer
> + *
> + * Returns >= nr_cpu_ids if no further cpus unset.
> + */
> +static inline unsigned int cpumask_next_zero(int n, const cpumask_t *srcp)
> +{
> + /* -1 is a legal arg here. */
> + if (n != -1)
> + cpumask_check(n);
> +
> + return find_next_zero_bit(srcp->bits, nr_cpu_ids, n+1);
return min_t(int, nr_cpu_ids, find_next_zero_bit(srcp->bits, nr_cpu_ids, n + 1));
> +}
> +
> +/*
> * cpumask_var_t: struct cpumask for stack usage.
> *
> * Oh, the wicked games we play! In order to make kernel coding a
> @@ -440,6 +457,29 @@ extern cpumask_t cpu_present_map;
> #define for_each_online_cpu(cpu) for_each_cpu(cpu, &cpu_online_map)
> #define for_each_present_cpu(cpu) for_each_cpu(cpu, &cpu_present_map)
>
> +/* Wrappers for arch boot code to manipulate normally-constant masks */
> +void set_cpu_possible(unsigned int cpu, bool possible);
> +void set_cpu_present(unsigned int cpu, bool present);
> +
> +/*
> + * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
> + * @bitmap: the bitmap
> + *
> + * There are a few places where cpumask_var_t isn't appropriate and
> + * static cpumasks must be used (eg. very early boot), yet we don't
> + * expose the definition of 'struct cpumask'.
> + *
> + * This does the conversion, and can be used as a constant initializer.
> + */
> +#define to_cpumask(bitmap) \
> + ((struct cpumask *)(1 ? (bitmap) \
it doesn't make sense to me
> + : (void *)sizeof(__check_is_bitmap(bitmap))))
> +
> +static inline int __check_is_bitmap(const unsigned long *bitmap)
> +{
> + return 1;
> +}
What is the purpose of this?
> /* Copy to/from cpumap provided by control tools. */
> struct xenctl_bitmap;
> int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *, const cpumask_t *);
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 09/35] Add cpumask_next_zero set_cpu_present and possible
2015-02-04 18:47 ` Stefano Stabellini
@ 2015-02-05 11:47 ` Jan Beulich
0 siblings, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-05 11:47 UTC (permalink / raw)
To: Stefano.Stabellini, Stefano Stabellini, parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
christoffer.dall
>>> On 04.02.15 at 19:47, <stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
>> +static DECLARE_BITMAP(cpu_possible_bits, NR_CPUS) __read_mostly;
>
> ARM already has cpu_possible_map. x86 seems to be able to cope with
> having ACPI without this map.
>
> If you want to introduce it, you should explain why x86 needs this map.
The more that we specifically got rid of it a few years back.
>> @@ -295,6 +296,22 @@ static inline int cpulist_scnprintf(char *buf, int len,
>> }
>>
>> /*
>> + * cpumask_next_zero - get the next unset cpu in a cpumask
>> + * @n: the cpu prior to the place to search (ie. return will be > @n)
>> + * @srcp: the cpumask pointer
>> + *
>> + * Returns >= nr_cpu_ids if no further cpus unset.
>> + */
>> +static inline unsigned int cpumask_next_zero(int n, const cpumask_t *srcp)
>> +{
>> + /* -1 is a legal arg here. */
>> + if (n != -1)
>> + cpumask_check(n);
>> +
>> + return find_next_zero_bit(srcp->bits, nr_cpu_ids, n+1);
>
> return min_t(int, nr_cpu_ids, find_next_zero_bit(srcp->bits, nr_cpu_ids, n + 1));
For one certainly not "int" when the function returns "unsigned int".
And then I don't see the need for the min() in the first place. Callers
ought to check < or >= nr_cpu_ids anyway. E.g. I'd rather see this
dropped from cpumask_next() and cpumask_first() too, fixing
eventual callers making wrong assumptions (like cpumask_cycle()).
Jan
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 09/35] Add cpumask_next_zero set_cpu_present and possible
2015-02-04 14:01 ` [PATCH RFC 09/35] Add cpumask_next_zero set_cpu_present and possible parth.dixit
2015-02-04 18:47 ` Stefano Stabellini
@ 2015-02-04 21:28 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-04 21:28 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, stefano.stabellini, jbeulich,
christoffer.dall
Hi Parth,
On 04/02/2015 14:01, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Introduce and use cpumask_next_zero, set_cpu_present and set_cpu_possible.
Why don't you use cpu_possible_map, cpu_present_map?
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/common/cpu.c | 18 ++++++++++++++++++
> xen/include/xen/cpumask.h | 40 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 58 insertions(+)
>
> diff --git a/xen/common/cpu.c b/xen/common/cpu.c
> index 630881e..da399c9 100644
> --- a/xen/common/cpu.c
> +++ b/xen/common/cpu.c
> @@ -216,3 +216,21 @@ void enable_nonboot_cpus(void)
>
> cpumask_clear(&frozen_cpus);
> }
> +
> +static DECLARE_BITMAP(cpu_present_bits, NR_CPUS) __read_mostly;
> +static DECLARE_BITMAP(cpu_possible_bits, NR_CPUS) __read_mostly;
> +void set_cpu_possible(unsigned int cpu, bool possible)
> +{
> + if ( possible )
> + cpumask_set_cpu(cpu, to_cpumask(cpu_possible_bits));
> + else
> + cpumask_clear_cpu(cpu, to_cpumask(cpu_possible_bits));
> +}
> +
> +void set_cpu_present(unsigned int cpu, bool present)
> +{
> + if ( present )
> + cpumask_set_cpu(cpu, to_cpumask(cpu_present_bits));
> + else
> + cpumask_clear_cpu(cpu, to_cpumask(cpu_present_bits));
> +}
What's the purpose of declaring two bitmaps but never use them?
> diff --git a/xen/include/xen/cpumask.h b/xen/include/xen/cpumask.h
> index 850b4a2..209483e 100644
> --- a/xen/include/xen/cpumask.h
> +++ b/xen/include/xen/cpumask.h
> @@ -78,6 +78,7 @@
> #include <xen/bitmap.h>
> #include <xen/kernel.h>
> #include <xen/random.h>
> +#include <xen/stdbool.h>
Please don't include stdbool.h and use bool_t instead (defined in types.h)
>
> typedef struct cpumask{ DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
>
> @@ -295,6 +296,22 @@ static inline int cpulist_scnprintf(char *buf, int len,
> }
>
> /*
> + * cpumask_next_zero - get the next unset cpu in a cpumask
> + * @n: the cpu prior to the place to search (ie. return will be > @n)
> + * @srcp: the cpumask pointer
> + *
> + * Returns >= nr_cpu_ids if no further cpus unset.
> + */
> +static inline unsigned int cpumask_next_zero(int n, const cpumask_t *srcp)
> +{
> + /* -1 is a legal arg here. */
> + if (n != -1)
> + cpumask_check(n);
> +
> + return find_next_zero_bit(srcp->bits, nr_cpu_ids, n+1);
> +}
> +
> +/*
> * cpumask_var_t: struct cpumask for stack usage.
> *
> * Oh, the wicked games we play! In order to make kernel coding a
> @@ -440,6 +457,29 @@ extern cpumask_t cpu_present_map;
> #define for_each_online_cpu(cpu) for_each_cpu(cpu, &cpu_online_map)
> #define for_each_present_cpu(cpu) for_each_cpu(cpu, &cpu_present_map)
>
> +/* Wrappers for arch boot code to manipulate normally-constant masks */
> +void set_cpu_possible(unsigned int cpu, bool possible);
> +void set_cpu_present(unsigned int cpu, bool present);
> +
> +/*
> + * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
> + * @bitmap: the bitmap
> + *
> + * There are a few places where cpumask_var_t isn't appropriate and
> + * static cpumasks must be used (eg. very early boot), yet we don't
> + * expose the definition of 'struct cpumask'.
> + *
> + * This does the conversion, and can be used as a constant initializer.
> + */
> +#define to_cpumask(bitmap) \
> + ((struct cpumask *)(1 ? (bitmap) \
> + : (void *)sizeof(__check_is_bitmap(bitmap))))
> +
> +static inline int __check_is_bitmap(const unsigned long *bitmap)
> +{
> + return 1;
> +}
> +
> /* Copy to/from cpumap provided by control tools. */
> struct xenctl_bitmap;
> int cpumask_to_xenctl_bitmap(struct xenctl_bitmap *, const cpumask_t *);
>
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 10/35] asm / arm: Introduce cputype.h
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (8 preceding siblings ...)
2015-02-04 14:01 ` [PATCH RFC 09/35] Add cpumask_next_zero set_cpu_present and possible parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-04 18:56 ` Stefano Stabellini
2015-02-04 21:33 ` Julien Grall
2015-02-04 14:01 ` [PATCH RFC 11/35] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map parth.dixit
` (25 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
Introduce cputype.h file for arm
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/include/asm-arm/cputype.h | 83 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 83 insertions(+)
create mode 100644 xen/include/asm-arm/cputype.h
diff --git a/xen/include/asm-arm/cputype.h b/xen/include/asm-arm/cputype.h
new file mode 100644
index 0000000..0b454cc
--- /dev/null
+++ b/xen/include/asm-arm/cputype.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef __ASM_CPUTYPE_H
+#define __ASM_CPUTYPE_H
+
+#include <asm/processor.h>
+
+#define INVALID_HWID ULONG_MAX
+
+#define MPIDR_HWID_BITMASK 0xff00ffffff
+
+#define MPIDR_LEVEL_BITS_SHIFT 3
+#define MPIDR_LEVEL_MASK ((1 << MPIDR_LEVEL_BITS) - 1)
+
+#define MPIDR_LEVEL_SHIFT(level) \
+ (((1 << level) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
+
+#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
+ ((mpidr >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
+
+#define read_cpuid(reg) ({ \
+ u64 __val; \
+ asm("mrs %0, " #reg : "=r" (__val)); \
+ __val; \
+})
+
+#define ARM_CPU_IMP_ARM 0x41
+#define ARM_CPU_IMP_APM 0x50
+
+#define ARM_CPU_PART_AEM_V8 0xD0F0
+#define ARM_CPU_PART_FOUNDATION 0xD000
+#define ARM_CPU_PART_CORTEX_A57 0xD070
+
+#define APM_CPU_PART_POTENZA 0x0000
+
+#ifndef __ASSEMBLY__
+
+/*
+ * The CPU ID never changes at run time, so we might as well tell the
+ * compiler that it's constant. Use this function to read the CPU ID
+ * rather than directly reading processor_id or read_cpuid() directly.
+ */
+static inline u32 __attribute_const__ read_cpuid_id(void)
+{
+ return read_cpuid(MIDR_EL1);
+}
+
+static inline u64 __attribute_const__ read_cpuid_mpidr(void)
+{
+ return read_cpuid(MPIDR_EL1);
+}
+
+static inline unsigned int __attribute_const__ read_cpuid_implementor(void)
+{
+ return (read_cpuid_id() & 0xFF000000) >> 24;
+}
+
+static inline unsigned int __attribute_const__ read_cpuid_part_number(void)
+{
+ return (read_cpuid_id() & 0xFFF0);
+}
+
+static inline u32 __attribute_const__ read_cpuid_cachetype(void)
+{
+ return read_cpuid(CTR_EL0);
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 10/35] asm / arm: Introduce cputype.h
2015-02-04 14:01 ` [PATCH RFC 10/35] asm / arm: Introduce cputype.h parth.dixit
@ 2015-02-04 18:56 ` Stefano Stabellini
2015-02-04 21:33 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-04 18:56 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Introduce cputype.h file for arm
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/include/asm-arm/cputype.h | 83 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 83 insertions(+)
> create mode 100644 xen/include/asm-arm/cputype.h
>
> diff --git a/xen/include/asm-arm/cputype.h b/xen/include/asm-arm/cputype.h
> new file mode 100644
> index 0000000..0b454cc
> --- /dev/null
> +++ b/xen/include/asm-arm/cputype.h
> @@ -0,0 +1,83 @@
> +/*
> + * Copyright (C) 2012 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +#ifndef __ASM_CPUTYPE_H
> +#define __ASM_CPUTYPE_H
> +
> +#include <asm/processor.h>
> +
> +#define INVALID_HWID ULONG_MAX
> +
> +#define MPIDR_HWID_BITMASK 0xff00ffffff
> +
> +#define MPIDR_LEVEL_BITS_SHIFT 3
> +#define MPIDR_LEVEL_MASK ((1 << MPIDR_LEVEL_BITS) - 1)
> +
> +#define MPIDR_LEVEL_SHIFT(level) \
> + (((1 << level) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
> +
> +#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
> + ((mpidr >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
You shouldn't duplicate the definitions in processor.h.
If you want to move them to this file, then please remove them from
processor.h.
> +#define read_cpuid(reg) ({ \
> + u64 __val; \
> + asm("mrs %0, " #reg : "=r" (__val)); \
> + __val; \
> +})
> +
> +#define ARM_CPU_IMP_ARM 0x41
> +#define ARM_CPU_IMP_APM 0x50
> +
> +#define ARM_CPU_PART_AEM_V8 0xD0F0
> +#define ARM_CPU_PART_FOUNDATION 0xD000
> +#define ARM_CPU_PART_CORTEX_A57 0xD070
> +
> +#define APM_CPU_PART_POTENZA 0x0000
> +
> +#ifndef __ASSEMBLY__
> +
> +/*
> + * The CPU ID never changes at run time, so we might as well tell the
> + * compiler that it's constant. Use this function to read the CPU ID
> + * rather than directly reading processor_id or read_cpuid() directly.
> + */
> +static inline u32 __attribute_const__ read_cpuid_id(void)
> +{
> + return read_cpuid(MIDR_EL1);
> +}
> +
> +static inline u64 __attribute_const__ read_cpuid_mpidr(void)
> +{
> + return read_cpuid(MPIDR_EL1);
> +}
> +
> +static inline unsigned int __attribute_const__ read_cpuid_implementor(void)
> +{
> + return (read_cpuid_id() & 0xFF000000) >> 24;
> +}
> +
> +static inline unsigned int __attribute_const__ read_cpuid_part_number(void)
> +{
> + return (read_cpuid_id() & 0xFFF0);
> +}
> +
> +static inline u32 __attribute_const__ read_cpuid_cachetype(void)
> +{
> + return read_cpuid(CTR_EL0);
> +}
We already read mpidr and midr in identify_cpu. Isn't that enough?
Can't you just reuse the info in struct cpuinfo_arm?
> +#endif /* __ASSEMBLY__ */
> +
> +#endif
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 10/35] asm / arm: Introduce cputype.h
2015-02-04 14:01 ` [PATCH RFC 10/35] asm / arm: Introduce cputype.h parth.dixit
2015-02-04 18:56 ` Stefano Stabellini
@ 2015-02-04 21:33 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-04 21:33 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, stefano.stabellini, jbeulich,
christoffer.dall
Hi Parth,
On 04/02/2015 14:01, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Introduce cputype.h file for arm
Most of the defines introduced already exists in asm-arm/processor.h
If you really want a separate file, which I don't think it's necessary,
please drop the defines in asm-arm/processor.h
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/include/asm-arm/cputype.h | 83 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 83 insertions(+)
> create mode 100644 xen/include/asm-arm/cputype.h
>
> diff --git a/xen/include/asm-arm/cputype.h b/xen/include/asm-arm/cputype.h
> new file mode 100644
> index 0000000..0b454cc
> --- /dev/null
> +++ b/xen/include/asm-arm/cputype.h
> @@ -0,0 +1,83 @@
> +/*
> + * Copyright (C) 2012 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +#ifndef __ASM_CPUTYPE_H
> +#define __ASM_CPUTYPE_H
> +
> +#include <asm/processor.h>
> +
> +#define INVALID_HWID ULONG_MAX
> +
> +#define MPIDR_HWID_BITMASK 0xff00ffffff
> +
> +#define MPIDR_LEVEL_BITS_SHIFT 3
> +#define MPIDR_LEVEL_MASK ((1 << MPIDR_LEVEL_BITS) - 1)
> +
> +#define MPIDR_LEVEL_SHIFT(level) \
> + (((1 << level) >> 1) << MPIDR_LEVEL_BITS_SHIFT)
> +
> +#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
> + ((mpidr >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
> +
> +#define read_cpuid(reg) ({ \
> + u64 __val; \
> + asm("mrs %0, " #reg : "=r" (__val)); \
> + __val; \
> +})
This is ARM64 specific, this will never work on ARM32.
> +#define ARM_CPU_IMP_ARM 0x41
> +#define ARM_CPU_IMP_APM 0x50
> +
> +#define ARM_CPU_PART_AEM_V8 0xD0F0
> +#define ARM_CPU_PART_FOUNDATION 0xD000
> +#define ARM_CPU_PART_CORTEX_A57 0xD070
> +
> +#define APM_CPU_PART_POTENZA 0x0000
Why thoses define?
> +#ifndef __ASSEMBLY__
> +
> +/*
> + * The CPU ID never changes at run time, so we might as well tell the
> + * compiler that it's constant. Use this function to read the CPU ID
> + * rather than directly reading processor_id or read_cpuid() directly.
> + */
> +static inline u32 __attribute_const__ read_cpuid_id(void)
> +{
> + return read_cpuid(MIDR_EL1);
> +}
> +
> +static inline u64 __attribute_const__ read_cpuid_mpidr(void)
> +{
> + return read_cpuid(MPIDR_EL1);
> +}
> +
> +static inline unsigned int __attribute_const__ read_cpuid_implementor(void)
> +{
> + return (read_cpuid_id() & 0xFF000000) >> 24;
> +}
> +
> +static inline unsigned int __attribute_const__ read_cpuid_part_number(void)
> +{
> + return (read_cpuid_id() & 0xFFF0);
> +}
> +
> +static inline u32 __attribute_const__ read_cpuid_cachetype(void)
> +{
> + return read_cpuid(CTR_EL0);
> +}
Rather than introducing helpers which will only work for ARM64, please
use READ_SYSREG(...). See usage in arch/arm/smpboot.c
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 11/35] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (9 preceding siblings ...)
2015-02-04 14:01 ` [PATCH RFC 10/35] asm / arm: Introduce cputype.h parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-04 21:44 ` Julien Grall
2015-02-04 14:01 ` [PATCH RFC 12/35] ARM64: Initialization of cpu_logical_map(0) parth.dixit
` (24 subsequent siblings)
35 siblings, 1 reply; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, Tomasz Nowicki,
stefano.stabellini, Hanjun Guo, jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
MADT contains the information for MPIDR which is essential for
SMP initialization, parse the GIC cpu interface structures to
get the MPIDR value and map it to cpu_logical_map(), and add
enabled cpu with valid MPIDR into cpu_possible_map and
cpu_present_map.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/arch/arm/arm64/acpi/arm-core.c | 139 +++++++++++++++++++++++++++++++++++++
xen/include/asm-arm/acpi.h | 2 +
xen/include/xen/acpi.h | 5 ++
3 files changed, 146 insertions(+)
diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
index 2b7e2ef..84b0032 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -26,7 +26,10 @@
#include <xen/init.h>
#include <xen/acpi.h>
#include <xen/errno.h>
+#include <xen/stdbool.h>
+#include <xen/cpumask.h>
+#include <asm/cputype.h>
#include <asm/acpi.h>
/*
@@ -49,10 +52,141 @@ int acpi_psci_present;
/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
int acpi_psci_use_hvc;
+/* available_cpus means enabled cpu in MADT */
+static int available_cpus;
+
enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
+/* arch-optional setting to enable display of offline cpus >= nr_cpu_ids */
+unsigned int total_cpus = 0;
+
+/*
+ * acpi_register_gic_cpu_interface - register a gic cpu interface and
+ * generates a logic cpu number
+ * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
+ * @enabled: this cpu is enabled or not
+ *
+ * Returns the logic cpu number which maps to the gic cpu interface
+ */
+static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)
+{
+ int cpu;
+
+ if ( mpidr == INVALID_HWID )
+ {
+ printk("Skip invalid cpu hardware ID\n");
+ return -EINVAL;
+ }
+
+ total_cpus++;
+ if ( !enabled )
+ return -EINVAL;
+
+ if ( available_cpus >= NR_CPUS )
+ {
+ printk("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
+ NR_CPUS, total_cpus, (long long unsigned int)mpidr);
+ return -EINVAL;
+ }
+
+ /* If it is the first CPU, no need to check duplicate MPIDRs */
+ if ( !available_cpus )
+ goto skip_mpidr_check;
+
+ /*
+ * Duplicate MPIDRs are a recipe for disaster. Scan
+ * all initialized entries and check for
+ * duplicates. If any is found just ignore the CPU.
+ */
+ for_each_present_cpu(cpu)
+ {
+ if ( cpu_logical_map(cpu) == mpidr )
+ {
+ printk("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
+ (long long unsigned int)mpidr);
+ return -EINVAL;
+ }
+ }
+
+skip_mpidr_check:
+ available_cpus++;
+
+ /* allocate a logic cpu id for the new comer */
+ if ( cpu_logical_map(0) == mpidr )
+ {
+ /*
+ * boot_cpu_init() already hold bit 0 in cpu_present_mask
+ * for BSP, no need to allocte again.
+ */
+ cpu = 0;
+ }
+ else
+ cpu = cpumask_next_zero(-1, &cpu_present_map);
+
+ /* map the logic cpu id to cpu MPIDR */
+ cpu_logical_map(cpu) = mpidr;
+
+ set_cpu_possible(cpu, true);
+ set_cpu_present(cpu, true);
+
+ return cpu;
+}
+
+static int __init
+acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+ struct acpi_madt_generic_interrupt *processor;
+
+ processor = (struct acpi_madt_generic_interrupt *)header;
+
+ if ( BAD_MADT_ENTRY(processor, end) )
+ return -EINVAL;
+
+ acpi_table_print_madt_entry(header);
+
+ acpi_register_gic_cpu_interface(processor->mpidr,
+ processor->flags & ACPI_MADT_ENABLED);
+
+ return 0;
+}
+
+/*
+ * Parse GIC cpu interface related entries in MADT
+ * returns 0 on success, < 0 on error
+ */
+static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
+{
+ int count;
+
+ /*
+ * do a partial walk of MADT to determine how many CPUs
+ * we have including disabled CPUs, and get information
+ * we need for SMP init
+ */
+ count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+ acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
+
+ if ( !count )
+ {
+ printk("No GIC CPU interface entries present\n");
+ return -ENODEV;
+ }
+ else if ( count < 0 )
+ {
+ printk("Error parsing GIC CPU interface entry\n");
+ return count;
+ }
+
+ /* Make boot-up look pretty */
+ printk("%d CPUs available, %d CPUs total\n", available_cpus,
+ total_cpus);
+
+ return 0;
+}
+
int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
{
*irq = -1;
@@ -140,6 +274,11 @@ int __init acpi_boot_init(void)
if ( err )
printk("Can't find FADT\n");
+ /* Get the boot CPU's MPIDR before MADT parsing */
+ cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
+
+ err = acpi_parse_madt_gic_cpu_interface_entries();
+
return err;
}
#endif
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 03051ef..c2d25db 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -105,4 +105,6 @@ static inline void acpi_disable_pci(void)
#define acpi_strict 1 /* no ACPI spec workarounds on ARM */
#endif
+#define MAX_GIC_CPU_INTERFACE 65535
+
#endif /*_ASM_ARM_ACPI_H*/
diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
index ff96336..9387b36 100644
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -67,6 +67,11 @@ typedef int (*acpi_table_handler) (struct acpi_table_header *table);
typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header, const unsigned long end);
unsigned int acpi_get_processor_id (unsigned int cpu);
+
+#define BAD_MADT_ENTRY(entry, end) ( \
+ (!entry) || (unsigned long)entry + sizeof(*entry) > end || \
+ ((struct acpi_subtable_header *)entry)->length < sizeof(*entry))
+
char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
int acpi_boot_init (void);
int acpi_boot_table_init (void);
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 11/35] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map
2015-02-04 14:01 ` [PATCH RFC 11/35] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map parth.dixit
@ 2015-02-04 21:44 ` Julien Grall
0 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-04 21:44 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, Tomasz Nowicki,
stefano.stabellini, Hanjun Guo, jbeulich, christoffer.dall
Hi Parth,
On 04/02/2015 14:01, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_map and
> cpu_present_map.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 139 +++++++++++++++++++++++++++++++++++++
> xen/include/asm-arm/acpi.h | 2 +
> xen/include/xen/acpi.h | 5 ++
> 3 files changed, 146 insertions(+)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index 2b7e2ef..84b0032 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -26,7 +26,10 @@
> #include <xen/init.h>
> #include <xen/acpi.h>
> #include <xen/errno.h>
> +#include <xen/stdbool.h>
> +#include <xen/cpumask.h>
>
> +#include <asm/cputype.h>
> #include <asm/acpi.h>
>
> /*
> @@ -49,10 +52,141 @@ int acpi_psci_present;
> /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> int acpi_psci_use_hvc;
>
> +/* available_cpus means enabled cpu in MADT */
> +static int available_cpus;
> +
Why adding available_cpus here, and total_cpus a bit below?
> enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
>
> struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
>
> +/* arch-optional setting to enable display of offline cpus >= nr_cpu_ids */
> +unsigned int total_cpus = 0;
Set but never used, neither exported...
> +/*
> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
> + * generates a logic cpu number
> + * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
> + * @enabled: this cpu is enabled or not
> + *
> + * Returns the logic cpu number which maps to the gic cpu interface
> + */
> +static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)
> +{
> + int cpu;
> +
> + if ( mpidr == INVALID_HWID )
> + {
> + printk("Skip invalid cpu hardware ID\n");
> + return -EINVAL;
> + }
> +
> + total_cpus++;
> + if ( !enabled )
> + return -EINVAL;
> +
> + if ( available_cpus >= NR_CPUS )
> + {
> + printk("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
> + NR_CPUS, total_cpus, (long long unsigned int)mpidr);
Why the (long long unsigned int) cast? Please use PRIx64.
> + return -EINVAL;
> + }
> +
> + /* If it is the first CPU, no need to check duplicate MPIDRs */
> + if ( !available_cpus )
> + goto skip_mpidr_check;
I don't think it's necessary, for_each_present_cpu should not contain
the first CPU...
> +
> + /*
> + * Duplicate MPIDRs are a recipe for disaster. Scan
> + * all initialized entries and check for
> + * duplicates. If any is found just ignore the CPU.
> + */
> + for_each_present_cpu(cpu)
> + {
> + if ( cpu_logical_map(cpu) == mpidr )
> + {
> + printk("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
> + (long long unsigned int)mpidr);
Ditto for the cast.
> + return -EINVAL;
> + }
> + }
> +
> +skip_mpidr_check:
> + available_cpus++;
> +
> + /* allocate a logic cpu id for the new comer */
> + if ( cpu_logical_map(0) == mpidr )
> + {
> + /*
> + * boot_cpu_init() already hold bit 0 in cpu_present_mask
> + * for BSP, no need to allocte again.
allocate
> + */
> + cpu = 0;
> + }
> + else
> + cpu = cpumask_next_zero(-1, &cpu_present_map);
> +
> + /* map the logic cpu id to cpu MPIDR */
> + cpu_logical_map(cpu) = mpidr;
> +
> + set_cpu_possible(cpu, true);
> + set_cpu_present(cpu, true);
> +
> + return cpu;
> +}
> +
> +static int __init
> +acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_interrupt *processor;
> +
> + processor = (struct acpi_madt_generic_interrupt *)header;
> +
> + if ( BAD_MADT_ENTRY(processor, end) )
> + return -EINVAL;
> +
> + acpi_table_print_madt_entry(header);
> +
> + acpi_register_gic_cpu_interface(processor->mpidr,
> + processor->flags & ACPI_MADT_ENABLED);
> +
> + return 0;
> +}
> +
> +/*
> + * Parse GIC cpu interface related entries in MADT
> + * returns 0 on success, < 0 on error
> + */
> +static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
> +{
> + int count;
> +
> + /*
> + * do a partial walk of MADT to determine how many CPUs
> + * we have including disabled CPUs, and get information
> + * we need for SMP init
> + */
> + count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
> + acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
> +
> + if ( !count )
> + {
> + printk("No GIC CPU interface entries present\n");
> + return -ENODEV;
> + }
> + else if ( count < 0 )
> + {
> + printk("Error parsing GIC CPU interface entry\n");
> + return count;
> + }
> +
> + /* Make boot-up look pretty */
> + printk("%d CPUs available, %d CPUs total\n", available_cpus,
> + total_cpus);
> +
> + return 0;
> +}
> +
> int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
> {
> *irq = -1;
> @@ -140,6 +274,11 @@ int __init acpi_boot_init(void)
> if ( err )
> printk("Can't find FADT\n");
If we don't find the FADT, we should give up rather than trying to parse
the GIC ACPI table.
>
> + /* Get the boot CPU's MPIDR before MADT parsing */
> + cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> +
> + err = acpi_parse_madt_gic_cpu_interface_entries();
> +
> return err;
> }
> #endif
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> index 03051ef..c2d25db 100644
> --- a/xen/include/asm-arm/acpi.h
> +++ b/xen/include/asm-arm/acpi.h
> @@ -105,4 +105,6 @@ static inline void acpi_disable_pci(void)
> #define acpi_strict 1 /* no ACPI spec workarounds on ARM */
> #endif
>
> +#define MAX_GIC_CPU_INTERFACE 65535
> +
> #endif /*_ASM_ARM_ACPI_H*/
> diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
> index ff96336..9387b36 100644
> --- a/xen/include/xen/acpi.h
> +++ b/xen/include/xen/acpi.h
> @@ -67,6 +67,11 @@ typedef int (*acpi_table_handler) (struct acpi_table_header *table);
> typedef int (*acpi_table_entry_handler) (struct acpi_subtable_header *header, const unsigned long end);
>
> unsigned int acpi_get_processor_id (unsigned int cpu);
> +
> +#define BAD_MADT_ENTRY(entry, end) ( \
> + (!entry) || (unsigned long)entry + sizeof(*entry) > end || \
> + ((struct acpi_subtable_header *)entry)->length < sizeof(*entry))
> +
IHMO, this should belong to a separate patch.
> char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
> int acpi_boot_init (void);
> int acpi_boot_table_init (void);
>
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 12/35] ARM64: Initialization of cpu_logical_map(0)
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (10 preceding siblings ...)
2015-02-04 14:01 ` [PATCH RFC 11/35] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-04 21:45 ` Julien Grall
2015-02-05 10:26 ` Stefano Stabellini
2015-02-04 14:01 ` [PATCH RFC 13/35] ACPI: Introduce acpi_parse_entries parth.dixit
` (23 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
Hanjun Guo, jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
Initialization of cpu_logical_map(0) before acpi_boot_init()
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Naresh Bhat <Naresh.Bhat@linaro.org>
---
xen/arch/arm/setup.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 3531d47..569b2da 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -47,6 +47,7 @@
#include <xsm/xsm.h>
#include <xen/acpi.h>
#include <asm/acpi.h>
+#include <asm-arm/cputype.h>
struct bootinfo __initdata bootinfo;
@@ -749,6 +750,10 @@ void __init start_xen(unsigned long boot_phys_offset,
#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
acpi_boot_table_init();
+
+ /* Get the boot CPU's MPIDR before cpu logical map is built */
+ cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
+
acpi_boot_init();
#endif
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 12/35] ARM64: Initialization of cpu_logical_map(0)
2015-02-04 14:01 ` [PATCH RFC 12/35] ARM64: Initialization of cpu_logical_map(0) parth.dixit
@ 2015-02-04 21:45 ` Julien Grall
2015-02-05 10:26 ` Stefano Stabellini
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-04 21:45 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, stefano.stabellini, Hanjun Guo,
jbeulich, christoffer.dall
Hi Parth,
On 04/02/2015 14:01, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Initialization of cpu_logical_map(0) before acpi_boot_init()
Perhaps, merging with the previous patch?
Regards,
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <Naresh.Bhat@linaro.org>
> ---
> xen/arch/arm/setup.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 3531d47..569b2da 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -47,6 +47,7 @@
> #include <xsm/xsm.h>
> #include <xen/acpi.h>
> #include <asm/acpi.h>
> +#include <asm-arm/cputype.h>
>
> struct bootinfo __initdata bootinfo;
>
> @@ -749,6 +750,10 @@ void __init start_xen(unsigned long boot_phys_offset,
>
> #if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
> acpi_boot_table_init();
> +
> + /* Get the boot CPU's MPIDR before cpu logical map is built */
> + cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> +
> acpi_boot_init();
> #endif
>
>
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 12/35] ARM64: Initialization of cpu_logical_map(0)
2015-02-04 14:01 ` [PATCH RFC 12/35] ARM64: Initialization of cpu_logical_map(0) parth.dixit
2015-02-04 21:45 ` Julien Grall
@ 2015-02-05 10:26 ` Stefano Stabellini
2015-02-11 5:09 ` Julien Grall
1 sibling, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 10:26 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, Hanjun Guo, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Initialization of cpu_logical_map(0) before acpi_boot_init()
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <Naresh.Bhat@linaro.org>
> ---
> xen/arch/arm/setup.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 3531d47..569b2da 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -47,6 +47,7 @@
> #include <xsm/xsm.h>
> #include <xen/acpi.h>
> #include <asm/acpi.h>
> +#include <asm-arm/cputype.h>
>
> struct bootinfo __initdata bootinfo;
>
> @@ -749,6 +750,10 @@ void __init start_xen(unsigned long boot_phys_offset,
>
> #if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
> acpi_boot_table_init();
> +
> + /* Get the boot CPU's MPIDR before cpu logical map is built */
> + cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> +
> acpi_boot_init();
> #endif
Isn't the current cpu_logical_map initialization in smp_init_cpus()
enough? If you want to initialize cpu_logical_map earlier, you need to
move the initialization earlier, removing the old one: we cannot have
two places where Xen initialize cpu_logical_map(0).
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 12/35] ARM64: Initialization of cpu_logical_map(0)
2015-02-05 10:26 ` Stefano Stabellini
@ 2015-02-11 5:09 ` Julien Grall
0 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-11 5:09 UTC (permalink / raw)
To: Stefano Stabellini, parth.dixit
Cc: ian.campbell, Naresh Bhat, tim, xen-devel, stefano.stabellini,
Hanjun Guo, jbeulich, christoffer.dall
Hi Stefano,
On 05/02/2015 18:26, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
>> From: Naresh Bhat <naresh.bhat@linaro.org>
>>
>> Initialization of cpu_logical_map(0) before acpi_boot_init()
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Naresh Bhat <Naresh.Bhat@linaro.org>
>> ---
>> xen/arch/arm/setup.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> index 3531d47..569b2da 100644
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -47,6 +47,7 @@
>> #include <xsm/xsm.h>
>> #include <xen/acpi.h>
>> #include <asm/acpi.h>
>> +#include <asm-arm/cputype.h>
>>
>> struct bootinfo __initdata bootinfo;
>>
>> @@ -749,6 +750,10 @@ void __init start_xen(unsigned long boot_phys_offset,
>>
>> #if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
>> acpi_boot_table_init();
>> +
>> + /* Get the boot CPU's MPIDR before cpu logical map is built */
>> + cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>> +
>> acpi_boot_init();
>> #endif
>
> Isn't the current cpu_logical_map initialization in smp_init_cpus()
> enough? If you want to initialize cpu_logical_map earlier, you need to
> move the initialization earlier, removing the old one: we cannot have
> two places where Xen initialize cpu_logical_map(0).
The ACPI is retrieving the CPU in acpi_boot_init (see patch #11). Having
this patch separate made this code difficult to understand.
Although, I don't see why we can't defer the parsing of the CPU table in
smp_init_cpu().
FWIW, it's where we get CPU from the DT.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 13/35] ACPI: Introduce acpi_parse_entries
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (11 preceding siblings ...)
2015-02-04 14:01 ` [PATCH RFC 12/35] ARM64: Initialization of cpu_logical_map(0) parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-05 10:29 ` Stefano Stabellini
2015-02-04 14:01 ` [PATCH RFC 14/35] ACPI / ACPICA: Add GTDT support updated by ACPI 5.1 parth.dixit
` (22 subsequent siblings)
35 siblings, 1 reply; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
Introduce acpi_parse_entries
Signed-off-by: Naresh Bhat <Naresh.Bhat@linaro.org>
---
xen/drivers/acpi/tables.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++
xen/include/xen/acpi.h | 4 +++
2 files changed, 68 insertions(+)
diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index 6754933..5314f0b 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -239,6 +239,70 @@ void __init acpi_table_print_madt_entry(struct acpi_subtable_header *header)
int __init
+acpi_parse_entries(unsigned long table_size,
+ acpi_table_entry_handler handler,
+ struct acpi_table_header *table_header,
+ int entry_id, unsigned int max_entries)
+{
+ struct acpi_subtable_header *entry;
+ int count = 0;
+ unsigned long table_end;
+
+ if (acpi_disabled)
+ return -ENODEV;
+
+ if (!handler)
+ return -EINVAL;
+
+ if (!table_size)
+ return -EINVAL;
+
+ if (!table_header) {
+ printk("Table header not present\n");
+ return -ENODEV;
+ }
+
+ table_end = (unsigned long)table_header + table_header->length;
+
+ /* Parse all entries looking for a match. */
+
+ entry = (struct acpi_subtable_header *)
+ ((unsigned long)table_header + table_size);
+
+ while (((unsigned long)entry) + sizeof(struct acpi_subtable_header) <
+ table_end) {
+ if (entry->type == entry_id
+ && (!max_entries || count++ < max_entries))
+ if (handler(entry, table_end)) {
+ count = -EINVAL;
+ goto err;
+ }
+
+ /*
+ * If entry->length is 0, break from this loop to avoid
+ * infinite loop.
+ */
+ if (entry->length == 0) {
+ printk("[0x%02x] Invalid zero length\n", entry_id);
+ count = -EINVAL;
+ goto err;
+ }
+
+ entry = (struct acpi_subtable_header *)
+ ((unsigned long)entry + entry->length);
+ }
+
+ if (max_entries && count > max_entries) {
+ printk("[0x%02x] ignored %i entries of %i found\n",
+ entry_id, count - max_entries, count);
+ }
+
+err:
+ return count;
+}
+
+
+int __init
acpi_table_parse_entries(char *id,
unsigned long table_size,
int entry_id,
diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
index 9387b36..bf60334 100644
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -81,6 +81,10 @@ void acpi_hest_init(void);
int acpi_table_init (void);
int acpi_table_parse(char *id, acpi_table_handler handler);
+int __init acpi_parse_entries(unsigned long table_size,
+ acpi_table_entry_handler handler,
+ struct acpi_table_header *table_header,
+ int entry_id, unsigned int max_entries);
int acpi_table_parse_entries(char *id, unsigned long table_size,
int entry_id, acpi_table_entry_handler handler, unsigned int max_entries);
int acpi_table_parse_madt(enum acpi_madt_type id, acpi_table_entry_handler handler, unsigned int max_entries);
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 13/35] ACPI: Introduce acpi_parse_entries
2015-02-04 14:01 ` [PATCH RFC 13/35] ACPI: Introduce acpi_parse_entries parth.dixit
@ 2015-02-05 10:29 ` Stefano Stabellini
2015-02-11 5:26 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 10:29 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Introduce acpi_parse_entries
>
> Signed-off-by: Naresh Bhat <Naresh.Bhat@linaro.org>
> ---
> xen/drivers/acpi/tables.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++
> xen/include/xen/acpi.h | 4 +++
> 2 files changed, 68 insertions(+)
>
> diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
> index 6754933..5314f0b 100644
> --- a/xen/drivers/acpi/tables.c
> +++ b/xen/drivers/acpi/tables.c
> @@ -239,6 +239,70 @@ void __init acpi_table_print_madt_entry(struct acpi_subtable_header *header)
>
>
> int __init
> +acpi_parse_entries(unsigned long table_size,
> + acpi_table_entry_handler handler,
> + struct acpi_table_header *table_header,
> + int entry_id, unsigned int max_entries)
> +{
> + struct acpi_subtable_header *entry;
> + int count = 0;
> + unsigned long table_end;
> +
> + if (acpi_disabled)
> + return -ENODEV;
> +
> + if (!handler)
> + return -EINVAL;
> +
> + if (!table_size)
> + return -EINVAL;
> +
> + if (!table_header) {
> + printk("Table header not present\n");
> + return -ENODEV;
> + }
> +
> + table_end = (unsigned long)table_header + table_header->length;
> +
> + /* Parse all entries looking for a match. */
> +
> + entry = (struct acpi_subtable_header *)
> + ((unsigned long)table_header + table_size);
> +
> + while (((unsigned long)entry) + sizeof(struct acpi_subtable_header) <
> + table_end) {
> + if (entry->type == entry_id
> + && (!max_entries || count++ < max_entries))
> + if (handler(entry, table_end)) {
> + count = -EINVAL;
> + goto err;
> + }
> +
> + /*
> + * If entry->length is 0, break from this loop to avoid
> + * infinite loop.
> + */
> + if (entry->length == 0) {
> + printk("[0x%02x] Invalid zero length\n", entry_id);
> + count = -EINVAL;
> + goto err;
> + }
> +
> + entry = (struct acpi_subtable_header *)
> + ((unsigned long)entry + entry->length);
> + }
> +
> + if (max_entries && count > max_entries) {
> + printk("[0x%02x] ignored %i entries of %i found\n",
> + entry_id, count - max_entries, count);
> + }
> +
> +err:
> + return count;
> +}
This function looks remarkably similar to acpi_table_parse_entries
below.
Could you use acpi_table_parse_entries? If not, why?
> +
> +int __init
> acpi_table_parse_entries(char *id,
> unsigned long table_size,
> int entry_id,
> diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
> index 9387b36..bf60334 100644
> --- a/xen/include/xen/acpi.h
> +++ b/xen/include/xen/acpi.h
> @@ -81,6 +81,10 @@ void acpi_hest_init(void);
>
> int acpi_table_init (void);
> int acpi_table_parse(char *id, acpi_table_handler handler);
> +int __init acpi_parse_entries(unsigned long table_size,
> + acpi_table_entry_handler handler,
> + struct acpi_table_header *table_header,
> + int entry_id, unsigned int max_entries);
> int acpi_table_parse_entries(char *id, unsigned long table_size,
> int entry_id, acpi_table_entry_handler handler, unsigned int max_entries);
> int acpi_table_parse_madt(enum acpi_madt_type id, acpi_table_entry_handler handler, unsigned int max_entries);
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 13/35] ACPI: Introduce acpi_parse_entries
2015-02-05 10:29 ` Stefano Stabellini
@ 2015-02-11 5:26 ` Julien Grall
0 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-11 5:26 UTC (permalink / raw)
To: Stefano Stabellini, parth.dixit
Cc: ian.campbell, Naresh Bhat, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
Hi Stefano,
On 05/02/2015 18:29, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
>> From: Naresh Bhat <naresh.bhat@linaro.org>
>>
>> Introduce acpi_parse_entries
>>
>> Signed-off-by: Naresh Bhat <Naresh.Bhat@linaro.org>
>> ---
>> xen/drivers/acpi/tables.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++
>> xen/include/xen/acpi.h | 4 +++
>> 2 files changed, 68 insertions(+)
>>
>> diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
>> index 6754933..5314f0b 100644
>> --- a/xen/drivers/acpi/tables.c
>> +++ b/xen/drivers/acpi/tables.c
>> @@ -239,6 +239,70 @@ void __init acpi_table_print_madt_entry(struct acpi_subtable_header *header)
>>
>>
>> int __init
>> +acpi_parse_entries(unsigned long table_size,
>> + acpi_table_entry_handler handler,
>> + struct acpi_table_header *table_header,
>> + int entry_id, unsigned int max_entries)
>> +{
>> + struct acpi_subtable_header *entry;
>> + int count = 0;
>> + unsigned long table_end;
>> +
>> + if (acpi_disabled)
>> + return -ENODEV;
>> +
>> + if (!handler)
>> + return -EINVAL;
>> +
>> + if (!table_size)
>> + return -EINVAL;
>> +
>> + if (!table_header) {
>> + printk("Table header not present\n");
>> + return -ENODEV;
>> + }
>> +
>> + table_end = (unsigned long)table_header + table_header->length;
>> +
>> + /* Parse all entries looking for a match. */
>> +
>> + entry = (struct acpi_subtable_header *)
>> + ((unsigned long)table_header + table_size);
>> +
>> + while (((unsigned long)entry) + sizeof(struct acpi_subtable_header) <
>> + table_end) {
>> + if (entry->type == entry_id
>> + && (!max_entries || count++ < max_entries))
>> + if (handler(entry, table_end)) {
>> + count = -EINVAL;
>> + goto err;
>> + }
>> +
>> + /*
>> + * If entry->length is 0, break from this loop to avoid
>> + * infinite loop.
>> + */
>> + if (entry->length == 0) {
>> + printk("[0x%02x] Invalid zero length\n", entry_id);
>> + count = -EINVAL;
>> + goto err;
>> + }
>> +
>> + entry = (struct acpi_subtable_header *)
>> + ((unsigned long)entry + entry->length);
>> + }
>> +
>> + if (max_entries && count > max_entries) {
>> + printk("[0x%02x] ignored %i entries of %i found\n",
>> + entry_id, count - max_entries, count);
>> + }
>> +
>> +err:
>> + return count;
>> +}
>
> This function looks remarkably similar to acpi_table_parse_entries
> below.
> Could you use acpi_table_parse_entries? If not, why?
I suspect that we don't even need to refactor the function
acpi_table_parse_entries.
The function acpi_parse_entries in only used for the GICv2 ACPI
initialization.
The current code in the GICv2 is manually doing the work of the
acpi_table_parse_entries. All just for printing the Local ACPI address,
we don't even store it...
If we call acpi_parse_madt, it will make the code more readable by
dropping nearly 30 lines of code, and also dropping this patch.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 14/35] ACPI / ACPICA: Add GTDT support updated by ACPI 5.1
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (12 preceding siblings ...)
2015-02-04 14:01 ` [PATCH RFC 13/35] ACPI: Introduce acpi_parse_entries parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-05 13:22 ` Stefano Stabellini
2015-02-04 14:01 ` [PATCH RFC 15/35] ARM64 / ACPI: Define ACPI_IRQ_MODEL_GIC needed for arm parth.dixit
` (21 subsequent siblings)
35 siblings, 1 reply; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
Hanjun Guo, jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
With ACPI 5.0, we got per-processor timer support in GTDT,
and ACPI 5.1 introduced the support for platform (memory-mapped)
timers: GT Block and SBSA watchdog timer, add the code needed
in this patch.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/include/acpi/actbl3.h | 90 ++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 77 insertions(+), 13 deletions(-)
diff --git a/xen/include/acpi/actbl3.h b/xen/include/acpi/actbl3.h
index 8c61b5f..0d1ff52 100644
--- a/xen/include/acpi/actbl3.h
+++ b/xen/include/acpi/actbl3.h
@@ -241,34 +241,98 @@ struct acpi_s3pt_suspend {
/*******************************************************************************
*
- * GTDT - Generic Timer Description Table (ACPI 5.0)
+ * GTDT - Generic Timer Description Table (ACPI 5.1)
* Version 1
*
******************************************************************************/
struct acpi_table_gtdt {
struct acpi_table_header header; /* Common ACPI table header */
- u64 address;
- u32 flags;
- u32 secure_pl1_interrupt;
- u32 secure_pl1_flags;
- u32 non_secure_pl1_interrupt;
- u32 non_secure_pl1_flags;
+ u64 cnt_control_base_address;
+ u32 reserved;
+ u32 secure_el1_interrupt;
+ u32 secure_el1_flags;
+ u32 non_secure_el1_interrupt;
+ u32 non_secure_el1_flags;
u32 virtual_timer_interrupt;
u32 virtual_timer_flags;
- u32 non_secure_pl2_interrupt;
- u32 non_secure_pl2_flags;
+ u32 non_secure_el2_interrupt;
+ u32 non_secure_el2_flags;
+ u64 cnt_read_base_address;
+ u32 platform_timer_count;
+ u32 platform_timer_offset;
};
-/* Values for Flags field above */
-
-#define ACPI_GTDT_MAPPED_BLOCK_PRESENT 1
-
/* Values for all "TimerFlags" fields above */
#define ACPI_GTDT_INTERRUPT_MODE 1
#define ACPI_GTDT_INTERRUPT_POLARITY 2
+#define ACPI_GTDT_ALWAYS_ON 4
+
+/* Values for GTDT subtable type in struct acpi_subtable_header */
+
+enum acpi_gtdt_type {
+ ACPI_GTDT_TYPE_GT_BLOCK = 0, /* memory-mapped generic timer */
+ ACPI_GTDT_TYPE_SBSA_GENERIC_WATCHDOG = 1,
+ ACPI_GTDT_TYPE_RESERVED = 2 /* 2 and greater are reserved */
+};
+
+/*
+ * GTDT Subtables, correspond to Type in struct acpi_subtable_header
+ */
+
+/* 0: Generic Timer Block */
+
+struct acpi_gtdt_gt_block {
+ struct acpi_subtable_header header;
+ u16 reserved;
+ u64 gt_block_address;
+ u32 gt_block_timer_count; /* must be less than or equal to 8 */
+ u32 gt_block_timer_offset;
+};
+
+/* GT Block Timer Structure */
+
+struct acpi_gt_block_timer {
+ u8 gt_frame_number;
+ u8 reseved[3];
+ u64 cnt_base_address;
+ u64 cnt_el0_base_adress;
+ u32 physical_timer_interrupt;
+ u32 physical_timer_flags;
+ u32 vitual_timer_interrupt;
+ u32 vitual_timer_flags;
+ u32 timer_common_flags;
+};
+
+/* Flag Definitions: GT Block Physical Timers and Virtual timers */
+
+#define ACPI_GT_BLOCK_INTERRUPT_MODE 1
+#define ACPI_GT_BLOCK_INTERRUPT_POLARITY 2
+
+/* Flag Definitions: Common Flags */
+
+#define ACPI_GT_BLOCK_IS_SECURE_TIMER 1
+#define ACPI_GT_BLOCK_ALWAYS_ON 2
+
+/* 1: SBSA Generic Watchdog Structure */
+
+struct acpi_sbsa_generic_watchdog {
+ struct acpi_subtable_header header;
+ u16 reserved;
+ u64 refresh_frame_address;
+ u64 control_frame_address;
+ u32 interrupt;
+ u32 flags;
+};
+
+/* Flag Definitions: SBSA Generic Watchdog */
+
+#define ACPI_SBSA_WATCHDOG_INTERRUPT_MODE 1
+#define ACPI_SBSA_WATCHDOG_INTERRUPT_POLARITY 2
+#define ACPI_SBSA_WATCHDOG_IS_SECURE_TIMER 4
+
/*******************************************************************************
*
* MPST - Memory Power State Table (ACPI 5.0)
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 14/35] ACPI / ACPICA: Add GTDT support updated by ACPI 5.1
2015-02-04 14:01 ` [PATCH RFC 14/35] ACPI / ACPICA: Add GTDT support updated by ACPI 5.1 parth.dixit
@ 2015-02-05 13:22 ` Stefano Stabellini
0 siblings, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 13:22 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, Hanjun Guo, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> With ACPI 5.0, we got per-processor timer support in GTDT,
> and ACPI 5.1 introduced the support for platform (memory-mapped)
> timers: GT Block and SBSA watchdog timer, add the code needed
> in this patch.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/include/acpi/actbl3.h | 90 ++++++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 77 insertions(+), 13 deletions(-)
>
> diff --git a/xen/include/acpi/actbl3.h b/xen/include/acpi/actbl3.h
> index 8c61b5f..0d1ff52 100644
> --- a/xen/include/acpi/actbl3.h
> +++ b/xen/include/acpi/actbl3.h
> @@ -241,34 +241,98 @@ struct acpi_s3pt_suspend {
>
> /*******************************************************************************
> *
> - * GTDT - Generic Timer Description Table (ACPI 5.0)
> + * GTDT - Generic Timer Description Table (ACPI 5.1)
> * Version 1
> *
> ******************************************************************************/
>
> struct acpi_table_gtdt {
> struct acpi_table_header header; /* Common ACPI table header */
> - u64 address;
> - u32 flags;
> - u32 secure_pl1_interrupt;
> - u32 secure_pl1_flags;
> - u32 non_secure_pl1_interrupt;
> - u32 non_secure_pl1_flags;
> + u64 cnt_control_base_address;
> + u32 reserved;
> + u32 secure_el1_interrupt;
> + u32 secure_el1_flags;
> + u32 non_secure_el1_interrupt;
> + u32 non_secure_el1_flags;
> u32 virtual_timer_interrupt;
> u32 virtual_timer_flags;
> - u32 non_secure_pl2_interrupt;
> - u32 non_secure_pl2_flags;
> + u32 non_secure_el2_interrupt;
> + u32 non_secure_el2_flags;
> + u64 cnt_read_base_address;
> + u32 platform_timer_count;
> + u32 platform_timer_offset;
> };
>
> -/* Values for Flags field above */
> -
> -#define ACPI_GTDT_MAPPED_BLOCK_PRESENT 1
> -
> /* Values for all "TimerFlags" fields above */
>
> #define ACPI_GTDT_INTERRUPT_MODE 1
I would prefer if you used the notation (1<<0)
> #define ACPI_GTDT_INTERRUPT_POLARITY 2
^ (1<<1)
> +#define ACPI_GTDT_ALWAYS_ON 4
^ (1<<2)
> +/* Values for GTDT subtable type in struct acpi_subtable_header */
> +
> +enum acpi_gtdt_type {
> + ACPI_GTDT_TYPE_GT_BLOCK = 0, /* memory-mapped generic timer */
> + ACPI_GTDT_TYPE_SBSA_GENERIC_WATCHDOG = 1,
> + ACPI_GTDT_TYPE_RESERVED = 2 /* 2 and greater are reserved */
> +};
> +
> +/*
> + * GTDT Subtables, correspond to Type in struct acpi_subtable_header
> + */
> +
> +/* 0: Generic Timer Block */
> +
> +struct acpi_gtdt_gt_block {
> + struct acpi_subtable_header header;
> + u16 reserved;
> + u64 gt_block_address;
> + u32 gt_block_timer_count; /* must be less than or equal to 8 */
> + u32 gt_block_timer_offset;
> +};
> +
> +/* GT Block Timer Structure */
> +
> +struct acpi_gt_block_timer {
> + u8 gt_frame_number;
> + u8 reseved[3];
> + u64 cnt_base_address;
> + u64 cnt_el0_base_adress;
> + u32 physical_timer_interrupt;
> + u32 physical_timer_flags;
> + u32 vitual_timer_interrupt;
> + u32 vitual_timer_flags;
> + u32 timer_common_flags;
> +};
> +
> +/* Flag Definitions: GT Block Physical Timers and Virtual timers */
> +
> +#define ACPI_GT_BLOCK_INTERRUPT_MODE 1
> +#define ACPI_GT_BLOCK_INTERRUPT_POLARITY 2
same here: (1<<0) and (1<<1)
> +/* Flag Definitions: Common Flags */
> +
> +#define ACPI_GT_BLOCK_IS_SECURE_TIMER 1
> +#define ACPI_GT_BLOCK_ALWAYS_ON 2
same here: (1<<0) and (1<<1)
> +/* 1: SBSA Generic Watchdog Structure */
> +
> +struct acpi_sbsa_generic_watchdog {
> + struct acpi_subtable_header header;
> + u16 reserved;
> + u64 refresh_frame_address;
> + u64 control_frame_address;
> + u32 interrupt;
> + u32 flags;
> +};
> +
> +/* Flag Definitions: SBSA Generic Watchdog */
> +
> +#define ACPI_SBSA_WATCHDOG_INTERRUPT_MODE 1
> +#define ACPI_SBSA_WATCHDOG_INTERRUPT_POLARITY 2
> +#define ACPI_SBSA_WATCHDOG_IS_SECURE_TIMER 4
same here
> /*******************************************************************************
> *
> * MPST - Memory Power State Table (ACPI 5.0)
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 15/35] ARM64 / ACPI: Define ACPI_IRQ_MODEL_GIC needed for arm
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (13 preceding siblings ...)
2015-02-04 14:01 ` [PATCH RFC 14/35] ACPI / ACPICA: Add GTDT support updated by ACPI 5.1 parth.dixit
@ 2015-02-04 14:01 ` parth.dixit
2015-02-05 14:39 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 16/35] ARM64 / ACPI: Parse GTDT to initialize timer parth.dixit
` (20 subsequent siblings)
35 siblings, 1 reply; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:01 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Al Stone, Naresh Bhat, julien.grall, tim,
stefano.stabellini, Hanjun Guo, jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
Needed because ARM64 uses GIC which is defined in ACPI 5.0 spec.
Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/arch/arm/arm64/acpi/arm-core.c | 6 ++-
xen/drivers/acpi/tables.c | 95 ++++++++++++++++++++------------------
2 files changed, 55 insertions(+), 46 deletions(-)
diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
index 84b0032..cc11fce 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -55,7 +55,11 @@ int acpi_psci_use_hvc;
/* available_cpus means enabled cpu in MADT */
static int available_cpus;
-enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
+/*
+ * Since we're on ARM, the default interrupt routing model
+ * clearly has to be GIC.
+ */
+enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_GIC;
struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index 5314f0b..ad680f8 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -244,60 +244,65 @@ acpi_parse_entries(unsigned long table_size,
struct acpi_table_header *table_header,
int entry_id, unsigned int max_entries)
{
- struct acpi_subtable_header *entry;
- int count = 0;
- unsigned long table_end;
+ struct acpi_subtable_header *entry;
+ int count = 0;
+ unsigned long table_end;
- if (acpi_disabled)
- return -ENODEV;
+ if ( acpi_disabled )
+ return -ENODEV;
- if (!handler)
- return -EINVAL;
+ if ( !handler )
+ return -EINVAL;
- if (!table_size)
- return -EINVAL;
+ if ( !table_size )
+ return -EINVAL;
- if (!table_header) {
- printk("Table header not present\n");
- return -ENODEV;
- }
+ if ( !table_header )
+ {
+ printk("Table header not present\n");
+ return -ENODEV;
+ }
- table_end = (unsigned long)table_header + table_header->length;
+ table_end = (unsigned long)table_header + table_header->length;
- /* Parse all entries looking for a match. */
+ /* Parse all entries looking for a match. */
- entry = (struct acpi_subtable_header *)
- ((unsigned long)table_header + table_size);
-
- while (((unsigned long)entry) + sizeof(struct acpi_subtable_header) <
- table_end) {
- if (entry->type == entry_id
- && (!max_entries || count++ < max_entries))
- if (handler(entry, table_end)) {
- count = -EINVAL;
- goto err;
- }
-
- /*
- * If entry->length is 0, break from this loop to avoid
- * infinite loop.
- */
- if (entry->length == 0) {
- printk("[0x%02x] Invalid zero length\n", entry_id);
- count = -EINVAL;
- goto err;
- }
-
- entry = (struct acpi_subtable_header *)
- ((unsigned long)entry + entry->length);
- }
+ entry = (struct acpi_subtable_header *)
+ ((unsigned long)table_header + table_size);
+
+ while ( ( (unsigned long)entry ) + sizeof(struct acpi_subtable_header) <
+ table_end)
+ {
+ if ( entry->type == entry_id
+ && ( !max_entries || count++ < max_entries ) )
+ if ( handler(entry, table_end) )
+ {
+ count = -EINVAL;
+ goto err;
+ }
- if (max_entries && count > max_entries) {
- printk("[0x%02x] ignored %i entries of %i found\n",
- entry_id, count - max_entries, count);
+ /*
+ * If entry->length is 0, break from this loop to avoid
+ * infinite loop.
+ */
+ if ( entry->length == 0 )
+ {
+ printk("[0x%02x] Invalid zero length\n", entry_id);
+ count = -EINVAL;
+ goto err;
}
-err:
+ entry = (struct acpi_subtable_header *)
+ ((unsigned long)entry + entry->length);
+ }
+
+ if ( max_entries && count > max_entries )
+ {
+ printk("[0x%02x] ignored %i entries of %i found\n",
+ entry_id, count - max_entries, count);
+ }
+
+ err:
return count;
}
@@ -394,7 +399,7 @@ int __init acpi_table_parse(char *id, acpi_table_handler handler)
return 1;
}
-/*
+/*
* The BIOS is supposed to supply a single APIC/MADT,
* but some report two. Provide a knob to use either.
* (don't you wish instance 0 and 1 were not the same?)
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 15/35] ARM64 / ACPI: Define ACPI_IRQ_MODEL_GIC needed for arm
2015-02-04 14:01 ` [PATCH RFC 15/35] ARM64 / ACPI: Define ACPI_IRQ_MODEL_GIC needed for arm parth.dixit
@ 2015-02-05 14:39 ` Stefano Stabellini
0 siblings, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 14:39 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Al Stone, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, Hanjun Guo, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Needed because ARM64 uses GIC which is defined in ACPI 5.0 spec.
>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 6 ++-
> xen/drivers/acpi/tables.c | 95 ++++++++++++++++++++------------------
> 2 files changed, 55 insertions(+), 46 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index 84b0032..cc11fce 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -55,7 +55,11 @@ int acpi_psci_use_hvc;
> /* available_cpus means enabled cpu in MADT */
> static int available_cpus;
>
> -enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
> +/*
> + * Since we're on ARM, the default interrupt routing model
> + * clearly has to be GIC.
> + */
> +enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_GIC;
>
> struct acpi_arm_root acpi_arm_rsdp_info; /* info about RSDP from FDT */
>
> diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
> index 5314f0b..ad680f8 100644
> --- a/xen/drivers/acpi/tables.c
> +++ b/xen/drivers/acpi/tables.c
> @@ -244,60 +244,65 @@ acpi_parse_entries(unsigned long table_size,
> struct acpi_table_header *table_header,
> int entry_id, unsigned int max_entries)
> {
> - struct acpi_subtable_header *entry;
> - int count = 0;
> - unsigned long table_end;
> + struct acpi_subtable_header *entry;
> + int count = 0;
> + unsigned long table_end;
>
> - if (acpi_disabled)
> - return -ENODEV;
> + if ( acpi_disabled )
> + return -ENODEV;
>
> - if (!handler)
> - return -EINVAL;
> + if ( !handler )
> + return -EINVAL;
>
> - if (!table_size)
> - return -EINVAL;
> + if ( !table_size )
> + return -EINVAL;
>
> - if (!table_header) {
> - printk("Table header not present\n");
> - return -ENODEV;
> - }
> + if ( !table_header )
> + {
> + printk("Table header not present\n");
> + return -ENODEV;
> + }
>
> - table_end = (unsigned long)table_header + table_header->length;
> + table_end = (unsigned long)table_header + table_header->length;
>
> - /* Parse all entries looking for a match. */
> + /* Parse all entries looking for a match. */
All these changes shouldn't be here.
As you are introducing this function in one of the previous patches, you
should have the indentation right in the first place.
> - entry = (struct acpi_subtable_header *)
> - ((unsigned long)table_header + table_size);
> -
> - while (((unsigned long)entry) + sizeof(struct acpi_subtable_header) <
> - table_end) {
> - if (entry->type == entry_id
> - && (!max_entries || count++ < max_entries))
> - if (handler(entry, table_end)) {
> - count = -EINVAL;
> - goto err;
> - }
> -
> - /*
> - * If entry->length is 0, break from this loop to avoid
> - * infinite loop.
> - */
> - if (entry->length == 0) {
> - printk("[0x%02x] Invalid zero length\n", entry_id);
> - count = -EINVAL;
> - goto err;
> - }
> -
> - entry = (struct acpi_subtable_header *)
> - ((unsigned long)entry + entry->length);
> - }
> + entry = (struct acpi_subtable_header *)
> + ((unsigned long)table_header + table_size);
> +
> + while ( ( (unsigned long)entry ) + sizeof(struct acpi_subtable_header) <
> + table_end)
> + {
> + if ( entry->type == entry_id
> + && ( !max_entries || count++ < max_entries ) )
> + if ( handler(entry, table_end) )
> + {
> + count = -EINVAL;
> + goto err;
> + }
>
> - if (max_entries && count > max_entries) {
> - printk("[0x%02x] ignored %i entries of %i found\n",
> - entry_id, count - max_entries, count);
> + /*
> + * If entry->length is 0, break from this loop to avoid
> + * infinite loop.
> + */
> + if ( entry->length == 0 )
> + {
> + printk("[0x%02x] Invalid zero length\n", entry_id);
> + count = -EINVAL;
> + goto err;
> }
>
> -err:
> + entry = (struct acpi_subtable_header *)
> + ((unsigned long)entry + entry->length);
> + }
> +
> + if ( max_entries && count > max_entries )
> + {
> + printk("[0x%02x] ignored %i entries of %i found\n",
> + entry_id, count - max_entries, count);
> + }
> +
> + err:
> return count;
> }
With all these indentation changes I cannot tell if you made any other
changes in this patch. Please remove all the indentation changes.
> @@ -394,7 +399,7 @@ int __init acpi_table_parse(char *id, acpi_table_handler handler)
> return 1;
> }
>
> -/*
> +/*
> * The BIOS is supposed to supply a single APIC/MADT,
> * but some report two. Provide a knob to use either.
> * (don't you wish instance 0 and 1 were not the same?)
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 16/35] ARM64 / ACPI: Parse GTDT to initialize timer
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (14 preceding siblings ...)
2015-02-04 14:01 ` [PATCH RFC 15/35] ARM64 / ACPI: Define ACPI_IRQ_MODEL_GIC needed for arm parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-04 21:51 ` Julien Grall
2015-02-05 14:46 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table parth.dixit
` (19 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, Parth Dixit, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
Parse GTDT (Generic Timer Descriptor Table) to initialize timer.
Using the information presented by GTDT to initialize the arch
timer (not momery-mapped).
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/arch/arm/setup.c | 6 +++++
xen/arch/arm/time.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++
xen/include/xen/time.h | 1 +
3 files changed, 73 insertions(+)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 569b2da..af9f429 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -775,7 +775,12 @@ void __init start_xen(unsigned long boot_phys_offset,
smp_init_cpus();
cpus = smp_get_max_cpus();
+/* Comment for now take it after GIC initialization */
+#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
+ init_xen_acpi_time();
+#else
init_xen_time();
+#endif
gic_init();
@@ -789,6 +794,7 @@ void __init start_xen(unsigned long boot_phys_offset,
xsm_dt_init();
init_maintenance_interrupt();
+
init_timer_interrupt();
timer_init();
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 0add494..0d4c26d 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -29,6 +29,7 @@
#include <xen/time.h>
#include <xen/sched.h>
#include <xen/event.h>
+#include <xen/acpi.h>
#include <asm/system.h>
#include <asm/time.h>
#include <asm/gic.h>
@@ -239,6 +240,71 @@ struct tm wallclock_time(uint64_t *ns)
return (struct tm) { 0 };
}
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+
+#define ACPI_GTDT_INTR_MASK 0x3
+
+static int GTDT_INTRL_TAB[] ={ DT_IRQ_TYPE_LEVEL_HIGH, DT_IRQ_TYPE_EDGE_RISING,
+ DT_IRQ_TYPE_LEVEL_LOW ,DT_IRQ_TYPE_EDGE_FALLING};
+
+/* Initialize per-processor generic timer */
+static int __init arch_timer_acpi_init(struct acpi_table_header *table)
+{
+ int res;
+ int type;
+ struct acpi_table_gtdt *gtdt;
+
+ gtdt = (struct acpi_table_gtdt *)table;
+
+ /* Initialize all the generic timer IRQ variable from GTDT table */
+
+ type = GTDT_INTRL_TAB[gtdt->non_secure_el1_flags & ACPI_GTDT_INTR_MASK];
+ acpi_set_irq(gtdt->non_secure_el1_interrupt, type);
+ timer_irq[TIMER_PHYS_NONSECURE_PPI] = gtdt->non_secure_el1_interrupt;
+
+ type = GTDT_INTRL_TAB[gtdt->secure_el1_flags & ACPI_GTDT_INTR_MASK];
+ acpi_set_irq(gtdt->secure_el1_interrupt, type);
+ timer_irq[TIMER_PHYS_SECURE_PPI] = gtdt->secure_el1_interrupt;
+
+ type = GTDT_INTRL_TAB[gtdt->non_secure_el2_flags & ACPI_GTDT_INTR_MASK];
+ acpi_set_irq(gtdt->non_secure_el2_interrupt, type);
+ timer_irq[TIMER_HYP_PPI] = gtdt->non_secure_el2_interrupt;
+
+ type = GTDT_INTRL_TAB[gtdt->virtual_timer_flags & ACPI_GTDT_INTR_MASK];
+ acpi_set_irq(gtdt->virtual_timer_interrupt, type);
+ timer_irq[TIMER_VIRT_PPI] = gtdt->virtual_timer_interrupt;
+
+ printk("Generic Timer IRQ from ACPI GTDT: phys=%u hyp=%u virt=%u\n",
+ timer_irq[TIMER_PHYS_NONSECURE_PPI],
+ timer_irq[TIMER_HYP_PPI],
+ timer_irq[TIMER_VIRT_PPI]);
+
+ res = platform_init_time();
+ if ( res )
+ printk("Timer: Cannot initialize platform timer");
+
+ /* Check that this CPU supports the Generic Timer interface */
+ if ( !cpu_has_gentimer )
+ printk("CPU does not support the Generic Timer v1 interface");
+
+ cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
+
+ boot_count = READ_SYSREG64(CNTPCT_EL0);
+
+ printk("Using generic timer at %lu KHz\n", cpu_khz);
+
+ return 0;
+}
+
+int __init init_xen_acpi_time(void)
+{
+ /* Initialize all the generic timers presented in GTDT */
+ acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
+ return 0;
+}
+
+#endif
+
/*
* Local variables:
* mode: C
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index 709501f..4598a0c 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -11,6 +11,7 @@
#include <xen/types.h>
#include <public/xen.h>
+extern int init_xen_acpi_time(void);
extern int init_xen_time(void);
extern void cstate_restore_tsc(void);
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 16/35] ARM64 / ACPI: Parse GTDT to initialize timer
2015-02-04 14:02 ` [PATCH RFC 16/35] ARM64 / ACPI: Parse GTDT to initialize timer parth.dixit
@ 2015-02-04 21:51 ` Julien Grall
2015-02-05 11:39 ` Ian Campbell
2015-02-05 14:46 ` Stefano Stabellini
1 sibling, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-04 21:51 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, stefano.stabellini, jbeulich,
christoffer.dall
Hi Parth,
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Parse GTDT (Generic Timer Descriptor Table) to initialize timer.
> Using the information presented by GTDT to initialize the arch
> timer (not momery-mapped).
memory-mapped
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/setup.c | 6 +++++
> xen/arch/arm/time.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++
> xen/include/xen/time.h | 1 +
> 3 files changed, 73 insertions(+)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 569b2da..af9f429 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -775,7 +775,12 @@ void __init start_xen(unsigned long boot_phys_offset,
> smp_init_cpus();
> cpus = smp_get_max_cpus();
>
> +/* Comment for now take it after GIC initialization */
> +#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
> + init_xen_acpi_time();
> +#else
> init_xen_time();
> +#endif
This is clearly wrong. A same Xen binary should run on both ACPI and DT
when ACPI is enabled.
Also, I would take care of the different between ACPI and DT in
init_xen_time, rather than ifdefining here. It will make the code more
cleaner.
> gic_init();
>
> @@ -789,6 +794,7 @@ void __init start_xen(unsigned long boot_phys_offset,
> xsm_dt_init();
>
> init_maintenance_interrupt();
> +
Spurious change.
> init_timer_interrupt();
>
> timer_init();
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index 0add494..0d4c26d 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -29,6 +29,7 @@
> #include <xen/time.h>
> #include <xen/sched.h>
> #include <xen/event.h>
> +#include <xen/acpi.h>
> #include <asm/system.h>
> #include <asm/time.h>
> #include <asm/gic.h>
> @@ -239,6 +240,71 @@ struct tm wallclock_time(uint64_t *ns)
> return (struct tm) { 0 };
> }
>
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
#ifdef CONFIG_ACPI
> +#define ACPI_GTDT_INTR_MASK 0x3
> +
> +static int GTDT_INTRL_TAB[] ={ DT_IRQ_TYPE_LEVEL_HIGH, DT_IRQ_TYPE_EDGE_RISING,
> + DT_IRQ_TYPE_LEVEL_LOW ,DT_IRQ_TYPE_EDGE_FALLING};
> +
> +/* Initialize per-processor generic timer */
> +static int __init arch_timer_acpi_init(struct acpi_table_header *table)
> +{
> + int res;
> + int type;
> + struct acpi_table_gtdt *gtdt;
> +
> + gtdt = (struct acpi_table_gtdt *)table;
> +
> + /* Initialize all the generic timer IRQ variable from GTDT table */
> +
> + type = GTDT_INTRL_TAB[gtdt->non_secure_el1_flags & ACPI_GTDT_INTR_MASK];
> + acpi_set_irq(gtdt->non_secure_el1_interrupt, type);
> + timer_irq[TIMER_PHYS_NONSECURE_PPI] = gtdt->non_secure_el1_interrupt;
> +
> + type = GTDT_INTRL_TAB[gtdt->secure_el1_flags & ACPI_GTDT_INTR_MASK];
> + acpi_set_irq(gtdt->secure_el1_interrupt, type);
> + timer_irq[TIMER_PHYS_SECURE_PPI] = gtdt->secure_el1_interrupt;
> +
> + type = GTDT_INTRL_TAB[gtdt->non_secure_el2_flags & ACPI_GTDT_INTR_MASK];
> + acpi_set_irq(gtdt->non_secure_el2_interrupt, type);
> + timer_irq[TIMER_HYP_PPI] = gtdt->non_secure_el2_interrupt;
> +
> + type = GTDT_INTRL_TAB[gtdt->virtual_timer_flags & ACPI_GTDT_INTR_MASK];
> + acpi_set_irq(gtdt->virtual_timer_interrupt, type);
> + timer_irq[TIMER_VIRT_PPI] = gtdt->virtual_timer_interrupt;
> +
> + printk("Generic Timer IRQ from ACPI GTDT: phys=%u hyp=%u virt=%u\n",
> + timer_irq[TIMER_PHYS_NONSECURE_PPI],
> + timer_irq[TIMER_HYP_PPI],
> + timer_irq[TIMER_VIRT_PPI]);
> +
> + res = platform_init_time();
The platform code is DT-centrict. Although, most of the code below is
similar to the Timer DT initialization. Please factor it.
> + if ( res )
> + printk("Timer: Cannot initialize platform timer");
> +
> + /* Check that this CPU supports the Generic Timer interface */
> + if ( !cpu_has_gentimer )
> + printk("CPU does not support the Generic Timer v1 interface");
> +
> + cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
> +
> + boot_count = READ_SYSREG64(CNTPCT_EL0);
> +
> + printk("Using generic timer at %lu KHz\n", cpu_khz);
> +
> + return 0;
> +}
> +
> +int __init init_xen_acpi_time(void)
> +{
> + /* Initialize all the generic timers presented in GTDT */
> + acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
> + return 0;
> +}
> +
> +#endif
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
> index 709501f..4598a0c 100644
> --- a/xen/include/xen/time.h
> +++ b/xen/include/xen/time.h
> @@ -11,6 +11,7 @@
> #include <xen/types.h>
> #include <public/xen.h>
>
> +extern int init_xen_acpi_time(void);
This is ARM specific, please move the prototype in asm-arm/time.h.
> extern int init_xen_time(void);
> extern void cstate_restore_tsc(void);
>
>
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 16/35] ARM64 / ACPI: Parse GTDT to initialize timer
2015-02-04 21:51 ` Julien Grall
@ 2015-02-05 11:39 ` Ian Campbell
2015-02-05 14:26 ` Julien Grall
2015-02-05 14:51 ` Stefano Stabellini
0 siblings, 2 replies; 166+ messages in thread
From: Ian Campbell @ 2015-02-05 11:39 UTC (permalink / raw)
To: Julien Grall
Cc: Naresh Bhat, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
On Wed, 2015-02-04 at 21:51 +0000, Julien Grall wrote:
> > + res = platform_init_time();
>
> The platform code is DT-centrict.
This is an interesting point. Given the stated goals and reasons for
having ACPI on ARM it seems to me that in general nothing under
xen/arch/arm/platforms/* should ever be needed, and certainly not things
like platform time init which we should insist have been setup correctly
by the platform.
It's possible that we might need some concept of ACPI quirks at some
point, but lets have a simple rule for now:
* The initial set of core ACPI patches for Xen should not ever
call into any platform specific code.
If there turns out to be a need to call platform code in this initial
series then it must be in a separate patch towards the end of the
series, after all the core code has been introduced. The patch
description should contain a detailed justification as to why this
platform specific code is required.
I think it is probable that any ACPI quirks should be separate from the
(DT-based) xen/arch/arm/platforms/* stuff, but lets see what, if
anything, turns out to be needed.
Perhaps platform_* should all grow an "ASSERT(!in acpi mode)" (or
"ASSERT(in dt mode)") to help enforce this.
Ian.
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 16/35] ARM64 / ACPI: Parse GTDT to initialize timer
2015-02-05 11:39 ` Ian Campbell
@ 2015-02-05 14:26 ` Julien Grall
2015-02-05 14:51 ` Stefano Stabellini
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-05 14:26 UTC (permalink / raw)
To: Ian Campbell
Cc: Naresh Bhat, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
Hi Ian,
On 05/02/2015 19:39, Ian Campbell wrote:
> On Wed, 2015-02-04 at 21:51 +0000, Julien Grall wrote:
> Perhaps platform_* should all grow an "ASSERT(!in acpi mode)" (or
> "ASSERT(in dt mode)") to help enforce this.
That would be good. We could also do the same for the device tree to
catch any usage of DT when ACPI is enabled.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 16/35] ARM64 / ACPI: Parse GTDT to initialize timer
2015-02-05 11:39 ` Ian Campbell
2015-02-05 14:26 ` Julien Grall
@ 2015-02-05 14:51 ` Stefano Stabellini
2015-02-05 14:55 ` Ian Campbell
1 sibling, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 14:51 UTC (permalink / raw)
To: Ian Campbell
Cc: Naresh Bhat, Julien Grall, tim, xen-devel, stefano.stabellini,
jbeulich, parth.dixit, christoffer.dall
On Thu, 5 Feb 2015, Ian Campbell wrote:
> On Wed, 2015-02-04 at 21:51 +0000, Julien Grall wrote:
> > > + res = platform_init_time();
> >
> > The platform code is DT-centrict.
>
> This is an interesting point. Given the stated goals and reasons for
> having ACPI on ARM it seems to me that in general nothing under
> xen/arch/arm/platforms/* should ever be needed, and certainly not things
> like platform time init which we should insist have been setup correctly
> by the platform.
At the moment I don't think that ACPI on ARM is in the state where we
can get away without anything under platforms.
> It's possible that we might need some concept of ACPI quirks at some
> point, but lets have a simple rule for now:
>
> * The initial set of core ACPI patches for Xen should not ever
> call into any platform specific code.
I think that is a good rule for the initial implementation.
If/When we need platform files on acpi systems, we might want to
introduce a new separate struct platform_desc for them anyway.
> If there turns out to be a need to call platform code in this initial
> series then it must be in a separate patch towards the end of the
> series, after all the core code has been introduced. The patch
> description should contain a detailed justification as to why this
> platform specific code is required.
>
> I think it is probable that any ACPI quirks should be separate from the
> (DT-based) xen/arch/arm/platforms/* stuff, but lets see what, if
> anything, turns out to be needed.
I agree
> Perhaps platform_* should all grow an "ASSERT(!in acpi mode)" (or
> "ASSERT(in dt mode)") to help enforce this.
>
> Ian.
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 16/35] ARM64 / ACPI: Parse GTDT to initialize timer
2015-02-05 14:51 ` Stefano Stabellini
@ 2015-02-05 14:55 ` Ian Campbell
0 siblings, 0 replies; 166+ messages in thread
From: Ian Campbell @ 2015-02-05 14:55 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Naresh Bhat, Julien Grall, tim, xen-devel, stefano.stabellini,
jbeulich, parth.dixit, christoffer.dall
On Thu, 2015-02-05 at 14:51 +0000, Stefano Stabellini wrote:
> On Thu, 5 Feb 2015, Ian Campbell wrote:
> > On Wed, 2015-02-04 at 21:51 +0000, Julien Grall wrote:
> > > > + res = platform_init_time();
> > >
> > > The platform code is DT-centrict.
> >
> > This is an interesting point. Given the stated goals and reasons for
> > having ACPI on ARM it seems to me that in general nothing under
> > xen/arch/arm/platforms/* should ever be needed, and certainly not things
> > like platform time init which we should insist have been setup correctly
> > by the platform.
>
> At the moment I don't think that ACPI on ARM is in the state where we
> can get away without anything under platforms.
That might be true, but given that ACPI is supposed to make this stuff
go away I want it to be harder to workaround something in Xen than it
would be to just fix the firmware, so we don't accumulate crappy hacks
while ACPI is immature.
Which means the barrier for getting such things into Xen needs to be
pretty darn high IMHO.
> > It's possible that we might need some concept of ACPI quirks at some
> > point, but lets have a simple rule for now:
> >
> > * The initial set of core ACPI patches for Xen should not ever
> > call into any platform specific code.
>
> I think that is a good rule for the initial implementation.
> If/When we need platform files on acpi systems, we might want to
> introduce a new separate struct platform_desc for them anyway.
Yeah, I don't think the same struct would make sense.
Ian.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 16/35] ARM64 / ACPI: Parse GTDT to initialize timer
2015-02-04 14:02 ` [PATCH RFC 16/35] ARM64 / ACPI: Parse GTDT to initialize timer parth.dixit
2015-02-04 21:51 ` Julien Grall
@ 2015-02-05 14:46 ` Stefano Stabellini
1 sibling, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 14:46 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Parse GTDT (Generic Timer Descriptor Table) to initialize timer.
> Using the information presented by GTDT to initialize the arch
> timer (not momery-mapped).
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/setup.c | 6 +++++
> xen/arch/arm/time.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++
> xen/include/xen/time.h | 1 +
> 3 files changed, 73 insertions(+)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 569b2da..af9f429 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -775,7 +775,12 @@ void __init start_xen(unsigned long boot_phys_offset,
> smp_init_cpus();
> cpus = smp_get_max_cpus();
>
> +/* Comment for now take it after GIC initialization */
> +#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
> + init_xen_acpi_time();
> +#else
> init_xen_time();
> +#endif
I wouldn't introduce a new function for this.
You can call the acpi specific initialization with appropriate #defines
from the implementation of init_xen_time.
> gic_init();
>
> @@ -789,6 +794,7 @@ void __init start_xen(unsigned long boot_phys_offset,
> xsm_dt_init();
>
> init_maintenance_interrupt();
> +
> init_timer_interrupt();
>
> timer_init();
Spurious change
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index 0add494..0d4c26d 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -29,6 +29,7 @@
> #include <xen/time.h>
> #include <xen/sched.h>
> #include <xen/event.h>
> +#include <xen/acpi.h>
> #include <asm/system.h>
> #include <asm/time.h>
> #include <asm/gic.h>
> @@ -239,6 +240,71 @@ struct tm wallclock_time(uint64_t *ns)
> return (struct tm) { 0 };
> }
>
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> +
> +#define ACPI_GTDT_INTR_MASK 0x3
This should be in actbl3.h with the other GTDT #defines.
> +static int GTDT_INTRL_TAB[] ={ DT_IRQ_TYPE_LEVEL_HIGH, DT_IRQ_TYPE_EDGE_RISING,
> + DT_IRQ_TYPE_LEVEL_LOW ,DT_IRQ_TYPE_EDGE_FALLING};
I don't think is a good idea to specify GTDT interrupt states in terms
of DT_IRQ_TYPEs. Unless this is some sort of conversion table?
> +/* Initialize per-processor generic timer */
> +static int __init arch_timer_acpi_init(struct acpi_table_header *table)
> +{
> + int res;
> + int type;
> + struct acpi_table_gtdt *gtdt;
> +
> + gtdt = (struct acpi_table_gtdt *)table;
> +
> + /* Initialize all the generic timer IRQ variable from GTDT table */
> +
> + type = GTDT_INTRL_TAB[gtdt->non_secure_el1_flags & ACPI_GTDT_INTR_MASK];
> + acpi_set_irq(gtdt->non_secure_el1_interrupt, type);
> + timer_irq[TIMER_PHYS_NONSECURE_PPI] = gtdt->non_secure_el1_interrupt;
> +
> + type = GTDT_INTRL_TAB[gtdt->secure_el1_flags & ACPI_GTDT_INTR_MASK];
> + acpi_set_irq(gtdt->secure_el1_interrupt, type);
> + timer_irq[TIMER_PHYS_SECURE_PPI] = gtdt->secure_el1_interrupt;
> +
> + type = GTDT_INTRL_TAB[gtdt->non_secure_el2_flags & ACPI_GTDT_INTR_MASK];
> + acpi_set_irq(gtdt->non_secure_el2_interrupt, type);
> + timer_irq[TIMER_HYP_PPI] = gtdt->non_secure_el2_interrupt;
> +
> + type = GTDT_INTRL_TAB[gtdt->virtual_timer_flags & ACPI_GTDT_INTR_MASK];
> + acpi_set_irq(gtdt->virtual_timer_interrupt, type);
> + timer_irq[TIMER_VIRT_PPI] = gtdt->virtual_timer_interrupt;
> +
> + printk("Generic Timer IRQ from ACPI GTDT: phys=%u hyp=%u virt=%u\n",
> + timer_irq[TIMER_PHYS_NONSECURE_PPI],
> + timer_irq[TIMER_HYP_PPI],
> + timer_irq[TIMER_VIRT_PPI]);
> +
> + res = platform_init_time();
> + if ( res )
> + printk("Timer: Cannot initialize platform timer");
> +
> + /* Check that this CPU supports the Generic Timer interface */
> + if ( !cpu_has_gentimer )
> + printk("CPU does not support the Generic Timer v1 interface");
> +
> + cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
> +
> + boot_count = READ_SYSREG64(CNTPCT_EL0);
> +
> + printk("Using generic timer at %lu KHz\n", cpu_khz);
> +
> + return 0;
> +}
> +
> +int __init init_xen_acpi_time(void)
> +{
> + /* Initialize all the generic timers presented in GTDT */
> + acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
> + return 0;
> +}
> +
> +#endif
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
> index 709501f..4598a0c 100644
> --- a/xen/include/xen/time.h
> +++ b/xen/include/xen/time.h
> @@ -11,6 +11,7 @@
> #include <xen/types.h>
> #include <public/xen.h>
>
> +extern int init_xen_acpi_time(void);
> extern int init_xen_time(void);
> extern void cstate_restore_tsc(void);
>
> --
> 1.9.1
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (15 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 16/35] ARM64 / ACPI: Parse GTDT to initialize timer parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-04 21:57 ` Julien Grall
2015-02-05 15:27 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 18/35] arm : add helper function for setting interrupt type parth.dixit
` (18 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, Parth Dixit, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
Parse ACPI SPCR (Serial Port Console Redirection table) table and
initialize the serial port pl011.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/arch/arm/setup.c | 6 +++++
xen/drivers/char/pl011.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++
xen/include/acpi/actbl2.h | 6 +++++
xen/include/xen/serial.h | 1 +
4 files changed, 82 insertions(+)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index af9f429..317b985 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -762,7 +762,13 @@ void __init start_xen(unsigned long boot_phys_offset,
init_IRQ();
+ /* If ACPI enabled and ARM64 arch then UART initialization from SPCR table */
+#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
+ acpi_uart_init();
+#else
dt_uart_init();
+#endif
+
console_init_preirq();
console_init_ring();
diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index dd19ce8..3499ee3 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -280,6 +280,75 @@ DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
.init = pl011_uart_init,
DT_DEVICE_END
+/* Parse the SPCR table and initialize the Serial UART */
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+
+#include <xen/acpi.h>
+
+static int __init acpi_pl011_uart_init(struct acpi_table_spcr *spcr)
+{
+ struct pl011 *uart;
+ u64 addr, size;
+
+ uart = &pl011_com;
+ uart->clock_hz = 0x16e3600;
+ uart->baud = spcr->baud_rate;
+ uart->data_bits = 8;
+ uart->parity = spcr->parity;
+ uart->stop_bits = spcr->stop_bits;
+
+ if ( spcr->interrupt < 0 )
+ {
+ printk("pl011: Unable to retrieve the IRQ\n");
+ return -EINVAL;
+ }
+
+ uart->irq = spcr->interrupt;
+ addr = spcr->serial_port.address;
+ size = 0x1000;
+ uart->regs = ioremap_nocache(addr, size);
+
+ acpi_set_irq(uart->irq, DT_IRQ_TYPE_EDGE_BOTH);
+
+ if ( !uart->regs )
+ {
+ printk("pl011: Unable to map the UART memory\n");
+ return -ENOMEM;
+ }
+
+ uart->vuart.base_addr = addr;
+ uart->vuart.size = size;
+ uart->vuart.data_off = DR;
+ uart->vuart.status_off = FR;
+ uart->vuart.status = 0;
+
+ /* Register with generic serial driver. */
+ serial_register_uart(SERHND_DTUART, &pl011_driver, uart);
+
+ return 0;
+}
+
+void __init acpi_uart_init(void)
+{
+ struct acpi_table_spcr *spcr=NULL;
+
+ printk("ACPI UART Init\n");
+ acpi_get_table(ACPI_SIG_SPCR, 0,(struct acpi_table_header **)&spcr);
+
+ switch(spcr->interface_type) {
+ case ACPI_SPCR_TYPPE_PL011:
+ acpi_pl011_uart_init(spcr);
+ break;
+ /* Not implemented yet */
+ case ACPI_SPCR_TYPE_16550:
+ case ACPI_SPCR_TYPE_16550_SUB:
+ default:
+ printk("iinvalid uart type\n");
+ }
+}
+
+#endif
+
/*
* Local variables:
* mode: C
diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 87bc6b3..6aad200 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -815,6 +815,12 @@ struct acpi_table_spcr {
#define ACPI_SPCR_DO_NOT_DISABLE (1)
+/* UART Interface type */
+#define ACPI_SPCR_TYPE_16550 0
+#define ACPI_SPCR_TYPE_16550_SUB 1
+#define ACPI_SPCR_TYPPE_PL011 3
+
+
/*******************************************************************************
*
* SPMI - Server Platform Management Interface table
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 9f4451b..99e53d4 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -167,6 +167,7 @@ void ns16550_init(int index, struct ns16550_defaults *defaults);
void ehci_dbgp_init(void);
void __init dt_uart_init(void);
+void __init acpi_uart_init(void);
struct physdev_dbgp_op;
int dbgp_op(const struct physdev_dbgp_op *);
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table
2015-02-04 14:02 ` [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table parth.dixit
@ 2015-02-04 21:57 ` Julien Grall
2015-02-05 11:42 ` Ian Campbell
2015-02-05 15:27 ` Stefano Stabellini
1 sibling, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-04 21:57 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, stefano.stabellini, jbeulich,
christoffer.dall
Hi Parth,
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Parse ACPI SPCR (Serial Port Console Redirection table) table and
> initialize the serial port pl011.
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/setup.c | 6 +++++
> xen/drivers/char/pl011.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++
> xen/include/acpi/actbl2.h | 6 +++++
> xen/include/xen/serial.h | 1 +
> 4 files changed, 82 insertions(+)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index af9f429..317b985 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -762,7 +762,13 @@ void __init start_xen(unsigned long boot_phys_offset,
>
> init_IRQ();
>
> + /* If ACPI enabled and ARM64 arch then UART initialization from SPCR table */
> +#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
> + acpi_uart_init();
> +#else
> dt_uart_init();
> +#endif
> +
Same as the previous patch, a Xen binary should both work on ACPI and DT.
> console_init_preirq();
> console_init_ring();
>
> diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
> index dd19ce8..3499ee3 100644
> --- a/xen/drivers/char/pl011.c
> +++ b/xen/drivers/char/pl011.c
> @@ -280,6 +280,75 @@ DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
> .init = pl011_uart_init,
> DT_DEVICE_END
>
> +/* Parse the SPCR table and initialize the Serial UART */
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
#ifdef CONFIG_ACPI
> +
> +#include <xen/acpi.h>
> +
No include in the middle of the file. Please move it a the beginning.
> +static int __init acpi_pl011_uart_init(struct acpi_table_spcr *spcr)
> +{
> + struct pl011 *uart;
> + u64 addr, size;
> +
> + uart = &pl011_com;
> + uart->clock_hz = 0x16e3600;
> + uart->baud = spcr->baud_rate;
> + uart->data_bits = 8;
> + uart->parity = spcr->parity;
> + uart->stop_bits = spcr->stop_bits;
> +
> + if ( spcr->interrupt < 0 )
> + {
> + printk("pl011: Unable to retrieve the IRQ\n");
> + return -EINVAL;
> + }
> +
> + uart->irq = spcr->interrupt;
> + addr = spcr->serial_port.address;
> + size = 0x1000;
Please explain this size.
> + uart->regs = ioremap_nocache(addr, size);
> +
> + acpi_set_irq(uart->irq, DT_IRQ_TYPE_EDGE_BOTH);
Is it always the case? I don't think so... Also, acpi_set_irq is define
after this patch. The code should never use code defined later.
> +
> + if ( !uart->regs )
> + {
> + printk("pl011: Unable to map the UART memory\n");
> + return -ENOMEM;
> + }
> +
> + uart->vuart.base_addr = addr;
> + uart->vuart.size = size;
> + uart->vuart.data_off = DR;
> + uart->vuart.status_off = FR;
> + uart->vuart.status = 0;
> +
> + /* Register with generic serial driver. */
> + serial_register_uart(SERHND_DTUART, &pl011_driver, uart);
I don't really like this. Maybe we should define a different serial
handler, or redefine it to SERHND_ARM
> +
> + return 0;
> +}
> +
> +void __init acpi_uart_init(void)
> +{
This function is not part of the PL011. In this case, you are breaking
the design.
I believe that most of the SPCR parsing should be generic, so maybe you
could extend the DEVICE interface to handle the ACPI case.
> + struct acpi_table_spcr *spcr=NULL;
> +
> + printk("ACPI UART Init\n");
> + acpi_get_table(ACPI_SIG_SPCR, 0,(struct acpi_table_header **)&spcr);
> +
> + switch(spcr->interface_type) {
> + case ACPI_SPCR_TYPPE_PL011:
> + acpi_pl011_uart_init(spcr);
> + break;
> + /* Not implemented yet */
> + case ACPI_SPCR_TYPE_16550:
> + case ACPI_SPCR_TYPE_16550_SUB:
> + default:
> + printk("iinvalid uart type\n");
invalid
> + }
> +}
> +
> +#endif
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
> index 87bc6b3..6aad200 100644
> --- a/xen/include/acpi/actbl2.h
> +++ b/xen/include/acpi/actbl2.h
> @@ -815,6 +815,12 @@ struct acpi_table_spcr {
>
> #define ACPI_SPCR_DO_NOT_DISABLE (1)
>
> +/* UART Interface type */
> +#define ACPI_SPCR_TYPE_16550 0
> +#define ACPI_SPCR_TYPE_16550_SUB 1
> +#define ACPI_SPCR_TYPPE_PL011 3
> +
> +
> /*******************************************************************************
> *
> * SPMI - Server Platform Management Interface table
> diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
> index 9f4451b..99e53d4 100644
> --- a/xen/include/xen/serial.h
> +++ b/xen/include/xen/serial.h
> @@ -167,6 +167,7 @@ void ns16550_init(int index, struct ns16550_defaults *defaults);
> void ehci_dbgp_init(void);
>
> void __init dt_uart_init(void);
> +void __init acpi_uart_init(void);
>
> struct physdev_dbgp_op;
> int dbgp_op(const struct physdev_dbgp_op *);
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table
2015-02-04 21:57 ` Julien Grall
@ 2015-02-05 11:42 ` Ian Campbell
2015-02-05 14:29 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Ian Campbell @ 2015-02-05 11:42 UTC (permalink / raw)
To: Julien Grall
Cc: Naresh Bhat, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
On Wed, 2015-02-04 at 21:57 +0000, Julien Grall wrote:
> I believe that most of the SPCR parsing should be generic, so maybe you
> could extend the DEVICE interface to handle the ACPI case.
Extending DT_DEVICE would be confusing IMHO. The answer is probably a
similar but parallel ACPI_DEVICE mechanism, perhaps sharing some
underlying infrastructure with DT_DEVICE.
Ian.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table
2015-02-05 11:42 ` Ian Campbell
@ 2015-02-05 14:29 ` Julien Grall
2015-02-05 14:52 ` Ian Campbell
0 siblings, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-05 14:29 UTC (permalink / raw)
To: Ian Campbell
Cc: Naresh Bhat, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
Hi Ian,
On 05/02/2015 19:42, Ian Campbell wrote:
> On Wed, 2015-02-04 at 21:57 +0000, Julien Grall wrote:
>
>> I believe that most of the SPCR parsing should be generic, so maybe you
>> could extend the DEVICE interface to handle the ACPI case.
>
> Extending DT_DEVICE would be confusing IMHO. The answer is probably a
> similar but parallel ACPI_DEVICE mechanism, perhaps sharing some
> underlying infrastructure with DT_DEVICE.
I was thinking to rename DT_DEVICE into something more meaningful.
Because infine, DT_DEVICE_START/DT_DEVICE_END doesn't do anything DT
specific but defined the a printed name and the device class.
So we can extend the device framework without adding too much new code.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table
2015-02-05 14:29 ` Julien Grall
@ 2015-02-05 14:52 ` Ian Campbell
2015-02-11 6:10 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Ian Campbell @ 2015-02-05 14:52 UTC (permalink / raw)
To: Julien Grall
Cc: Naresh Bhat, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
On Thu, 2015-02-05 at 22:29 +0800, Julien Grall wrote:
> Hi Ian,
>
> On 05/02/2015 19:42, Ian Campbell wrote:
> > On Wed, 2015-02-04 at 21:57 +0000, Julien Grall wrote:
> >
> >> I believe that most of the SPCR parsing should be generic, so maybe you
> >> could extend the DEVICE interface to handle the ACPI case.
> >
> > Extending DT_DEVICE would be confusing IMHO. The answer is probably a
> > similar but parallel ACPI_DEVICE mechanism, perhaps sharing some
> > underlying infrastructure with DT_DEVICE.
>
> I was thinking to rename DT_DEVICE into something more meaningful.
> Because infine, DT_DEVICE_START/DT_DEVICE_END doesn't do anything DT
> specific but defined the a printed name and the device class.
>
> So we can extend the device framework without adding too much new code.
Remember that things like the probe function are going to have different
prototypes. It also contains things like the DT compat list which is DT
specific.
So, I think the macros should remain boot firmware specific, whether
they fill in the same array or not is an implementation detail, but it
would seem less error prone to split them up.
Ian.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table
2015-02-05 14:52 ` Ian Campbell
@ 2015-02-11 6:10 ` Julien Grall
0 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-11 6:10 UTC (permalink / raw)
To: Ian Campbell
Cc: Naresh Bhat, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
Hi Ian,
On 05/02/2015 22:52, Ian Campbell wrote:
> On Thu, 2015-02-05 at 22:29 +0800, Julien Grall wrote:
>> On 05/02/2015 19:42, Ian Campbell wrote:
>>> On Wed, 2015-02-04 at 21:57 +0000, Julien Grall wrote:
>>>
>>>> I believe that most of the SPCR parsing should be generic, so maybe you
>>>> could extend the DEVICE interface to handle the ACPI case.
>>>
>>> Extending DT_DEVICE would be confusing IMHO. The answer is probably a
>>> similar but parallel ACPI_DEVICE mechanism, perhaps sharing some
>>> underlying infrastructure with DT_DEVICE.
>>
>> I was thinking to rename DT_DEVICE into something more meaningful.
>> Because infine, DT_DEVICE_START/DT_DEVICE_END doesn't do anything DT
>> specific but defined the a printed name and the device class.
>>
>> So we can extend the device framework without adding too much new code.
>
> Remember that things like the probe function are going to have different
> prototypes. It also contains things like the DT compat list which is DT
> specific.
>
> So, I think the macros should remain boot firmware specific, whether
> they fill in the same array or not is an implementation detail, but it
> would seem less error prone to split them up.
We may duplicate some fields with this. Although we are talking about
only few bytes.
So I guess it's fine.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table
2015-02-04 14:02 ` [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table parth.dixit
2015-02-04 21:57 ` Julien Grall
@ 2015-02-05 15:27 ` Stefano Stabellini
2015-02-05 15:32 ` Ian Campbell
1 sibling, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 15:27 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Parse ACPI SPCR (Serial Port Console Redirection table) table and
> initialize the serial port pl011.
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/setup.c | 6 +++++
> xen/drivers/char/pl011.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++
> xen/include/acpi/actbl2.h | 6 +++++
> xen/include/xen/serial.h | 1 +
> 4 files changed, 82 insertions(+)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index af9f429..317b985 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -762,7 +762,13 @@ void __init start_xen(unsigned long boot_phys_offset,
>
> init_IRQ();
>
> + /* If ACPI enabled and ARM64 arch then UART initialization from SPCR table */
> +#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
> + acpi_uart_init();
> +#else
> dt_uart_init();
> +#endif
This is bad. We should have a single uart_init function, that calls
acpi_uart_init #ifdef(CONFIG_ACPI) and/or simply if(!acpi_disabled).
> console_init_preirq();
> console_init_ring();
>
> diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
> index dd19ce8..3499ee3 100644
> --- a/xen/drivers/char/pl011.c
> +++ b/xen/drivers/char/pl011.c
> @@ -280,6 +280,75 @@ DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
> .init = pl011_uart_init,
> DT_DEVICE_END
>
> +/* Parse the SPCR table and initialize the Serial UART */
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> +
> +#include <xen/acpi.h>
> +
> +static int __init acpi_pl011_uart_init(struct acpi_table_spcr *spcr)
> +{
> + struct pl011 *uart;
> + u64 addr, size;
> +
> + uart = &pl011_com;
> + uart->clock_hz = 0x16e3600;
> + uart->baud = spcr->baud_rate;
> + uart->data_bits = 8;
> + uart->parity = spcr->parity;
> + uart->stop_bits = spcr->stop_bits;
> +
> + if ( spcr->interrupt < 0 )
> + {
> + printk("pl011: Unable to retrieve the IRQ\n");
> + return -EINVAL;
> + }
> +
> + uart->irq = spcr->interrupt;
> + addr = spcr->serial_port.address;
> + size = 0x1000;
> + uart->regs = ioremap_nocache(addr, size);
> +
> + acpi_set_irq(uart->irq, DT_IRQ_TYPE_EDGE_BOTH);
It is not appropriate to use DT_IRQ_TYPEs in an acpi init function.
I think you should introduce a new ACPI irq type or at least have an
explicit conversion function.
> + if ( !uart->regs )
> + {
> + printk("pl011: Unable to map the UART memory\n");
> + return -ENOMEM;
> + }
> +
> + uart->vuart.base_addr = addr;
> + uart->vuart.size = size;
> + uart->vuart.data_off = DR;
> + uart->vuart.status_off = FR;
> + uart->vuart.status = 0;
> +
> + /* Register with generic serial driver. */
> + serial_register_uart(SERHND_DTUART, &pl011_driver, uart);
> +
> + return 0;
> +}
> +
> +void __init acpi_uart_init(void)
> +{
> + struct acpi_table_spcr *spcr=NULL;
> +
> + printk("ACPI UART Init\n");
> + acpi_get_table(ACPI_SIG_SPCR, 0,(struct acpi_table_header **)&spcr);
> +
> + switch(spcr->interface_type) {
> + case ACPI_SPCR_TYPPE_PL011:
> + acpi_pl011_uart_init(spcr);
> + break;
> + /* Not implemented yet */
> + case ACPI_SPCR_TYPE_16550:
> + case ACPI_SPCR_TYPE_16550_SUB:
> + default:
> + printk("iinvalid uart type\n");
> + }
> +}
Given that acpi_uart_init is supposed to be a generic uart initalization
function, is not right to implement it in pl011.c, the source file for
the pl011 driver.
I think that you should rename dt-uart.c into something more generic,
maybe arm_uart, then move acpi_uart_init there.
> +#endif
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
> index 87bc6b3..6aad200 100644
> --- a/xen/include/acpi/actbl2.h
> +++ b/xen/include/acpi/actbl2.h
> @@ -815,6 +815,12 @@ struct acpi_table_spcr {
>
> #define ACPI_SPCR_DO_NOT_DISABLE (1)
>
> +/* UART Interface type */
> +#define ACPI_SPCR_TYPE_16550 0
> +#define ACPI_SPCR_TYPE_16550_SUB 1
> +#define ACPI_SPCR_TYPPE_PL011 3
^ typo
> +
> /*******************************************************************************
> *
> * SPMI - Server Platform Management Interface table
> diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
> index 9f4451b..99e53d4 100644
> --- a/xen/include/xen/serial.h
> +++ b/xen/include/xen/serial.h
> @@ -167,6 +167,7 @@ void ns16550_init(int index, struct ns16550_defaults *defaults);
> void ehci_dbgp_init(void);
>
> void __init dt_uart_init(void);
> +void __init acpi_uart_init(void);
>
> struct physdev_dbgp_op;
> int dbgp_op(const struct physdev_dbgp_op *);
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table
2015-02-05 15:27 ` Stefano Stabellini
@ 2015-02-05 15:32 ` Ian Campbell
0 siblings, 0 replies; 166+ messages in thread
From: Ian Campbell @ 2015-02-05 15:32 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Naresh Bhat, julien.grall, tim, xen-devel, stefano.stabellini,
jbeulich, Parth Dixit, christoffer.dall
On Thu, 2015-02-05 at 15:27 +0000, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> > From: Naresh Bhat <naresh.bhat@linaro.org>
> >
> > Parse ACPI SPCR (Serial Port Console Redirection table) table and
> > initialize the serial port pl011.
> >
> > Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> > ---
> > xen/arch/arm/setup.c | 6 +++++
> > xen/drivers/char/pl011.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++
> > xen/include/acpi/actbl2.h | 6 +++++
> > xen/include/xen/serial.h | 1 +
> > 4 files changed, 82 insertions(+)
> >
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index af9f429..317b985 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -762,7 +762,13 @@ void __init start_xen(unsigned long boot_phys_offset,
> >
> > init_IRQ();
> >
> > + /* If ACPI enabled and ARM64 arch then UART initialization from SPCR table */
> > +#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
> > + acpi_uart_init();
> > +#else
> > dt_uart_init();
> > +#endif
>
> This is bad. We should have a single uart_init function, that calls
> acpi_uart_init #ifdef(CONFIG_ACPI) and/or simply if(!acpi_disabled).
The latter, please.
And yes I agree: all these foo_init's should be refactored to have
generic and dt parts and then have the acpi stuff inserted in the
appropriate place (ideally in at least two patches, refactor then add
ACPI). It should not be done by making each caller have a conditional on
acpi support as is being done in this series. i.e smth like:
uart_init()
{
[ early generic setup ]
if (acpi_enabled)
acpi_uart_init()
else
dt_uart_init()
[ late generic setup]
}
with start_xen calling uart_init.
The same is true of the timers, interrupt controllers, etc.
Ian.
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 18/35] arm : add helper function for setting interrupt type
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (16 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 17/35] pl011: Initialize serial from ACPI SPCR table parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-04 21:59 ` Julien Grall
2015-02-05 15:33 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support parth.dixit
` (17 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, julien.grall, tim, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
From: Parth Dixit <parth.dixit@linaro.org>
set edge/level type information for an interrupt
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/arch/arm/irq.c | 19 +++++++++++++++++++
xen/include/asm-arm/irq.h | 4 ++++
2 files changed, 23 insertions(+)
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 25ecf1d..ae4e99a 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -545,6 +545,25 @@ int platform_get_irq(const struct dt_device_node *device, int index)
return irq;
}
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+int acpi_set_irq(int irq,int type)
+{
+ int res;
+
+ /* Setup the IRQ type */
+ if ( irq < NR_LOCAL_IRQS )
+ res = irq_local_set_type(irq, type);
+ else
+ res = irq_set_spi_type(irq, type);
+
+ if ( res )
+ return -1;
+
+ return 0;
+
+}
+#endif
+
/*
* Local variables:
* mode: C
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 435dfcd..7b09557 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -47,6 +47,10 @@ void arch_move_irqs(struct vcpu *v);
/* Set IRQ type for an SPI */
int irq_set_spi_type(unsigned int spi, unsigned int type);
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+int acpi_set_irq(int irq,int type);
+#endif
+
int platform_get_irq(const struct dt_device_node *device, int index);
void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask);
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 18/35] arm : add helper function for setting interrupt type
2015-02-04 14:02 ` [PATCH RFC 18/35] arm : add helper function for setting interrupt type parth.dixit
@ 2015-02-04 21:59 ` Julien Grall
2015-02-05 15:33 ` Stefano Stabellini
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-04 21:59 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: christoffer.dall, tim, stefano.stabellini, ian.campbell, jbeulich
Hi Parth,
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> set edge/level type information for an interrupt
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/irq.c | 19 +++++++++++++++++++
> xen/include/asm-arm/irq.h | 4 ++++
> 2 files changed, 23 insertions(+)
>
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 25ecf1d..ae4e99a 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -545,6 +545,25 @@ int platform_get_irq(const struct dt_device_node *device, int index)
> return irq;
> }
>
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> +int acpi_set_irq(int irq,int type)
> +{
> + int res;
> +
> + /* Setup the IRQ type */
> + if ( irq < NR_LOCAL_IRQS )
> + res = irq_local_set_type(irq, type);
> + else
> + res = irq_set_spi_type(irq, type);
> +
> + if ( res )
> + return -1;
> +
> + return 0;
> +
> +}
> +#endif
> +
IIRC Ian was requiring a similar function for PCI. So I would rename to
a generic name.
Also, now that we start to support ACPI the name of the define DT_IRQ_*
are not anymore relevant. Maybe we should rename it.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 18/35] arm : add helper function for setting interrupt type
2015-02-04 14:02 ` [PATCH RFC 18/35] arm : add helper function for setting interrupt type parth.dixit
2015-02-04 21:59 ` Julien Grall
@ 2015-02-05 15:33 ` Stefano Stabellini
2015-02-11 6:12 ` Julien Grall
1 sibling, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 15:33 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, julien.grall, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> set edge/level type information for an interrupt
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/irq.c | 19 +++++++++++++++++++
> xen/include/asm-arm/irq.h | 4 ++++
> 2 files changed, 23 insertions(+)
>
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 25ecf1d..ae4e99a 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -545,6 +545,25 @@ int platform_get_irq(const struct dt_device_node *device, int index)
> return irq;
> }
>
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> +int acpi_set_irq(int irq,int type)
> +{
> + int res;
> +
> + /* Setup the IRQ type */
> + if ( irq < NR_LOCAL_IRQS )
> + res = irq_local_set_type(irq, type);
> + else
> + res = irq_set_spi_type(irq, type);
> +
> + if ( res )
> + return -1;
> +
> + return 0;
> +
> +}
> +#endif
As you are using this function in previous patches, you should
defenitely move this patch earlier in the series.
Please introduce another set of IRQ_TYPEs that are not DT specific, or
make the existing ones generic.
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
> index 435dfcd..7b09557 100644
> --- a/xen/include/asm-arm/irq.h
> +++ b/xen/include/asm-arm/irq.h
> @@ -47,6 +47,10 @@ void arch_move_irqs(struct vcpu *v);
> /* Set IRQ type for an SPI */
> int irq_set_spi_type(unsigned int spi, unsigned int type);
>
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> +int acpi_set_irq(int irq,int type);
> +#endif
> +
> int platform_get_irq(const struct dt_device_node *device, int index);
>
> void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask);
> --
> 1.9.1
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 18/35] arm : add helper function for setting interrupt type
2015-02-05 15:33 ` Stefano Stabellini
@ 2015-02-11 6:12 ` Julien Grall
0 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-11 6:12 UTC (permalink / raw)
To: Stefano Stabellini, Parth Dixit
Cc: ian.campbell, tim, xen-devel, stefano.stabellini, jbeulich,
christoffer.dall
Hi Stefano,
On 05/02/2015 23:33, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
>> From: Parth Dixit <parth.dixit@linaro.org>
>>
>> set edge/level type information for an interrupt
>>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>> xen/arch/arm/irq.c | 19 +++++++++++++++++++
>> xen/include/asm-arm/irq.h | 4 ++++
>> 2 files changed, 23 insertions(+)
>>
>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
>> index 25ecf1d..ae4e99a 100644
>> --- a/xen/arch/arm/irq.c
>> +++ b/xen/arch/arm/irq.c
>> @@ -545,6 +545,25 @@ int platform_get_irq(const struct dt_device_node *device, int index)
>> return irq;
>> }
>>
>> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>> +int acpi_set_irq(int irq,int type)
>> +{
>> + int res;
>> +
>> + /* Setup the IRQ type */
>> + if ( irq < NR_LOCAL_IRQS )
>> + res = irq_local_set_type(irq, type);
>> + else
>> + res = irq_set_spi_type(irq, type);
>> +
>> + if ( res )
>> + return -1;
>> +
>> + return 0;
>> +
>> +}
>> +#endif
>
> As you are using this function in previous patches, you should
> defenitely move this patch earlier in the series.
>
> Please introduce another set of IRQ_TYPEs that are not DT specific, or
> make the existing ones generic.
The existing (DT_IRQ_*) one has to be kept because it's part of the
device tree bindings.
I would introduce new one and, if necessary, add function to translate
DT_IRQ_* to IRQ_TYPEs.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (17 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 18/35] arm : add helper function for setting interrupt type parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-04 14:43 ` G Gregory
` (2 more replies)
2015-02-04 14:02 ` [PATCH RFC 20/35] xen/arm: Prepare a min DT for DOM0 parth.dixit
` (16 subsequent siblings)
35 siblings, 3 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Graeme Gregory, Naresh Bhat, julien.grall, tim,
Tomasz Nowicki, stefano.stabellini, Hanjun Guo, jbeulich,
Parth Dixit, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
It needs to parse GIC related subtables, collect CPU interface and distributor
addresses and call driver initialization function (which is hardware
abstraction agnostic). In a similar way, FDT initialize GICv1/2.
NOTE: This commit allow to initialize GICv1/2 only.
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
Conflicts:
xen/arch/arm/irq.c
---
xen/arch/arm/gic-v2.c | 271 +++++++++++++++++++++++++++++++++++++++++++++
xen/arch/arm/setup.c | 3 +-
xen/include/asm-arm/acpi.h | 2 +
3 files changed, 275 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index faad1ff..cb1d205 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -777,6 +777,277 @@ DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
.init = gicv2_init,
DT_DEVICE_END
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+
+#include <xen/acpi.h>
+#include <xen/errno.h>
+#include <xen/vmap.h>
+#include <asm/acpi.h>
+
+/*
+ * Hard code here, we can not get memory size from MADT (but FDT does),
+ * this size can be inferred from GICv2 spec
+ */
+
+#define ACPI_GIC_DIST_MEM_SIZE 0x00010000 // (SZ_64K)
+#define ACPI_GIC_CPU_IF_MEM_SIZE 0x00002000 // (SZ_8K)
+
+static DEFINE_PER_CPU(u64, gic_percpu_cpu_base);
+static cpumask_t gic_acpi_cpu_mask;
+static u64 dist_phy_base;
+
+static int __init
+gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+ struct acpi_madt_generic_interrupt *processor;
+ unsigned int cpu;
+
+ processor = (struct acpi_madt_generic_interrupt *)header;
+
+ if (BAD_MADT_ENTRY(processor, end))
+ return -EINVAL;
+ for_each_possible_cpu(cpu) {
+ /*
+ * FIXME: This condition is failing.
+ * In Xen we first want to bring/initialize the GIC in hypervisor with single CPU
+ * if (processor->mpidr == cpu_logical_map(cpu))
+ */
+ goto find;
+ }
+
+ printk("\nUnable to find CPU corresponding to GIC CPU entry [mpdir %lx]\n",
+ (long)processor->mpidr);
+
+ return 0;
+
+find:
+ /* Read from APIC table and fill up the GIC variables */
+ gicv2.dbase = processor->redist_base_address;
+ gicv2.cbase = processor->base_address;
+ gicv2.hbase = processor->gich_base_address;
+ gicv2.vbase = processor->gicv_base_address;
+ gicv2_info.maintenance_irq = processor->vgic_maintenance_interrupt;
+ if( processor->flags & ACPI_MADT_ENABLED )
+ {
+ if( processor->flags & ACPI_MADT_VGIC )
+ acpi_set_irq(gicv2_info.maintenance_irq, DT_IRQ_TYPE_EDGE_BOTH);
+ else
+ acpi_set_irq(gicv2_info.maintenance_irq, DT_IRQ_TYPE_LEVEL_MASK);
+ }
+
+ /*
+ * Do not validate CPU i/f base, we can still use "Local Interrupt
+ * Controller Address" from MADT header instead.
+ */
+ per_cpu(gic_percpu_cpu_base, cpu) = processor->base_address;
+ cpumask_set_cpu(cpu, &gic_acpi_cpu_mask);
+
+ return 0;
+}
+
+static int __init
+gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+ struct acpi_madt_generic_distributor *dist;
+
+ dist = (struct acpi_madt_generic_distributor *)header;
+
+ if (BAD_MADT_ENTRY(dist, end))
+ return -EINVAL;
+
+ dist_phy_base = dist->base_address;
+
+ return 0;
+}
+
+static int gic_acpi_validate_init(u64 madt_cpu_addr)
+{
+ void __iomem *cpu_base, *dist_base;
+ u64 gic_cpu_base = 0;
+ unsigned int cpu;
+
+ /* Process all GICC entries delivered by MADT */
+ if (!cpumask_empty(&gic_acpi_cpu_mask)) {
+ /*
+ * If MADT contains at least one GICC entry, it must be BSP
+ * dedicated.
+ */
+ if (!cpumask_test_cpu(0, &gic_acpi_cpu_mask)) {
+ printk("GICC entries exist but unable to find BSP GICC "
+ "address\n");
+ goto madt_cpu_base;
+ }
+
+ /*
+ * There is no support for non-banked GICv1/2 register in ACPI
+ * spec. All CPU interface addresses have to be the same.
+ */
+ gic_cpu_base = per_cpu(gic_percpu_cpu_base, 0);
+ for_each_cpu (cpu, &gic_acpi_cpu_mask) {
+ if (gic_cpu_base != per_cpu(gic_percpu_cpu_base, cpu)) {
+ printk("GICC addresses are different, no support"
+ "for non-banked GICC registers !!!\n");
+ gic_cpu_base = 0;
+ goto madt_cpu_base;
+ }
+ }
+ }
+
+madt_cpu_base:
+ /* If no GICC address provided, use address from MADT header */
+ if (!gic_cpu_base) {
+ if (!madt_cpu_addr) {
+ printk("Unable to find GICC address\n");
+ return -EINVAL;
+ }
+
+ printk("Attempt to use Local Interrupt Controller Address"
+ "as GICC base address\n");
+ gic_cpu_base = madt_cpu_addr;
+ }
+
+ cpu_base = ioremap(gic_cpu_base, ACPI_GIC_CPU_IF_MEM_SIZE);
+ if (!cpu_base) {
+ printk("Unable to map GICC registers\n");
+ return -ENOMEM;
+ }
+
+ dist_base = ioremap(dist_phy_base, ACPI_GIC_DIST_MEM_SIZE);
+ if (!dist_base) {
+ printk("Unable to map GICD registers\n");
+ iounmap(cpu_base);
+ return -ENOMEM;
+ }
+
+ /*
+ * FIXME: Initialize zero GIC instance (no multi-GIC support) based on
+ * addresses obtained from MADT. Also, set GIC as default IRQ domain
+ * to allow for GSI registration and GSI to IRQ number translation
+ * (see acpi_register_gsi() and acpi_gsi_to_irq()).
+ *
+ * gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
+ * irq_set_default_host(gic_data[0].domain);
+ */
+
+ /* TODO: Add check on distributor, cpu size */
+
+ printk("GICv2 initialization from ACPI MADT table :\n"
+ " gic_dist_addr=%"PRIpaddr"\n"
+ " gic_cpu_addr=%"PRIpaddr"\n"
+ " gic_hyp_addr=%"PRIpaddr"\n"
+ " gic_vcpu_addr=%"PRIpaddr"\n"
+ " gic_maintenance_irq=%u\n",
+ gicv2.dbase, gicv2.cbase, gicv2.hbase, gicv2.vbase,
+ gicv2_info.maintenance_irq);
+
+ if ( (gicv2.dbase & ~PAGE_MASK) || (gicv2.cbase & ~PAGE_MASK) ||
+ (gicv2.hbase & ~PAGE_MASK) || (gicv2.vbase & ~PAGE_MASK) )
+ panic("GICv2 interfaces not page aligned");
+
+ gicv2.map_dbase = ioremap_nocache(gicv2.dbase, PAGE_SIZE);
+ if ( !gicv2.map_dbase )
+ panic("GICv2: Failed to ioremap for GIC distributor\n");
+
+ gicv2.map_cbase[0] = ioremap_nocache(gicv2.cbase, PAGE_SIZE);
+
+ if ( platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
+ gicv2.map_cbase[1] = ioremap_nocache(gicv2.cbase + PAGE_SIZE * 0x10,
+ PAGE_SIZE);
+ else
+ gicv2.map_cbase[1] = ioremap_nocache(gicv2.cbase + PAGE_SIZE, PAGE_SIZE);
+
+ if ( !gicv2.map_cbase[0] || !gicv2.map_cbase[1] )
+ panic("GICv2: Failed to ioremap for GIC CPU interface\n");
+
+ gicv2.map_hbase = ioremap_nocache(gicv2.hbase, PAGE_SIZE);
+ if ( !gicv2.map_hbase )
+ panic("GICv2: Failed to ioremap for GIC Virtual interface\n");
+
+ /* Global settings: interrupt distributor */
+ spin_lock_init(&gicv2.lock);
+ spin_lock(&gicv2.lock);
+
+ gicv2_dist_init();
+ gicv2_cpu_init();
+ gicv2_hyp_init();
+
+ spin_unlock(&gicv2.lock);
+
+ gicv2_info.hw_version = GIC_V2;
+ register_gic_ops(&gicv2_ops);
+
+ return 0;
+}
+
+int __init
+gic_v2_acpi_init(struct acpi_table_header *table)
+{
+ struct acpi_table_madt *madt;
+ int count;
+
+ /* Collect CPU base addresses */
+ count = acpi_parse_entries(sizeof(struct acpi_table_madt),
+ gic_acpi_parse_madt_cpu, table,
+ ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+ MAX_GIC_CPU_INTERFACE);
+ if (count <= 0) {
+ printk("Error during GICC entries parsing\n");
+ return -EINVAL;
+ }
+
+ /*
+ * Find distributor base address. We expect one distributor entry since
+ * ACPI 5.0 spec neither support multi-GIC instances nor GIC cascade.
+ */
+ count = acpi_parse_entries(sizeof(struct acpi_table_madt),
+ gic_acpi_parse_madt_distributor, table,
+ ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
+ MAX_GIC_DISTRIBUTOR);
+ if (count <= 0) {
+ printk("Error during GICD entries parsing\n");
+ return -EINVAL;
+ }
+
+ madt = (struct acpi_table_madt *)table;
+ return gic_acpi_validate_init((u64)madt->address);
+}
+
+static int __init acpi_parse_madt(struct acpi_table_header *table)
+{
+ struct acpi_table_madt *madt = NULL;
+ madt = (struct acpi_table_madt *)table;
+
+ if (!madt)
+ return 1;
+ else
+ printk("Local APIC address 0x%08x\n", madt->address);
+
+ return 0;
+}
+
+int __init acpi_gic_init()
+{
+ acpi_status status;
+ int err;
+
+ status = acpi_table_parse(ACPI_SIG_MADT, acpi_parse_madt);
+
+ if (ACPI_FAILURE(status)) {
+ const char *msg = acpi_format_exception(status);
+ printk("\nFailed to get MADT table, %s\n", msg);
+ return 1;
+ }
+
+ err = acpi_table_parse(ACPI_SIG_MADT, gic_v2_acpi_init);
+ if (err)
+ printk("\nFailed to initialize GIC IRQ controller\n");
+
+ return 0;
+}
+#endif
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 317b985..93c8a8a 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -784,11 +784,12 @@ void __init start_xen(unsigned long boot_phys_offset,
/* Comment for now take it after GIC initialization */
#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
init_xen_acpi_time();
+ acpi_gic_init();
#else
init_xen_time();
+ gic_init();
#endif
- gic_init();
p2m_vmid_allocator_init();
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index c2d25db..01ce28d 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -106,5 +106,7 @@ static inline void acpi_disable_pci(void)
#endif
#define MAX_GIC_CPU_INTERFACE 65535
+#define MAX_GIC_DISTRIBUTOR 1 /* should be the same as MAX_GIC_NR */
+extern int __init acpi_gic_init(void);
#endif /*_ASM_ARM_ACPI_H*/
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support
2015-02-04 14:02 ` [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support parth.dixit
@ 2015-02-04 14:43 ` G Gregory
2015-02-05 6:26 ` Parth Dixit
2015-02-05 3:41 ` Julien Grall
2015-02-05 15:54 ` Stefano Stabellini
2 siblings, 1 reply; 166+ messages in thread
From: G Gregory @ 2015-02-04 14:43 UTC (permalink / raw)
To: Parth Dixit
Cc: Ian Campbell, Naresh Bhat, Julien Grall, tim, Tomasz Nowicki,
xen-devel, Stefano Stabellini, Hanjun Guo, jbeulich,
Christoffer Dall
On 4 February 2015 at 14:02, <parth.dixit@linaro.org> wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
> It needs to parse GIC related subtables, collect CPU interface and distributor
> addresses and call driver initialization function (which is hardware
> abstraction agnostic). In a similar way, FDT initialize GICv1/2.
>
> NOTE: This commit allow to initialize GICv1/2 only.
>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
I do not recognise any of the code here and I'm pretty sure I have not
worked on any of it. I am unsure what the rules on Signed-off-by: is
but I think this one is wrong.
Graeme
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>
> Conflicts:
>
> xen/arch/arm/irq.c
> ---
> xen/arch/arm/gic-v2.c | 271 +++++++++++++++++++++++++++++++++++++++++++++
> xen/arch/arm/setup.c | 3 +-
> xen/include/asm-arm/acpi.h | 2 +
> 3 files changed, 275 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index faad1ff..cb1d205 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -777,6 +777,277 @@ DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
> .init = gicv2_init,
> DT_DEVICE_END
>
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> +
> +#include <xen/acpi.h>
> +#include <xen/errno.h>
> +#include <xen/vmap.h>
> +#include <asm/acpi.h>
> +
> +/*
> + * Hard code here, we can not get memory size from MADT (but FDT does),
> + * this size can be inferred from GICv2 spec
> + */
> +
> +#define ACPI_GIC_DIST_MEM_SIZE 0x00010000 // (SZ_64K)
> +#define ACPI_GIC_CPU_IF_MEM_SIZE 0x00002000 // (SZ_8K)
> +
> +static DEFINE_PER_CPU(u64, gic_percpu_cpu_base);
> +static cpumask_t gic_acpi_cpu_mask;
> +static u64 dist_phy_base;
> +
> +static int __init
> +gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_interrupt *processor;
> + unsigned int cpu;
> +
> + processor = (struct acpi_madt_generic_interrupt *)header;
> +
> + if (BAD_MADT_ENTRY(processor, end))
> + return -EINVAL;
> + for_each_possible_cpu(cpu) {
> + /*
> + * FIXME: This condition is failing.
> + * In Xen we first want to bring/initialize the GIC in hypervisor with single CPU
> + * if (processor->mpidr == cpu_logical_map(cpu))
> + */
> + goto find;
> + }
> +
> + printk("\nUnable to find CPU corresponding to GIC CPU entry [mpdir %lx]\n",
> + (long)processor->mpidr);
> +
> + return 0;
> +
> +find:
> + /* Read from APIC table and fill up the GIC variables */
> + gicv2.dbase = processor->redist_base_address;
> + gicv2.cbase = processor->base_address;
> + gicv2.hbase = processor->gich_base_address;
> + gicv2.vbase = processor->gicv_base_address;
> + gicv2_info.maintenance_irq = processor->vgic_maintenance_interrupt;
> + if( processor->flags & ACPI_MADT_ENABLED )
> + {
> + if( processor->flags & ACPI_MADT_VGIC )
> + acpi_set_irq(gicv2_info.maintenance_irq, DT_IRQ_TYPE_EDGE_BOTH);
> + else
> + acpi_set_irq(gicv2_info.maintenance_irq, DT_IRQ_TYPE_LEVEL_MASK);
> + }
> +
> + /*
> + * Do not validate CPU i/f base, we can still use "Local Interrupt
> + * Controller Address" from MADT header instead.
> + */
> + per_cpu(gic_percpu_cpu_base, cpu) = processor->base_address;
> + cpumask_set_cpu(cpu, &gic_acpi_cpu_mask);
> +
> + return 0;
> +}
> +
> +static int __init
> +gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_distributor *dist;
> +
> + dist = (struct acpi_madt_generic_distributor *)header;
> +
> + if (BAD_MADT_ENTRY(dist, end))
> + return -EINVAL;
> +
> + dist_phy_base = dist->base_address;
> +
> + return 0;
> +}
> +
> +static int gic_acpi_validate_init(u64 madt_cpu_addr)
> +{
> + void __iomem *cpu_base, *dist_base;
> + u64 gic_cpu_base = 0;
> + unsigned int cpu;
> +
> + /* Process all GICC entries delivered by MADT */
> + if (!cpumask_empty(&gic_acpi_cpu_mask)) {
> + /*
> + * If MADT contains at least one GICC entry, it must be BSP
> + * dedicated.
> + */
> + if (!cpumask_test_cpu(0, &gic_acpi_cpu_mask)) {
> + printk("GICC entries exist but unable to find BSP GICC "
> + "address\n");
> + goto madt_cpu_base;
> + }
> +
> + /*
> + * There is no support for non-banked GICv1/2 register in ACPI
> + * spec. All CPU interface addresses have to be the same.
> + */
> + gic_cpu_base = per_cpu(gic_percpu_cpu_base, 0);
> + for_each_cpu (cpu, &gic_acpi_cpu_mask) {
> + if (gic_cpu_base != per_cpu(gic_percpu_cpu_base, cpu)) {
> + printk("GICC addresses are different, no support"
> + "for non-banked GICC registers !!!\n");
> + gic_cpu_base = 0;
> + goto madt_cpu_base;
> + }
> + }
> + }
> +
> +madt_cpu_base:
> + /* If no GICC address provided, use address from MADT header */
> + if (!gic_cpu_base) {
> + if (!madt_cpu_addr) {
> + printk("Unable to find GICC address\n");
> + return -EINVAL;
> + }
> +
> + printk("Attempt to use Local Interrupt Controller Address"
> + "as GICC base address\n");
> + gic_cpu_base = madt_cpu_addr;
> + }
> +
> + cpu_base = ioremap(gic_cpu_base, ACPI_GIC_CPU_IF_MEM_SIZE);
> + if (!cpu_base) {
> + printk("Unable to map GICC registers\n");
> + return -ENOMEM;
> + }
> +
> + dist_base = ioremap(dist_phy_base, ACPI_GIC_DIST_MEM_SIZE);
> + if (!dist_base) {
> + printk("Unable to map GICD registers\n");
> + iounmap(cpu_base);
> + return -ENOMEM;
> + }
> +
> + /*
> + * FIXME: Initialize zero GIC instance (no multi-GIC support) based on
> + * addresses obtained from MADT. Also, set GIC as default IRQ domain
> + * to allow for GSI registration and GSI to IRQ number translation
> + * (see acpi_register_gsi() and acpi_gsi_to_irq()).
> + *
> + * gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
> + * irq_set_default_host(gic_data[0].domain);
> + */
> +
> + /* TODO: Add check on distributor, cpu size */
> +
> + printk("GICv2 initialization from ACPI MADT table :\n"
> + " gic_dist_addr=%"PRIpaddr"\n"
> + " gic_cpu_addr=%"PRIpaddr"\n"
> + " gic_hyp_addr=%"PRIpaddr"\n"
> + " gic_vcpu_addr=%"PRIpaddr"\n"
> + " gic_maintenance_irq=%u\n",
> + gicv2.dbase, gicv2.cbase, gicv2.hbase, gicv2.vbase,
> + gicv2_info.maintenance_irq);
> +
> + if ( (gicv2.dbase & ~PAGE_MASK) || (gicv2.cbase & ~PAGE_MASK) ||
> + (gicv2.hbase & ~PAGE_MASK) || (gicv2.vbase & ~PAGE_MASK) )
> + panic("GICv2 interfaces not page aligned");
> +
> + gicv2.map_dbase = ioremap_nocache(gicv2.dbase, PAGE_SIZE);
> + if ( !gicv2.map_dbase )
> + panic("GICv2: Failed to ioremap for GIC distributor\n");
> +
> + gicv2.map_cbase[0] = ioremap_nocache(gicv2.cbase, PAGE_SIZE);
> +
> + if ( platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
> + gicv2.map_cbase[1] = ioremap_nocache(gicv2.cbase + PAGE_SIZE * 0x10,
> + PAGE_SIZE);
> + else
> + gicv2.map_cbase[1] = ioremap_nocache(gicv2.cbase + PAGE_SIZE, PAGE_SIZE);
> +
> + if ( !gicv2.map_cbase[0] || !gicv2.map_cbase[1] )
> + panic("GICv2: Failed to ioremap for GIC CPU interface\n");
> +
> + gicv2.map_hbase = ioremap_nocache(gicv2.hbase, PAGE_SIZE);
> + if ( !gicv2.map_hbase )
> + panic("GICv2: Failed to ioremap for GIC Virtual interface\n");
> +
> + /* Global settings: interrupt distributor */
> + spin_lock_init(&gicv2.lock);
> + spin_lock(&gicv2.lock);
> +
> + gicv2_dist_init();
> + gicv2_cpu_init();
> + gicv2_hyp_init();
> +
> + spin_unlock(&gicv2.lock);
> +
> + gicv2_info.hw_version = GIC_V2;
> + register_gic_ops(&gicv2_ops);
> +
> + return 0;
> +}
> +
> +int __init
> +gic_v2_acpi_init(struct acpi_table_header *table)
> +{
> + struct acpi_table_madt *madt;
> + int count;
> +
> + /* Collect CPU base addresses */
> + count = acpi_parse_entries(sizeof(struct acpi_table_madt),
> + gic_acpi_parse_madt_cpu, table,
> + ACPI_MADT_TYPE_GENERIC_INTERRUPT,
> + MAX_GIC_CPU_INTERFACE);
> + if (count <= 0) {
> + printk("Error during GICC entries parsing\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * Find distributor base address. We expect one distributor entry since
> + * ACPI 5.0 spec neither support multi-GIC instances nor GIC cascade.
> + */
> + count = acpi_parse_entries(sizeof(struct acpi_table_madt),
> + gic_acpi_parse_madt_distributor, table,
> + ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
> + MAX_GIC_DISTRIBUTOR);
> + if (count <= 0) {
> + printk("Error during GICD entries parsing\n");
> + return -EINVAL;
> + }
> +
> + madt = (struct acpi_table_madt *)table;
> + return gic_acpi_validate_init((u64)madt->address);
> +}
> +
> +static int __init acpi_parse_madt(struct acpi_table_header *table)
> +{
> + struct acpi_table_madt *madt = NULL;
> + madt = (struct acpi_table_madt *)table;
> +
> + if (!madt)
> + return 1;
> + else
> + printk("Local APIC address 0x%08x\n", madt->address);
> +
> + return 0;
> +}
> +
> +int __init acpi_gic_init()
> +{
> + acpi_status status;
> + int err;
> +
> + status = acpi_table_parse(ACPI_SIG_MADT, acpi_parse_madt);
> +
> + if (ACPI_FAILURE(status)) {
> + const char *msg = acpi_format_exception(status);
> + printk("\nFailed to get MADT table, %s\n", msg);
> + return 1;
> + }
> +
> + err = acpi_table_parse(ACPI_SIG_MADT, gic_v2_acpi_init);
> + if (err)
> + printk("\nFailed to initialize GIC IRQ controller\n");
> +
> + return 0;
> +}
> +#endif
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 317b985..93c8a8a 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -784,11 +784,12 @@ void __init start_xen(unsigned long boot_phys_offset,
> /* Comment for now take it after GIC initialization */
> #if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
> init_xen_acpi_time();
> + acpi_gic_init();
> #else
> init_xen_time();
> + gic_init();
> #endif
>
> - gic_init();
>
> p2m_vmid_allocator_init();
>
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> index c2d25db..01ce28d 100644
> --- a/xen/include/asm-arm/acpi.h
> +++ b/xen/include/asm-arm/acpi.h
> @@ -106,5 +106,7 @@ static inline void acpi_disable_pci(void)
> #endif
>
> #define MAX_GIC_CPU_INTERFACE 65535
> +#define MAX_GIC_DISTRIBUTOR 1 /* should be the same as MAX_GIC_NR */
> +extern int __init acpi_gic_init(void);
>
> #endif /*_ASM_ARM_ACPI_H*/
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support
2015-02-04 14:43 ` G Gregory
@ 2015-02-05 6:26 ` Parth Dixit
0 siblings, 0 replies; 166+ messages in thread
From: Parth Dixit @ 2015-02-05 6:26 UTC (permalink / raw)
To: G Gregory
Cc: Ian Campbell, Naresh Bhat, Julien Grall, tim, Tomasz Nowicki,
xen-devel, Stefano Stabellini, Hanjun Guo, Jan Beulich,
Christoffer Dall
On 4 February 2015 at 20:13, G Gregory <graeme.gregory@linaro.org> wrote:
> On 4 February 2015 at 14:02, <parth.dixit@linaro.org> wrote:
>> From: Naresh Bhat <naresh.bhat@linaro.org>
>>
>> ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
>> It needs to parse GIC related subtables, collect CPU interface and distributor
>> addresses and call driver initialization function (which is hardware
>> abstraction agnostic). In a similar way, FDT initialize GICv1/2.
>>
>> NOTE: This commit allow to initialize GICv1/2 only.
>>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>
> I do not recognise any of the code here and I'm pretty sure I have not
> worked on any of it. I am unsure what the rules on Signed-off-by: is
> but I think this one is wrong.
>
> Graeme
I will remove it. I inherited this patch from naresh with your
signoff , so i did not removed it. Thanks for alerting me.
Policy is to not remove the previous signoff's in a patch and add
signoff only in case
some logical change is made to the patch.
Parth
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>>
>> Conflicts:
>>
>> xen/arch/arm/irq.c
>> ---
>> xen/arch/arm/gic-v2.c | 271 +++++++++++++++++++++++++++++++++++++++++++++
>> xen/arch/arm/setup.c | 3 +-
>> xen/include/asm-arm/acpi.h | 2 +
>> 3 files changed, 275 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index faad1ff..cb1d205 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -777,6 +777,277 @@ DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
>> .init = gicv2_init,
>> DT_DEVICE_END
>>
>> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>> +
>> +#include <xen/acpi.h>
>> +#include <xen/errno.h>
>> +#include <xen/vmap.h>
>> +#include <asm/acpi.h>
>> +
>> +/*
>> + * Hard code here, we can not get memory size from MADT (but FDT does),
>> + * this size can be inferred from GICv2 spec
>> + */
>> +
>> +#define ACPI_GIC_DIST_MEM_SIZE 0x00010000 // (SZ_64K)
>> +#define ACPI_GIC_CPU_IF_MEM_SIZE 0x00002000 // (SZ_8K)
>> +
>> +static DEFINE_PER_CPU(u64, gic_percpu_cpu_base);
>> +static cpumask_t gic_acpi_cpu_mask;
>> +static u64 dist_phy_base;
>> +
>> +static int __init
>> +gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
>> + const unsigned long end)
>> +{
>> + struct acpi_madt_generic_interrupt *processor;
>> + unsigned int cpu;
>> +
>> + processor = (struct acpi_madt_generic_interrupt *)header;
>> +
>> + if (BAD_MADT_ENTRY(processor, end))
>> + return -EINVAL;
>> + for_each_possible_cpu(cpu) {
>> + /*
>> + * FIXME: This condition is failing.
>> + * In Xen we first want to bring/initialize the GIC in hypervisor with single CPU
>> + * if (processor->mpidr == cpu_logical_map(cpu))
>> + */
>> + goto find;
>> + }
>> +
>> + printk("\nUnable to find CPU corresponding to GIC CPU entry [mpdir %lx]\n",
>> + (long)processor->mpidr);
>> +
>> + return 0;
>> +
>> +find:
>> + /* Read from APIC table and fill up the GIC variables */
>> + gicv2.dbase = processor->redist_base_address;
>> + gicv2.cbase = processor->base_address;
>> + gicv2.hbase = processor->gich_base_address;
>> + gicv2.vbase = processor->gicv_base_address;
>> + gicv2_info.maintenance_irq = processor->vgic_maintenance_interrupt;
>> + if( processor->flags & ACPI_MADT_ENABLED )
>> + {
>> + if( processor->flags & ACPI_MADT_VGIC )
>> + acpi_set_irq(gicv2_info.maintenance_irq, DT_IRQ_TYPE_EDGE_BOTH);
>> + else
>> + acpi_set_irq(gicv2_info.maintenance_irq, DT_IRQ_TYPE_LEVEL_MASK);
>> + }
>> +
>> + /*
>> + * Do not validate CPU i/f base, we can still use "Local Interrupt
>> + * Controller Address" from MADT header instead.
>> + */
>> + per_cpu(gic_percpu_cpu_base, cpu) = processor->base_address;
>> + cpumask_set_cpu(cpu, &gic_acpi_cpu_mask);
>> +
>> + return 0;
>> +}
>> +
>> +static int __init
>> +gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
>> + const unsigned long end)
>> +{
>> + struct acpi_madt_generic_distributor *dist;
>> +
>> + dist = (struct acpi_madt_generic_distributor *)header;
>> +
>> + if (BAD_MADT_ENTRY(dist, end))
>> + return -EINVAL;
>> +
>> + dist_phy_base = dist->base_address;
>> +
>> + return 0;
>> +}
>> +
>> +static int gic_acpi_validate_init(u64 madt_cpu_addr)
>> +{
>> + void __iomem *cpu_base, *dist_base;
>> + u64 gic_cpu_base = 0;
>> + unsigned int cpu;
>> +
>> + /* Process all GICC entries delivered by MADT */
>> + if (!cpumask_empty(&gic_acpi_cpu_mask)) {
>> + /*
>> + * If MADT contains at least one GICC entry, it must be BSP
>> + * dedicated.
>> + */
>> + if (!cpumask_test_cpu(0, &gic_acpi_cpu_mask)) {
>> + printk("GICC entries exist but unable to find BSP GICC "
>> + "address\n");
>> + goto madt_cpu_base;
>> + }
>> +
>> + /*
>> + * There is no support for non-banked GICv1/2 register in ACPI
>> + * spec. All CPU interface addresses have to be the same.
>> + */
>> + gic_cpu_base = per_cpu(gic_percpu_cpu_base, 0);
>> + for_each_cpu (cpu, &gic_acpi_cpu_mask) {
>> + if (gic_cpu_base != per_cpu(gic_percpu_cpu_base, cpu)) {
>> + printk("GICC addresses are different, no support"
>> + "for non-banked GICC registers !!!\n");
>> + gic_cpu_base = 0;
>> + goto madt_cpu_base;
>> + }
>> + }
>> + }
>> +
>> +madt_cpu_base:
>> + /* If no GICC address provided, use address from MADT header */
>> + if (!gic_cpu_base) {
>> + if (!madt_cpu_addr) {
>> + printk("Unable to find GICC address\n");
>> + return -EINVAL;
>> + }
>> +
>> + printk("Attempt to use Local Interrupt Controller Address"
>> + "as GICC base address\n");
>> + gic_cpu_base = madt_cpu_addr;
>> + }
>> +
>> + cpu_base = ioremap(gic_cpu_base, ACPI_GIC_CPU_IF_MEM_SIZE);
>> + if (!cpu_base) {
>> + printk("Unable to map GICC registers\n");
>> + return -ENOMEM;
>> + }
>> +
>> + dist_base = ioremap(dist_phy_base, ACPI_GIC_DIST_MEM_SIZE);
>> + if (!dist_base) {
>> + printk("Unable to map GICD registers\n");
>> + iounmap(cpu_base);
>> + return -ENOMEM;
>> + }
>> +
>> + /*
>> + * FIXME: Initialize zero GIC instance (no multi-GIC support) based on
>> + * addresses obtained from MADT. Also, set GIC as default IRQ domain
>> + * to allow for GSI registration and GSI to IRQ number translation
>> + * (see acpi_register_gsi() and acpi_gsi_to_irq()).
>> + *
>> + * gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
>> + * irq_set_default_host(gic_data[0].domain);
>> + */
>> +
>> + /* TODO: Add check on distributor, cpu size */
>> +
>> + printk("GICv2 initialization from ACPI MADT table :\n"
>> + " gic_dist_addr=%"PRIpaddr"\n"
>> + " gic_cpu_addr=%"PRIpaddr"\n"
>> + " gic_hyp_addr=%"PRIpaddr"\n"
>> + " gic_vcpu_addr=%"PRIpaddr"\n"
>> + " gic_maintenance_irq=%u\n",
>> + gicv2.dbase, gicv2.cbase, gicv2.hbase, gicv2.vbase,
>> + gicv2_info.maintenance_irq);
>> +
>> + if ( (gicv2.dbase & ~PAGE_MASK) || (gicv2.cbase & ~PAGE_MASK) ||
>> + (gicv2.hbase & ~PAGE_MASK) || (gicv2.vbase & ~PAGE_MASK) )
>> + panic("GICv2 interfaces not page aligned");
>> +
>> + gicv2.map_dbase = ioremap_nocache(gicv2.dbase, PAGE_SIZE);
>> + if ( !gicv2.map_dbase )
>> + panic("GICv2: Failed to ioremap for GIC distributor\n");
>> +
>> + gicv2.map_cbase[0] = ioremap_nocache(gicv2.cbase, PAGE_SIZE);
>> +
>> + if ( platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
>> + gicv2.map_cbase[1] = ioremap_nocache(gicv2.cbase + PAGE_SIZE * 0x10,
>> + PAGE_SIZE);
>> + else
>> + gicv2.map_cbase[1] = ioremap_nocache(gicv2.cbase + PAGE_SIZE, PAGE_SIZE);
>> +
>> + if ( !gicv2.map_cbase[0] || !gicv2.map_cbase[1] )
>> + panic("GICv2: Failed to ioremap for GIC CPU interface\n");
>> +
>> + gicv2.map_hbase = ioremap_nocache(gicv2.hbase, PAGE_SIZE);
>> + if ( !gicv2.map_hbase )
>> + panic("GICv2: Failed to ioremap for GIC Virtual interface\n");
>> +
>> + /* Global settings: interrupt distributor */
>> + spin_lock_init(&gicv2.lock);
>> + spin_lock(&gicv2.lock);
>> +
>> + gicv2_dist_init();
>> + gicv2_cpu_init();
>> + gicv2_hyp_init();
>> +
>> + spin_unlock(&gicv2.lock);
>> +
>> + gicv2_info.hw_version = GIC_V2;
>> + register_gic_ops(&gicv2_ops);
>> +
>> + return 0;
>> +}
>> +
>> +int __init
>> +gic_v2_acpi_init(struct acpi_table_header *table)
>> +{
>> + struct acpi_table_madt *madt;
>> + int count;
>> +
>> + /* Collect CPU base addresses */
>> + count = acpi_parse_entries(sizeof(struct acpi_table_madt),
>> + gic_acpi_parse_madt_cpu, table,
>> + ACPI_MADT_TYPE_GENERIC_INTERRUPT,
>> + MAX_GIC_CPU_INTERFACE);
>> + if (count <= 0) {
>> + printk("Error during GICC entries parsing\n");
>> + return -EINVAL;
>> + }
>> +
>> + /*
>> + * Find distributor base address. We expect one distributor entry since
>> + * ACPI 5.0 spec neither support multi-GIC instances nor GIC cascade.
>> + */
>> + count = acpi_parse_entries(sizeof(struct acpi_table_madt),
>> + gic_acpi_parse_madt_distributor, table,
>> + ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
>> + MAX_GIC_DISTRIBUTOR);
>> + if (count <= 0) {
>> + printk("Error during GICD entries parsing\n");
>> + return -EINVAL;
>> + }
>> +
>> + madt = (struct acpi_table_madt *)table;
>> + return gic_acpi_validate_init((u64)madt->address);
>> +}
>> +
>> +static int __init acpi_parse_madt(struct acpi_table_header *table)
>> +{
>> + struct acpi_table_madt *madt = NULL;
>> + madt = (struct acpi_table_madt *)table;
>> +
>> + if (!madt)
>> + return 1;
>> + else
>> + printk("Local APIC address 0x%08x\n", madt->address);
>> +
>> + return 0;
>> +}
>> +
>> +int __init acpi_gic_init()
>> +{
>> + acpi_status status;
>> + int err;
>> +
>> + status = acpi_table_parse(ACPI_SIG_MADT, acpi_parse_madt);
>> +
>> + if (ACPI_FAILURE(status)) {
>> + const char *msg = acpi_format_exception(status);
>> + printk("\nFailed to get MADT table, %s\n", msg);
>> + return 1;
>> + }
>> +
>> + err = acpi_table_parse(ACPI_SIG_MADT, gic_v2_acpi_init);
>> + if (err)
>> + printk("\nFailed to initialize GIC IRQ controller\n");
>> +
>> + return 0;
>> +}
>> +#endif
>> +
>> /*
>> * Local variables:
>> * mode: C
>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> index 317b985..93c8a8a 100644
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -784,11 +784,12 @@ void __init start_xen(unsigned long boot_phys_offset,
>> /* Comment for now take it after GIC initialization */
>> #if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
>> init_xen_acpi_time();
>> + acpi_gic_init();
>> #else
>> init_xen_time();
>> + gic_init();
>> #endif
>>
>> - gic_init();
>>
>> p2m_vmid_allocator_init();
>>
>> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
>> index c2d25db..01ce28d 100644
>> --- a/xen/include/asm-arm/acpi.h
>> +++ b/xen/include/asm-arm/acpi.h
>> @@ -106,5 +106,7 @@ static inline void acpi_disable_pci(void)
>> #endif
>>
>> #define MAX_GIC_CPU_INTERFACE 65535
>> +#define MAX_GIC_DISTRIBUTOR 1 /* should be the same as MAX_GIC_NR */
>> +extern int __init acpi_gic_init(void);
>>
>> #endif /*_ASM_ARM_ACPI_H*/
>> --
>> 1.9.1
>>
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support
2015-02-04 14:02 ` [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support parth.dixit
2015-02-04 14:43 ` G Gregory
@ 2015-02-05 3:41 ` Julien Grall
2015-02-05 15:54 ` Stefano Stabellini
2 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-05 3:41 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Graeme Gregory, Naresh Bhat, tim, Tomasz Nowicki,
stefano.stabellini, Hanjun Guo, jbeulich, christoffer.dall
Hi Parth,
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
> It needs to parse GIC related subtables, collect CPU interface and distributor
> addresses and call driver initialization function (which is hardware
> abstraction agnostic). In a similar way, FDT initialize GICv1/2.
No need to spec about GICv1, we don't support it on Xen.
> NOTE: This commit allow to initialize GICv1/2 only.
Ditto.
>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>
> Conflicts:
>
> xen/arch/arm/irq.c
This may have come via a conflicted merge.
> ---
> xen/arch/arm/gic-v2.c | 271 +++++++++++++++++++++++++++++++++++++++++++++
> xen/arch/arm/setup.c | 3 +-
> xen/include/asm-arm/acpi.h | 2 +
> 3 files changed, 275 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index faad1ff..cb1d205 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -777,6 +777,277 @@ DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
> .init = gicv2_init,
> DT_DEVICE_END
>
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> +
> +#include <xen/acpi.h>
> +#include <xen/errno.h>
> +#include <xen/vmap.h>
> +#include <asm/acpi.h>
Please no include in the middle of the file.
> +
> +/*
> + * Hard code here, we can not get memory size from MADT (but FDT does),
> + * this size can be inferred from GICv2 spec
> + */
> +
> +#define ACPI_GIC_DIST_MEM_SIZE 0x00010000 // (SZ_64K)
> +#define ACPI_GIC_CPU_IF_MEM_SIZE 0x00002000 // (SZ_8K)
Why don't you use the proper define (SZ_64K/SZ_8k) rather than
hardcoding it?
> +
> +static DEFINE_PER_CPU(u64, gic_percpu_cpu_base);
> +static cpumask_t gic_acpi_cpu_mask;
> +static u64 dist_phy_base;
> +
> +static int __init
> +gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_interrupt *processor;
> + unsigned int cpu;
> +
> + processor = (struct acpi_madt_generic_interrupt *)header;
> +
> + if (BAD_MADT_ENTRY(processor, end))
if ( ... )
> + return -EINVAL;
> + for_each_possible_cpu(cpu) {
for_each_possible( ... )
{
Please checking the coding style within this patch. I won't tell more
foo ( ... )
{
in this patch.
> + /*
> + * FIXME: This condition is failing.
> + * In Xen we first want to bring/initialize the GIC in hypervisor with single CPU
> + * if (processor->mpidr == cpu_logical_map(cpu))
> + */
> + goto find;
> + }
Looking at the code in this function, this whole loop doesn't seem
useful. It make the code more complicate to read. Why don't you validate
directly the GIC addresses in this function?
This is what Linux does and it's divide by 5 the produced code.
> +
> + printk("\nUnable to find CPU corresponding to GIC CPU entry [mpdir %lx]\n",
> + (long)processor->mpidr);
> +
> + return 0;
> +
> +find:
> + /* Read from APIC table and fill up the GIC variables */
> + gicv2.dbase = processor->redist_base_address;
> + gicv2.cbase = processor->base_address;
> + gicv2.hbase = processor->gich_base_address;
> + gicv2.vbase = processor->gicv_base_address;
> + gicv2_info.maintenance_irq = processor->vgic_maintenance_interrupt;
> + if( processor->flags & ACPI_MADT_ENABLED )
> + {
> + if( processor->flags & ACPI_MADT_VGIC )
> + acpi_set_irq(gicv2_info.maintenance_irq, DT_IRQ_TYPE_EDGE_BOTH);
> + else
> + acpi_set_irq(gicv2_info.maintenance_irq, DT_IRQ_TYPE_LEVEL_MASK);
> + }
> +
> + /*
> + * Do not validate CPU i/f base, we can still use "Local Interrupt
> + * Controller Address" from MADT header instead.
> + */
> + per_cpu(gic_percpu_cpu_base, cpu) = processor->base_address;
> + cpumask_set_cpu(cpu, &gic_acpi_cpu_mask);
> +
> + return 0;
> +}
> +
> +static int __init
> +gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_distributor *dist;
> +
> + dist = (struct acpi_madt_generic_distributor *)header;
> +
> + if (BAD_MADT_ENTRY(dist, end))
> + return -EINVAL;
> +
> + dist_phy_base = dist->base_address;
> +
> + return 0;
> +}
> +
> +static int gic_acpi_validate_init(u64 madt_cpu_addr)
> +{
> + void __iomem *cpu_base, *dist_base;
> + u64 gic_cpu_base = 0;
> + unsigned int cpu;
> +
> + /* Process all GICC entries delivered by MADT */
> + if (!cpumask_empty(&gic_acpi_cpu_mask)) {
> + /*
> + * If MADT contains at least one GICC entry, it must be BSP
> + * dedicated.
> + */
> + if (!cpumask_test_cpu(0, &gic_acpi_cpu_mask)) {
> + printk("GICC entries exist but unable to find BSP GICC "
> + "address\n");
> + goto madt_cpu_base;
> + }
> +
> + /*
> + * There is no support for non-banked GICv1/2 register in ACPI
> + * spec. All CPU interface addresses have to be the same.
> + */
> + gic_cpu_base = per_cpu(gic_percpu_cpu_base, 0);
> + for_each_cpu (cpu, &gic_acpi_cpu_mask) {
> + if (gic_cpu_base != per_cpu(gic_percpu_cpu_base, cpu)) {
> + printk("GICC addresses are different, no support"
> + "for non-banked GICC registers !!!\n");
> + gic_cpu_base = 0;
> + goto madt_cpu_base;
> + }
> + }
> + }
Based on what I say above, this could be validate when fetch the GICC
information.
> +
> +madt_cpu_base:
> + /* If no GICC address provided, use address from MADT header */
> + if (!gic_cpu_base) {
> + if (!madt_cpu_addr) {
> + printk("Unable to find GICC address\n");
> + return -EINVAL;
> + }
> +
> + printk("Attempt to use Local Interrupt Controller Address"
> + "as GICC base address\n");
> + gic_cpu_base = madt_cpu_addr;
> + }
> +
> + cpu_base = ioremap(gic_cpu_base, ACPI_GIC_CPU_IF_MEM_SIZE);
> + if (!cpu_base) {
> + printk("Unable to map GICC registers\n");
> + return -ENOMEM;
> + }
> +
> + dist_base = ioremap(dist_phy_base, ACPI_GIC_DIST_MEM_SIZE);
> + if (!dist_base) {
> + printk("Unable to map GICD registers\n");
> + iounmap(cpu_base);
> + return -ENOMEM;
> + }
> +
> + /*
> + * FIXME: Initialize zero GIC instance (no multi-GIC support) based on
> + * addresses obtained from MADT. Also, set GIC as default IRQ domain
> + * to allow for GSI registration and GSI to IRQ number translation
> + * (see acpi_register_gsi() and acpi_gsi_to_irq()).
> + *
> + * gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
> + * irq_set_default_host(gic_data[0].domain);
> + */
> +
> + /* TODO: Add check on distributor, cpu size */
Indentation ... All the code below could be shared with the DT version.
Please create an helper to avoid duplication.
> +
> + printk("GICv2 initialization from ACPI MADT table :\n"
> + " gic_dist_addr=%"PRIpaddr"\n"
> + " gic_cpu_addr=%"PRIpaddr"\n"
> + " gic_hyp_addr=%"PRIpaddr"\n"
> + " gic_vcpu_addr=%"PRIpaddr"\n"
> + " gic_maintenance_irq=%u\n",
> + gicv2.dbase, gicv2.cbase, gicv2.hbase, gicv2.vbase,
> + gicv2_info.maintenance_irq);
> +
> + if ( (gicv2.dbase & ~PAGE_MASK) || (gicv2.cbase & ~PAGE_MASK) ||
> + (gicv2.hbase & ~PAGE_MASK) || (gicv2.vbase & ~PAGE_MASK) )
> + panic("GICv2 interfaces not page aligned");
> +
> + gicv2.map_dbase = ioremap_nocache(gicv2.dbase, PAGE_SIZE);
> + if ( !gicv2.map_dbase )
> + panic("GICv2: Failed to ioremap for GIC distributor\n");
> +
> + gicv2.map_cbase[0] = ioremap_nocache(gicv2.cbase, PAGE_SIZE);
> +
> + if ( platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
> + gicv2.map_cbase[1] = ioremap_nocache(gicv2.cbase + PAGE_SIZE * 0x10,
> + PAGE_SIZE);
> + else
> + gicv2.map_cbase[1] = ioremap_nocache(gicv2.cbase + PAGE_SIZE, PAGE_SIZE);
> +
> + if ( !gicv2.map_cbase[0] || !gicv2.map_cbase[1] )
> + panic("GICv2: Failed to ioremap for GIC CPU interface\n");
> +
> + gicv2.map_hbase = ioremap_nocache(gicv2.hbase, PAGE_SIZE);
> + if ( !gicv2.map_hbase )
> + panic("GICv2: Failed to ioremap for GIC Virtual interface\n");
> +
> + /* Global settings: interrupt distributor */
> + spin_lock_init(&gicv2.lock);
> + spin_lock(&gicv2.lock);
> +
> + gicv2_dist_init();
> + gicv2_cpu_init();
> + gicv2_hyp_init();
> +
> + spin_unlock(&gicv2.lock);
> +
> + gicv2_info.hw_version = GIC_V2;
> + register_gic_ops(&gicv2_ops);
> +
> + return 0;
> +}
> +
> +int __init
> +gic_v2_acpi_init(struct acpi_table_header *table)
> +{
> + struct acpi_table_madt *madt;
> + int count;
> +
> + /* Collect CPU base addresses */
> + count = acpi_parse_entries(sizeof(struct acpi_table_madt),
> + gic_acpi_parse_madt_cpu, table,
> + ACPI_MADT_TYPE_GENERIC_INTERRUPT,
> + MAX_GIC_CPU_INTERFACE);
> + if (count <= 0) {
> + printk("Error during GICC entries parsing\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * Find distributor base address. We expect one distributor entry since
> + * ACPI 5.0 spec neither support multi-GIC instances nor GIC cascade.
> + */
> + count = acpi_parse_entries(sizeof(struct acpi_table_madt),
> + gic_acpi_parse_madt_distributor, table,
> + ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
> + MAX_GIC_DISTRIBUTOR);
> + if (count <= 0) {
> + printk("Error during GICD entries parsing\n");
> + return -EINVAL;
> + }
There should be only one Distributor. Please check count is always equal
to 1.
> +
> + madt = (struct acpi_table_madt *)table;
> + return gic_acpi_validate_init((u64)madt->address);
> +}
> +
> +static int __init acpi_parse_madt(struct acpi_table_header *table)
> +{
> + struct acpi_table_madt *madt = NULL;
> + madt = (struct acpi_table_madt *)table;
> +
> + if (!madt)
> + return 1;
> + else
> + printk("Local APIC address 0x%08x\n", madt->address);
> +
> + return 0;
> +}
> +
> +int __init acpi_gic_init()
> +{
> + acpi_status status;
> + int err;
> +
> + status = acpi_table_parse(ACPI_SIG_MADT, acpi_parse_madt);
> +
> + if (ACPI_FAILURE(status)) {
> + const char *msg = acpi_format_exception(status);
> + printk("\nFailed to get MADT table, %s\n", msg);
> + return 1;
> + }
> +
> + err = acpi_table_parse(ACPI_SIG_MADT, gic_v2_acpi_init);
> + if (err)
> + printk("\nFailed to initialize GIC IRQ controller\n");
> +
> + return 0;
> +}
I will make the same comment as on the UART driver. We should use a
generic framework (maybe base on device). This is more cleaner and will
make easy the support of GICv3/GICv2m.
> +#endif
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 317b985..93c8a8a 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -784,11 +784,12 @@ void __init start_xen(unsigned long boot_phys_offset,
> /* Comment for now take it after GIC initialization */
> #if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
> init_xen_acpi_time();
> + acpi_gic_init();
> #else
> init_xen_time();
> + gic_init();
> #endif
Same remark as the timer, a same binary should work for ACPI and DT.
gic_init should be able to know if we use ACPI or DT and, based on it,
correctly initialized the the GIC.
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> index c2d25db..01ce28d 100644
> --- a/xen/include/asm-arm/acpi.h
> +++ b/xen/include/asm-arm/acpi.h
> @@ -106,5 +106,7 @@ static inline void acpi_disable_pci(void)
> #endif
>
> #define MAX_GIC_CPU_INTERFACE 65535
> +#define MAX_GIC_DISTRIBUTOR 1 /* should be the same as MAX_GIC_NR */
> +extern int __init acpi_gic_init(void);
>
> #endif /*_ASM_ARM_ACPI_H*/
>
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support
2015-02-04 14:02 ` [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support parth.dixit
2015-02-04 14:43 ` G Gregory
2015-02-05 3:41 ` Julien Grall
@ 2015-02-05 15:54 ` Stefano Stabellini
2 siblings, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 15:54 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, Graeme Gregory, Naresh Bhat, julien.grall, tim,
Tomasz Nowicki, xen-devel, stefano.stabellini, Hanjun Guo,
jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
> It needs to parse GIC related subtables, collect CPU interface and distributor
> addresses and call driver initialization function (which is hardware
> abstraction agnostic). In a similar way, FDT initialize GICv1/2.
>
> NOTE: This commit allow to initialize GICv1/2 only.
>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>
> Conflicts:
>
> xen/arch/arm/irq.c
Remove this from the commit message
> xen/arch/arm/gic-v2.c | 271 +++++++++++++++++++++++++++++++++++++++++++++
> xen/arch/arm/setup.c | 3 +-
> xen/include/asm-arm/acpi.h | 2 +
> 3 files changed, 275 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index faad1ff..cb1d205 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -777,6 +777,277 @@ DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
> .init = gicv2_init,
> DT_DEVICE_END
>
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> +
> +#include <xen/acpi.h>
> +#include <xen/errno.h>
> +#include <xen/vmap.h>
> +#include <asm/acpi.h>
> +
> +/*
> + * Hard code here, we can not get memory size from MADT (but FDT does),
> + * this size can be inferred from GICv2 spec
> + */
> +
> +#define ACPI_GIC_DIST_MEM_SIZE 0x00010000 // (SZ_64K)
> +#define ACPI_GIC_CPU_IF_MEM_SIZE 0x00002000 // (SZ_8K)
> +
> +static DEFINE_PER_CPU(u64, gic_percpu_cpu_base);
> +static cpumask_t gic_acpi_cpu_mask;
> +static u64 dist_phy_base;
Could you reuse struct gicv2 and gicv2_info?
> +static int __init
> +gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_interrupt *processor;
> + unsigned int cpu;
> +
> + processor = (struct acpi_madt_generic_interrupt *)header;
> +
> + if (BAD_MADT_ENTRY(processor, end))
> + return -EINVAL;
> + for_each_possible_cpu(cpu) {
> + /*
> + * FIXME: This condition is failing.
> + * In Xen we first want to bring/initialize the GIC in hypervisor with single CPU
> + * if (processor->mpidr == cpu_logical_map(cpu))
> + */
> + goto find;
> + }
I don't understand, could you please elaborate?
> + printk("\nUnable to find CPU corresponding to GIC CPU entry [mpdir %lx]\n",
> + (long)processor->mpidr);
> +
> + return 0;
> +
> +find:
> + /* Read from APIC table and fill up the GIC variables */
> + gicv2.dbase = processor->redist_base_address;
> + gicv2.cbase = processor->base_address;
> + gicv2.hbase = processor->gich_base_address;
> + gicv2.vbase = processor->gicv_base_address;
> + gicv2_info.maintenance_irq = processor->vgic_maintenance_interrupt;
> + if( processor->flags & ACPI_MADT_ENABLED )
> + {
> + if( processor->flags & ACPI_MADT_VGIC )
> + acpi_set_irq(gicv2_info.maintenance_irq, DT_IRQ_TYPE_EDGE_BOTH);
> + else
> + acpi_set_irq(gicv2_info.maintenance_irq, DT_IRQ_TYPE_LEVEL_MASK);
please don't use DT_IRQ_TYPEs for acpi interrupt initialization
> + }
> +
> + /*
> + * Do not validate CPU i/f base, we can still use "Local Interrupt
> + * Controller Address" from MADT header instead.
> + */
> + per_cpu(gic_percpu_cpu_base, cpu) = processor->base_address;
> + cpumask_set_cpu(cpu, &gic_acpi_cpu_mask);
> +
> + return 0;
> +}
> +
> +static int __init
> +gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_distributor *dist;
> +
> + dist = (struct acpi_madt_generic_distributor *)header;
> +
> + if (BAD_MADT_ENTRY(dist, end))
> + return -EINVAL;
> +
> + dist_phy_base = dist->base_address;
> +
> + return 0;
> +}
> +
> +static int gic_acpi_validate_init(u64 madt_cpu_addr)
> +{
> + void __iomem *cpu_base, *dist_base;
> + u64 gic_cpu_base = 0;
> + unsigned int cpu;
> +
> + /* Process all GICC entries delivered by MADT */
> + if (!cpumask_empty(&gic_acpi_cpu_mask)) {
> + /*
> + * If MADT contains at least one GICC entry, it must be BSP
> + * dedicated.
> + */
> + if (!cpumask_test_cpu(0, &gic_acpi_cpu_mask)) {
> + printk("GICC entries exist but unable to find BSP GICC "
> + "address\n");
> + goto madt_cpu_base;
> + }
> +
> + /*
> + * There is no support for non-banked GICv1/2 register in ACPI
> + * spec. All CPU interface addresses have to be the same.
> + */
> + gic_cpu_base = per_cpu(gic_percpu_cpu_base, 0);
> + for_each_cpu (cpu, &gic_acpi_cpu_mask) {
> + if (gic_cpu_base != per_cpu(gic_percpu_cpu_base, cpu)) {
> + printk("GICC addresses are different, no support"
> + "for non-banked GICC registers !!!\n");
> + gic_cpu_base = 0;
> + goto madt_cpu_base;
> + }
> + }
> + }
> +
> +madt_cpu_base:
> + /* If no GICC address provided, use address from MADT header */
> + if (!gic_cpu_base) {
> + if (!madt_cpu_addr) {
> + printk("Unable to find GICC address\n");
> + return -EINVAL;
> + }
> +
> + printk("Attempt to use Local Interrupt Controller Address"
> + "as GICC base address\n");
> + gic_cpu_base = madt_cpu_addr;
> + }
> +
> + cpu_base = ioremap(gic_cpu_base, ACPI_GIC_CPU_IF_MEM_SIZE);
> + if (!cpu_base) {
> + printk("Unable to map GICC registers\n");
> + return -ENOMEM;
> + }
> +
> + dist_base = ioremap(dist_phy_base, ACPI_GIC_DIST_MEM_SIZE);
> + if (!dist_base) {
> + printk("Unable to map GICD registers\n");
> + iounmap(cpu_base);
> + return -ENOMEM;
> + }
> +
> + /*
> + * FIXME: Initialize zero GIC instance (no multi-GIC support) based on
> + * addresses obtained from MADT. Also, set GIC as default IRQ domain
> + * to allow for GSI registration and GSI to IRQ number translation
> + * (see acpi_register_gsi() and acpi_gsi_to_irq()).
> + *
> + * gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
> + * irq_set_default_host(gic_data[0].domain);
> + */
> +
> + /* TODO: Add check on distributor, cpu size */
> +
> + printk("GICv2 initialization from ACPI MADT table :\n"
> + " gic_dist_addr=%"PRIpaddr"\n"
> + " gic_cpu_addr=%"PRIpaddr"\n"
> + " gic_hyp_addr=%"PRIpaddr"\n"
> + " gic_vcpu_addr=%"PRIpaddr"\n"
> + " gic_maintenance_irq=%u\n",
> + gicv2.dbase, gicv2.cbase, gicv2.hbase, gicv2.vbase,
> + gicv2_info.maintenance_irq);
> +
> + if ( (gicv2.dbase & ~PAGE_MASK) || (gicv2.cbase & ~PAGE_MASK) ||
> + (gicv2.hbase & ~PAGE_MASK) || (gicv2.vbase & ~PAGE_MASK) )
> + panic("GICv2 interfaces not page aligned");
> +
> + gicv2.map_dbase = ioremap_nocache(gicv2.dbase, PAGE_SIZE);
> + if ( !gicv2.map_dbase )
> + panic("GICv2: Failed to ioremap for GIC distributor\n");
> +
> + gicv2.map_cbase[0] = ioremap_nocache(gicv2.cbase, PAGE_SIZE);
> +
> + if ( platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
> + gicv2.map_cbase[1] = ioremap_nocache(gicv2.cbase + PAGE_SIZE * 0x10,
> + PAGE_SIZE);
> + else
> + gicv2.map_cbase[1] = ioremap_nocache(gicv2.cbase + PAGE_SIZE, PAGE_SIZE);
> +
> + if ( !gicv2.map_cbase[0] || !gicv2.map_cbase[1] )
> + panic("GICv2: Failed to ioremap for GIC CPU interface\n");
> +
> + gicv2.map_hbase = ioremap_nocache(gicv2.hbase, PAGE_SIZE);
> + if ( !gicv2.map_hbase )
> + panic("GICv2: Failed to ioremap for GIC Virtual interface\n");
> +
> + /* Global settings: interrupt distributor */
> + spin_lock_init(&gicv2.lock);
> + spin_lock(&gicv2.lock);
> +
> + gicv2_dist_init();
> + gicv2_cpu_init();
> + gicv2_hyp_init();
> +
> + spin_unlock(&gicv2.lock);
> +
> + gicv2_info.hw_version = GIC_V2;
> + register_gic_ops(&gicv2_ops);
Almost everything in this function is common with the dt initialization
of the gic. Please refactor the code to avoid code duplication.
> + return 0;
> +}
> +
> +int __init
> +gic_v2_acpi_init(struct acpi_table_header *table)
> +{
> + struct acpi_table_madt *madt;
> + int count;
> +
> + /* Collect CPU base addresses */
> + count = acpi_parse_entries(sizeof(struct acpi_table_madt),
> + gic_acpi_parse_madt_cpu, table,
> + ACPI_MADT_TYPE_GENERIC_INTERRUPT,
> + MAX_GIC_CPU_INTERFACE);
> + if (count <= 0) {
> + printk("Error during GICC entries parsing\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * Find distributor base address. We expect one distributor entry since
> + * ACPI 5.0 spec neither support multi-GIC instances nor GIC cascade.
> + */
> + count = acpi_parse_entries(sizeof(struct acpi_table_madt),
> + gic_acpi_parse_madt_distributor, table,
> + ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
> + MAX_GIC_DISTRIBUTOR);
> + if (count <= 0) {
> + printk("Error during GICD entries parsing\n");
> + return -EINVAL;
> + }
> +
> + madt = (struct acpi_table_madt *)table;
> + return gic_acpi_validate_init((u64)madt->address);
> +}
> +
> +static int __init acpi_parse_madt(struct acpi_table_header *table)
> +{
> + struct acpi_table_madt *madt = NULL;
> + madt = (struct acpi_table_madt *)table;
> +
> + if (!madt)
> + return 1;
> + else
> + printk("Local APIC address 0x%08x\n", madt->address);
This doesn't make sense: it can only fail if the table argument is NULL
in the first place. Also your message prints something about the Local
APIC, that cannot be right.
> + return 0;
> +}
> +
> +int __init acpi_gic_init()
> +{
> + acpi_status status;
> + int err;
> +
> + status = acpi_table_parse(ACPI_SIG_MADT, acpi_parse_madt);
> +
> + if (ACPI_FAILURE(status)) {
> + const char *msg = acpi_format_exception(status);
> + printk("\nFailed to get MADT table, %s\n", msg);
> + return 1;
> + }
> +
> + err = acpi_table_parse(ACPI_SIG_MADT, gic_v2_acpi_init);
> + if (err)
> + printk("\nFailed to initialize GIC IRQ controller\n");
> +
> + return 0;
> +}
> +#endif
At the very least acpi_gic_init should be in gic.c as it doesn't depend
on the gic version.
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 317b985..93c8a8a 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -784,11 +784,12 @@ void __init start_xen(unsigned long boot_phys_offset,
> /* Comment for now take it after GIC initialization */
> #if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
> init_xen_acpi_time();
> + acpi_gic_init();
> #else
> init_xen_time();
> + gic_init();
> #endif
>
> - gic_init();
As per the other init functions, please move the acpi_gic_init() call to
gic_init.
> p2m_vmid_allocator_init();
>
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> index c2d25db..01ce28d 100644
> --- a/xen/include/asm-arm/acpi.h
> +++ b/xen/include/asm-arm/acpi.h
> @@ -106,5 +106,7 @@ static inline void acpi_disable_pci(void)
> #endif
>
> #define MAX_GIC_CPU_INTERFACE 65535
> +#define MAX_GIC_DISTRIBUTOR 1 /* should be the same as MAX_GIC_NR */
> +extern int __init acpi_gic_init(void);
>
> #endif /*_ASM_ARM_ACPI_H*/
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 20/35] xen/arm: Prepare a min DT for DOM0
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (18 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 19/35] ACPI / GICv2: Add GIC specific ACPI boot support parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 3:48 ` Julien Grall
2015-02-05 15:58 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 21/35] xen/arm: Create memory node " parth.dixit
` (15 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
This patch prepare a DT from scratch for DOM0 for
ACPI-case only. Basically the DT contains minmal
required informations such as DOM0 bootargs, memory
and ACPI RSDP informations only.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/arch/arm/domain_build.c | 67 ++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index de180d8..bb7f043 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -18,6 +18,7 @@
#include <asm/psci.h>
#include <asm/setup.h>
#include <asm/cpufeature.h>
+#include <asm/acpi.h>
#include <asm/gic.h>
#include <xen/irq.h>
@@ -61,6 +62,9 @@ custom_param("dom0_mem", parse_dom0_mem);
*/
#define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
+/* Reserve DOM0 FDT size in ACPI case only */
+#define DOM0_FDT_MIN_SIZE 4096
+
struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
{
if ( opt_dom0_max_vcpus == 0 )
@@ -1151,6 +1155,63 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo,
return res;
}
+/*
+ * Prepare a minimal DTB for DOM0 which contains
+ * bootargs, memory information,
+ * ACPI RSDP pointer.
+ */
+static int prepare_dtb_acpi(struct domain *d, struct kernel_info *kinfo)
+{
+ int new_size;
+ int ret;
+
+ DPRINT("Prepare a min DTB for DOM0\n");
+
+ /* Allocate min size for DT */
+ new_size = DOM0_FDT_MIN_SIZE;
+ kinfo->fdt = xmalloc_bytes(DOM0_FDT_MIN_SIZE);
+
+ if ( kinfo->fdt == NULL )
+ return -ENOMEM;
+
+ /* Create a new empty DT for DOM0 */
+ ret = fdt_create(kinfo->fdt, new_size);
+ if ( ret < 0 )
+ goto err;
+
+ /* Reserve the memory space for new DT */
+ ret = fdt_finish_reservemap(kinfo->fdt);
+ if ( ret < 0 )
+ goto err;
+
+ ret = fdt_begin_node(kinfo->fdt, "/");
+ if ( ret < 0 )
+ goto err;
+
+ ret = fdt_property_cell(kinfo->fdt, "#address-cells", 2);
+ if ( ret )
+ return ret;
+
+ ret = fdt_property_cell(kinfo->fdt, "#size-cells", 1);
+ if ( ret )
+ return ret;
+
+ ret = fdt_end_node(kinfo->fdt);
+ if ( ret < 0 )
+ goto err;
+
+ ret = fdt_finish(kinfo->fdt);
+ if ( ret < 0 )
+ goto err;
+
+ return 0;
+
+ err:
+ printk("Device tree generation failed (%d).\n", ret);
+ xfree(kinfo->fdt);
+ return -EINVAL;
+}
+
static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
{
const void *fdt;
@@ -1305,7 +1366,11 @@ int construct_dom0(struct domain *d)
allocate_memory(d, &kinfo);
- rc = prepare_dtb(d, &kinfo);
+ if (acpi_disabled)
+ rc = prepare_dtb(d, &kinfo);
+ else
+ rc = prepare_dtb_acpi(d, &kinfo);
+
if ( rc < 0 )
return rc;
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 20/35] xen/arm: Prepare a min DT for DOM0
2015-02-04 14:02 ` [PATCH RFC 20/35] xen/arm: Prepare a min DT for DOM0 parth.dixit
@ 2015-02-05 3:48 ` Julien Grall
2015-02-05 15:58 ` Stefano Stabellini
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-05 3:48 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, stefano.stabellini, jbeulich,
christoffer.dall
Hi Parth,
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> This patch prepare a DT from scratch for DOM0 for
> ACPI-case only. Basically the DT contains minmal
> required informations such as DOM0 bootargs, memory
> and ACPI RSDP informations only.
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/arch/arm/domain_build.c | 67 ++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index de180d8..bb7f043 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -18,6 +18,7 @@
> #include <asm/psci.h>
> #include <asm/setup.h>
> #include <asm/cpufeature.h>
> +#include <asm/acpi.h>
>
> #include <asm/gic.h>
> #include <xen/irq.h>
> @@ -61,6 +62,9 @@ custom_param("dom0_mem", parse_dom0_mem);
> */
> #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
>
> +/* Reserve DOM0 FDT size in ACPI case only */
> +#define DOM0_FDT_MIN_SIZE 4096
> +
> struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
> {
> if ( opt_dom0_max_vcpus == 0 )
> @@ -1151,6 +1155,63 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo,
> return res;
> }
>
> +/*
> + * Prepare a minimal DTB for DOM0 which contains
> + * bootargs, memory information,
> + * ACPI RSDP pointer.
> + */
> +static int prepare_dtb_acpi(struct domain *d, struct kernel_info *kinfo)
> +{
> + int new_size;
> + int ret;
> +
> + DPRINT("Prepare a min DTB for DOM0\n");
> +
> + /* Allocate min size for DT */
> + new_size = DOM0_FDT_MIN_SIZE;
> + kinfo->fdt = xmalloc_bytes(DOM0_FDT_MIN_SIZE);
> +
> + if ( kinfo->fdt == NULL )
> + return -ENOMEM;
> +
> + /* Create a new empty DT for DOM0 */
> + ret = fdt_create(kinfo->fdt, new_size);
> + if ( ret < 0 )
> + goto err;
> +
> + /* Reserve the memory space for new DT */
Wrong comment.
> + ret = fdt_finish_reservemap(kinfo->fdt);
> + if ( ret < 0 )
> + goto err;
> +
> + ret = fdt_begin_node(kinfo->fdt, "/");
> + if ( ret < 0 )
> + goto err;
> +
> + ret = fdt_property_cell(kinfo->fdt, "#address-cells", 2);
> + if ( ret )
> + return ret;
> +
> + ret = fdt_property_cell(kinfo->fdt, "#size-cells", 1);
> + if ( ret )
> + return ret;
> +
> + ret = fdt_end_node(kinfo->fdt);
> + if ( ret < 0 )
> + goto err;
> +
> + ret = fdt_finish(kinfo->fdt);
> + if ( ret < 0 )
> + goto err;
> +
> + return 0;
> +
> + err:
> + printk("Device tree generation failed (%d).\n", ret);
> + xfree(kinfo->fdt);
> + return -EINVAL;
> +}
> +
> static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
> {
> const void *fdt;
> @@ -1305,7 +1366,11 @@ int construct_dom0(struct domain *d)
>
I bet the change in construct_dom0 should be more complex than the 4
lines. For instance, initrd_load fixup the DTB when the initrd is present.
How initrd should be loaded in presence of ACPI?
> allocate_memory(d, &kinfo);
>
> - rc = prepare_dtb(d, &kinfo);
> + if (acpi_disabled)
> + rc = prepare_dtb(d, &kinfo);
The name prepare_dtb is now confusing. We should find a better name.
> + else
> + rc = prepare_dtb_acpi(d, &kinfo);
> +
> if ( rc < 0 )
> return rc;
>
>
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 20/35] xen/arm: Prepare a min DT for DOM0
2015-02-04 14:02 ` [PATCH RFC 20/35] xen/arm: Prepare a min DT for DOM0 parth.dixit
2015-02-05 3:48 ` Julien Grall
@ 2015-02-05 15:58 ` Stefano Stabellini
1 sibling, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 15:58 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> This patch prepare a DT from scratch for DOM0 for
> ACPI-case only. Basically the DT contains minmal
> required informations such as DOM0 bootargs, memory
> and ACPI RSDP informations only.
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/arch/arm/domain_build.c | 67 ++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index de180d8..bb7f043 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -18,6 +18,7 @@
> #include <asm/psci.h>
> #include <asm/setup.h>
> #include <asm/cpufeature.h>
> +#include <asm/acpi.h>
>
> #include <asm/gic.h>
> #include <xen/irq.h>
> @@ -61,6 +62,9 @@ custom_param("dom0_mem", parse_dom0_mem);
> */
> #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
>
> +/* Reserve DOM0 FDT size in ACPI case only */
> +#define DOM0_FDT_MIN_SIZE 4096
> +
> struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
> {
> if ( opt_dom0_max_vcpus == 0 )
> @@ -1151,6 +1155,63 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo,
> return res;
> }
>
> +/*
> + * Prepare a minimal DTB for DOM0 which contains
> + * bootargs, memory information,
> + * ACPI RSDP pointer.
> + */
> +static int prepare_dtb_acpi(struct domain *d, struct kernel_info *kinfo)
> +{
> + int new_size;
> + int ret;
> +
> + DPRINT("Prepare a min DTB for DOM0\n");
> +
> + /* Allocate min size for DT */
> + new_size = DOM0_FDT_MIN_SIZE;
> + kinfo->fdt = xmalloc_bytes(DOM0_FDT_MIN_SIZE);
> +
> + if ( kinfo->fdt == NULL )
> + return -ENOMEM;
> +
> + /* Create a new empty DT for DOM0 */
> + ret = fdt_create(kinfo->fdt, new_size);
> + if ( ret < 0 )
> + goto err;
> +
> + /* Reserve the memory space for new DT */
> + ret = fdt_finish_reservemap(kinfo->fdt);
> + if ( ret < 0 )
> + goto err;
> +
> + ret = fdt_begin_node(kinfo->fdt, "/");
> + if ( ret < 0 )
> + goto err;
> +
> + ret = fdt_property_cell(kinfo->fdt, "#address-cells", 2);
> + if ( ret )
> + return ret;
> +
> + ret = fdt_property_cell(kinfo->fdt, "#size-cells", 1);
> + if ( ret )
> + return ret;
> +
> + ret = fdt_end_node(kinfo->fdt);
> + if ( ret < 0 )
> + goto err;
> +
> + ret = fdt_finish(kinfo->fdt);
> + if ( ret < 0 )
> + goto err;
> +
> + return 0;
> +
> + err:
> + printk("Device tree generation failed (%d).\n", ret);
> + xfree(kinfo->fdt);
> + return -EINVAL;
> +}
> +
> static int prepare_dtb(struct domain *d, struct kernel_info *kinfo)
> {
> const void *fdt;
> @@ -1305,7 +1366,11 @@ int construct_dom0(struct domain *d)
>
> allocate_memory(d, &kinfo);
>
> - rc = prepare_dtb(d, &kinfo);
> + if (acpi_disabled)
> + rc = prepare_dtb(d, &kinfo);
> + else
> + rc = prepare_dtb_acpi(d, &kinfo);
Better than the other acpi specific initializations, this is the way to go.
> if ( rc < 0 )
> return rc;
>
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 21/35] xen/arm: Create memory node for DOM0
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (19 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 20/35] xen/arm: Prepare a min DT for DOM0 parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 3:51 ` Julien Grall
2015-02-05 16:01 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 22/35] xen/arm: Create chosen " parth.dixit
` (14 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
Create a memory node for DOM0.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
xen/arch/arm/domain_build.c | 48 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index bb7f043..30bebe5 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1155,6 +1155,50 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo,
return res;
}
+static int make_memory_node_acpi(const struct domain *d,
+ void *fdt,
+ int addr_cells,
+ int size_cells,
+ const struct kernel_info *kinfo)
+{
+ int res, i;
+ int reg_size = addr_cells + size_cells;
+ int nr_cells = reg_size*kinfo->mem.nr_banks;
+ __be32 reg[nr_cells];
+ __be32 *cells;
+
+ DPRINT("Create memory node (reg size %d, nr cells %d)\n", reg_size, nr_cells);
+
+ /* ePAPR 3.4 */
+ res = fdt_begin_node(fdt, "memory");
+ if ( res )
+ return res;
+
+ res = fdt_property_string(fdt, "device_type", "memory");
+ if ( res )
+ return res;
+
+ cells = ®[0];
+ for ( i = 0 ; i < kinfo->mem.nr_banks; i++ )
+ {
+ u64 start = kinfo->mem.bank[i].start;
+ u64 size = kinfo->mem.bank[i].size;
+
+ DPRINT(" Bank %d: %#"PRIx64"->%#"PRIx64"\n",
+ i, start, start + size);
+
+ dt_set_range(&cells, fdt, start, size);
+ }
+
+ res = fdt_property(fdt, "reg", reg, sizeof(reg));
+ if ( res )
+ return res;
+
+ res = fdt_end_node(fdt);
+
+ return res;
+}
+
/*
* Prepare a minimal DTB for DOM0 which contains
* bootargs, memory information,
@@ -1196,6 +1240,10 @@ static int prepare_dtb_acpi(struct domain *d, struct kernel_info *kinfo)
if ( ret )
return ret;
+ ret = make_memory_node_acpi(d, kinfo->fdt, 2, 1, kinfo);
+ if ( ret )
+ goto err;
+
ret = fdt_end_node(kinfo->fdt);
if ( ret < 0 )
goto err;
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 21/35] xen/arm: Create memory node for DOM0
2015-02-04 14:02 ` [PATCH RFC 21/35] xen/arm: Create memory node " parth.dixit
@ 2015-02-05 3:51 ` Julien Grall
2015-02-05 16:01 ` Stefano Stabellini
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-05 3:51 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: ian.campbell, Naresh Bhat, tim, stefano.stabellini, jbeulich,
christoffer.dall
Hi Parth,
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Create a memory node for DOM0.
I'm not convince it's necessary to have a separate patch for this. I
would squash it the #20.
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/arch/arm/domain_build.c | 48 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index bb7f043..30bebe5 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1155,6 +1155,50 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo,
> return res;
> }
>
> +static int make_memory_node_acpi(const struct domain *d,
> + void *fdt,
> + int addr_cells,
> + int size_cells,
> + const struct kernel_info *kinfo)
> +{
> + int res, i;
> + int reg_size = addr_cells + size_cells;
> + int nr_cells = reg_size*kinfo->mem.nr_banks;
> + __be32 reg[nr_cells];
> + __be32 *cells;
> +
> + DPRINT("Create memory node (reg size %d, nr cells %d)\n", reg_size, nr_cells);
> +
> + /* ePAPR 3.4 */
> + res = fdt_begin_node(fdt, "memory");
> + if ( res )
> + return res;
> +
> + res = fdt_property_string(fdt, "device_type", "memory");
> + if ( res )
> + return res;
> +
> + cells = ®[0];
> + for ( i = 0 ; i < kinfo->mem.nr_banks; i++ )
> + {
> + u64 start = kinfo->mem.bank[i].start;
> + u64 size = kinfo->mem.bank[i].size;
> +
> + DPRINT(" Bank %d: %#"PRIx64"->%#"PRIx64"\n",
> + i, start, start + size);
> +
> + dt_set_range(&cells, fdt, start, size);
> + }
> +
> + res = fdt_property(fdt, "reg", reg, sizeof(reg));
> + if ( res )
> + return res;
> +
> + res = fdt_end_node(fdt);
> +
> + return res;
> +}
> +
Why did you duplicate make_memory_node rather than slightly modify the
function to support both ACPI and DT version?
> /*
> * Prepare a minimal DTB for DOM0 which contains
> * bootargs, memory information,
> @@ -1196,6 +1240,10 @@ static int prepare_dtb_acpi(struct domain *d, struct kernel_info *kinfo)
> if ( ret )
> return ret;
>
> + ret = make_memory_node_acpi(d, kinfo->fdt, 2, 1, kinfo);
I forget to mention it on the previous patch. Please add 2 defines for
the value 2/1.
> + if ( ret )
> + goto err;
> +
> ret = fdt_end_node(kinfo->fdt);
> if ( ret < 0 )
> goto err;
>
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 21/35] xen/arm: Create memory node for DOM0
2015-02-04 14:02 ` [PATCH RFC 21/35] xen/arm: Create memory node " parth.dixit
2015-02-05 3:51 ` Julien Grall
@ 2015-02-05 16:01 ` Stefano Stabellini
2015-02-11 6:27 ` Julien Grall
1 sibling, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 16:01 UTC (permalink / raw)
To: parth.dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Create a memory node for DOM0.
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> ---
> xen/arch/arm/domain_build.c | 48 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index bb7f043..30bebe5 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1155,6 +1155,50 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo,
> return res;
> }
>
> +static int make_memory_node_acpi(const struct domain *d,
> + void *fdt,
> + int addr_cells,
> + int size_cells,
> + const struct kernel_info *kinfo)
> +{
> + int res, i;
> + int reg_size = addr_cells + size_cells;
> + int nr_cells = reg_size*kinfo->mem.nr_banks;
> + __be32 reg[nr_cells];
> + __be32 *cells;
> +
> + DPRINT("Create memory node (reg size %d, nr cells %d)\n", reg_size, nr_cells);
> +
> + /* ePAPR 3.4 */
> + res = fdt_begin_node(fdt, "memory");
> + if ( res )
> + return res;
> +
> + res = fdt_property_string(fdt, "device_type", "memory");
> + if ( res )
> + return res;
> +
> + cells = ®[0];
> + for ( i = 0 ; i < kinfo->mem.nr_banks; i++ )
> + {
> + u64 start = kinfo->mem.bank[i].start;
> + u64 size = kinfo->mem.bank[i].size;
> +
> + DPRINT(" Bank %d: %#"PRIx64"->%#"PRIx64"\n",
> + i, start, start + size);
> +
> + dt_set_range(&cells, fdt, start, size);
> + }
> +
> + res = fdt_property(fdt, "reg", reg, sizeof(reg));
> + if ( res )
> + return res;
> +
> + res = fdt_end_node(fdt);
> +
> + return res;
> +}
What's the difference with make_memory_node? Couldn't you just use that
instead?
> /*
> * Prepare a minimal DTB for DOM0 which contains
> * bootargs, memory information,
> @@ -1196,6 +1240,10 @@ static int prepare_dtb_acpi(struct domain *d, struct kernel_info *kinfo)
> if ( ret )
> return ret;
>
> + ret = make_memory_node_acpi(d, kinfo->fdt, 2, 1, kinfo);
> + if ( ret )
> + goto err;
> +
> ret = fdt_end_node(kinfo->fdt);
> if ( ret < 0 )
> goto err;
> --
> 1.9.1
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 21/35] xen/arm: Create memory node for DOM0
2015-02-05 16:01 ` Stefano Stabellini
@ 2015-02-11 6:27 ` Julien Grall
0 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-11 6:27 UTC (permalink / raw)
To: Stefano Stabellini, parth.dixit
Cc: ian.campbell, Naresh Bhat, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
Hi Stefano,
On 06/02/2015 00:01, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
>> From: Naresh Bhat <naresh.bhat@linaro.org>
>>
>> Create a memory node for DOM0.
>>
>> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
>> ---
>> xen/arch/arm/domain_build.c | 48 +++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 48 insertions(+)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index bb7f043..30bebe5 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1155,6 +1155,50 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo,
>> return res;
>> }
>>
>> +static int make_memory_node_acpi(const struct domain *d,
>> + void *fdt,
>> + int addr_cells,
>> + int size_cells,
>> + const struct kernel_info *kinfo)
>> +{
>> + int res, i;
>> + int reg_size = addr_cells + size_cells;
>> + int nr_cells = reg_size*kinfo->mem.nr_banks;
>> + __be32 reg[nr_cells];
>> + __be32 *cells;
>> +
>> + DPRINT("Create memory node (reg size %d, nr cells %d)\n", reg_size, nr_cells);
>> +
>> + /* ePAPR 3.4 */
>> + res = fdt_begin_node(fdt, "memory");
>> + if ( res )
>> + return res;
>> +
>> + res = fdt_property_string(fdt, "device_type", "memory");
>> + if ( res )
>> + return res;
>> +
>> + cells = ®[0];
>> + for ( i = 0 ; i < kinfo->mem.nr_banks; i++ )
>> + {
>> + u64 start = kinfo->mem.bank[i].start;
>> + u64 size = kinfo->mem.bank[i].size;
>> +
>> + DPRINT(" Bank %d: %#"PRIx64"->%#"PRIx64"\n",
>> + i, start, start + size);
>> +
>> + dt_set_range(&cells, fdt, start, size);
>> + }
>> +
>> + res = fdt_property(fdt, "reg", reg, sizeof(reg));
>> + if ( res )
>> + return res;
>> +
>> + res = fdt_end_node(fdt);
>> +
>> + return res;
>> +}
>
> What's the difference with make_memory_node? Couldn't you just use that
> instead?
AFAICS, the only difference is the way we get the number of address/size
cells.
I agree that we should extend make_memory_node to get those number of
cells in parameter rather than duplicating the function.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 22/35] xen/arm: Create chosen node for DOM0
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (20 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 21/35] xen/arm: Create memory node " parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 16:09 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 23/35] arm: acpi add status override table parth.dixit
` (13 subsequent siblings)
35 siblings, 1 reply; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, Parth Dixit, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
Create a chosen node for DOM0 with
- bootargs
- rsdp
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/arch/arm/domain_build.c | 41 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 30bebe5..d781c63 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -19,6 +19,7 @@
#include <asm/setup.h>
#include <asm/cpufeature.h>
#include <asm/acpi.h>
+#include <xen/acpi.h>
#include <asm/gic.h>
#include <xen/irq.h>
@@ -1199,6 +1200,41 @@ static int make_memory_node_acpi(const struct domain *d,
return res;
}
+static int make_chosen_node(const struct domain *d, const struct kernel_info *kinfo)
+{
+ int res = 0;
+ const char *bootargs = NULL;
+ const struct bootmodule *mod = kinfo->kernel_bootmodule;
+ u64 a = acpi_os_get_root_pointer();
+ void *fdt = kinfo->fdt;
+ __be32 val[2];
+ __be32 *cellp;
+
+ DPRINT("Create bootargs chosen node\n");
+
+ if ( mod && mod->cmdline[0] )
+ bootargs = &mod->cmdline[0];
+
+ res = fdt_begin_node(fdt, "chosen");
+ if ( res )
+ return res;
+
+ res = fdt_property(fdt, "bootargs", bootargs, (strlen(bootargs)+1));
+ if ( res )
+ return res;
+
+ cellp = (__be32 *)val;
+ dt_set_cell(&cellp, ARRAY_SIZE(val), a);
+
+ res = fdt_property(fdt, "rsdp", &val, sizeof(val));
+ if ( res )
+ return res;
+
+ res = fdt_end_node(fdt);
+
+ return res;
+}
+
/*
* Prepare a minimal DTB for DOM0 which contains
* bootargs, memory information,
@@ -1244,6 +1280,11 @@ static int prepare_dtb_acpi(struct domain *d, struct kernel_info *kinfo)
if ( ret )
goto err;
+ /* Create a chosen node for DOM0 */
+ ret = make_chosen_node(d, kinfo);
+ if ( ret )
+ goto err;
+
ret = fdt_end_node(kinfo->fdt);
if ( ret < 0 )
goto err;
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 22/35] xen/arm: Create chosen node for DOM0
2015-02-04 14:02 ` [PATCH RFC 22/35] xen/arm: Create chosen " parth.dixit
@ 2015-02-05 16:09 ` Stefano Stabellini
2015-02-06 0:29 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 16:09 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, xen-devel,
stefano.stabellini, jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Naresh Bhat <naresh.bhat@linaro.org>
>
> Create a chosen node for DOM0 with
> - bootargs
> - rsdp
>
> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/domain_build.c | 41 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 30bebe5..d781c63 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -19,6 +19,7 @@
> #include <asm/setup.h>
> #include <asm/cpufeature.h>
> #include <asm/acpi.h>
> +#include <xen/acpi.h>
>
> #include <asm/gic.h>
> #include <xen/irq.h>
> @@ -1199,6 +1200,41 @@ static int make_memory_node_acpi(const struct domain *d,
> return res;
> }
>
> +static int make_chosen_node(const struct domain *d, const struct kernel_info *kinfo)
> +{
> + int res = 0;
> + const char *bootargs = NULL;
> + const struct bootmodule *mod = kinfo->kernel_bootmodule;
> + u64 a = acpi_os_get_root_pointer();
> + void *fdt = kinfo->fdt;
> + __be32 val[2];
> + __be32 *cellp;
> +
> + DPRINT("Create bootargs chosen node\n");
> +
> + if ( mod && mod->cmdline[0] )
> + bootargs = &mod->cmdline[0];
> +
> + res = fdt_begin_node(fdt, "chosen");
> + if ( res )
> + return res;
> +
> + res = fdt_property(fdt, "bootargs", bootargs, (strlen(bootargs)+1));
> + if ( res )
> + return res;
> +
> + cellp = (__be32 *)val;
> + dt_set_cell(&cellp, ARRAY_SIZE(val), a);
> +
> + res = fdt_property(fdt, "rsdp", &val, sizeof(val));
> + if ( res )
> + return res;
> +
> + res = fdt_end_node(fdt);
> +
> + return res;
> +}
This is similar to setup_chosen_node in xen/arch/arm/efi/efi-boot.h.
It might make sense to refactor the code to avoid code duplication.
> /*
> * Prepare a minimal DTB for DOM0 which contains
> * bootargs, memory information,
> @@ -1244,6 +1280,11 @@ static int prepare_dtb_acpi(struct domain *d, struct kernel_info *kinfo)
> if ( ret )
> goto err;
>
> + /* Create a chosen node for DOM0 */
> + ret = make_chosen_node(d, kinfo);
> + if ( ret )
> + goto err;
> +
> ret = fdt_end_node(kinfo->fdt);
> if ( ret < 0 )
> goto err;
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 22/35] xen/arm: Create chosen node for DOM0
2015-02-05 16:09 ` Stefano Stabellini
@ 2015-02-06 0:29 ` Julien Grall
2015-02-06 14:09 ` Stefano Stabellini
0 siblings, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-06 0:29 UTC (permalink / raw)
To: Stefano Stabellini, Parth Dixit
Cc: ian.campbell, Naresh Bhat, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
Hi Stefano,
On 06/02/2015 00:09, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
>> From: Naresh Bhat <naresh.bhat@linaro.org>
>>
>> Create a chosen node for DOM0 with
>> - bootargs
>> - rsdp
>>
>> Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>> xen/arch/arm/domain_build.c | 41 +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 41 insertions(+)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 30bebe5..d781c63 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -19,6 +19,7 @@
>> #include <asm/setup.h>
>> #include <asm/cpufeature.h>
>> #include <asm/acpi.h>
>> +#include <xen/acpi.h>
>>
>> #include <asm/gic.h>
>> #include <xen/irq.h>
>> @@ -1199,6 +1200,41 @@ static int make_memory_node_acpi(const struct domain *d,
>> return res;
>> }
>>
>> +static int make_chosen_node(const struct domain *d, const struct kernel_info *kinfo)
>> +{
>> + int res = 0;
>> + const char *bootargs = NULL;
>> + const struct bootmodule *mod = kinfo->kernel_bootmodule;
>> + u64 a = acpi_os_get_root_pointer();
>> + void *fdt = kinfo->fdt;
>> + __be32 val[2];
>> + __be32 *cellp;
>> +
>> + DPRINT("Create bootargs chosen node\n");
>> +
>> + if ( mod && mod->cmdline[0] )
>> + bootargs = &mod->cmdline[0];
>> +
>> + res = fdt_begin_node(fdt, "chosen");
>> + if ( res )
>> + return res;
>> +
>> + res = fdt_property(fdt, "bootargs", bootargs, (strlen(bootargs)+1));
>> + if ( res )
>> + return res;
>> +
>> + cellp = (__be32 *)val;
>> + dt_set_cell(&cellp, ARRAY_SIZE(val), a);
>> +
>> + res = fdt_property(fdt, "rsdp", &val, sizeof(val));
>> + if ( res )
>> + return res;
>> +
>> + res = fdt_end_node(fdt);
>> +
>> + return res;
>> +}
>
> This is similar to setup_chosen_node in xen/arch/arm/efi/efi-boot.h.
> It might make sense to refactor the code to avoid code duplication.
I don't think it make sense to have a common function between efi-boot.h
(which create the DT for Xen) and here (which create the DT for DOM0).
The former one is adding a node into an existing device tree while the
former creating the device tree. Futhermore, the rsdp property doesn't
exist on EFI boot.
Regads,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 22/35] xen/arm: Create chosen node for DOM0
2015-02-06 0:29 ` Julien Grall
@ 2015-02-06 14:09 ` Stefano Stabellini
0 siblings, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-06 14:09 UTC (permalink / raw)
To: Julien Grall
Cc: ian.campbell, Stefano Stabellini, Naresh Bhat, tim, xen-devel,
stefano.stabellini, jbeulich, Parth Dixit, christoffer.dall
On Fri, 6 Feb 2015, Julien Grall wrote:
> Hi Stefano,
>
> On 06/02/2015 00:09, Stefano Stabellini wrote:
> > On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> > > From: Naresh Bhat <naresh.bhat@linaro.org>
> > >
> > > Create a chosen node for DOM0 with
> > > - bootargs
> > > - rsdp
> > >
> > > Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
> > > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> > > ---
> > > xen/arch/arm/domain_build.c | 41
> > > +++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 41 insertions(+)
> > >
> > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > index 30bebe5..d781c63 100644
> > > --- a/xen/arch/arm/domain_build.c
> > > +++ b/xen/arch/arm/domain_build.c
> > > @@ -19,6 +19,7 @@
> > > #include <asm/setup.h>
> > > #include <asm/cpufeature.h>
> > > #include <asm/acpi.h>
> > > +#include <xen/acpi.h>
> > >
> > > #include <asm/gic.h>
> > > #include <xen/irq.h>
> > > @@ -1199,6 +1200,41 @@ static int make_memory_node_acpi(const struct
> > > domain *d,
> > > return res;
> > > }
> > >
> > > +static int make_chosen_node(const struct domain *d, const struct
> > > kernel_info *kinfo)
> > > +{
> > > + int res = 0;
> > > + const char *bootargs = NULL;
> > > + const struct bootmodule *mod = kinfo->kernel_bootmodule;
> > > + u64 a = acpi_os_get_root_pointer();
> > > + void *fdt = kinfo->fdt;
> > > + __be32 val[2];
> > > + __be32 *cellp;
> > > +
> > > + DPRINT("Create bootargs chosen node\n");
> > > +
> > > + if ( mod && mod->cmdline[0] )
> > > + bootargs = &mod->cmdline[0];
> > > +
> > > + res = fdt_begin_node(fdt, "chosen");
> > > + if ( res )
> > > + return res;
> > > +
> > > + res = fdt_property(fdt, "bootargs", bootargs, (strlen(bootargs)+1));
> > > + if ( res )
> > > + return res;
> > > +
> > > + cellp = (__be32 *)val;
> > > + dt_set_cell(&cellp, ARRAY_SIZE(val), a);
> > > +
> > > + res = fdt_property(fdt, "rsdp", &val, sizeof(val));
> > > + if ( res )
> > > + return res;
> > > +
> > > + res = fdt_end_node(fdt);
> > > +
> > > + return res;
> > > +}
> >
> > This is similar to setup_chosen_node in xen/arch/arm/efi/efi-boot.h.
> > It might make sense to refactor the code to avoid code duplication.
>
> I don't think it make sense to have a common function between efi-boot.h
> (which create the DT for Xen) and here (which create the DT for DOM0).
>
> The former one is adding a node into an existing device tree while the former
> creating the device tree. Futhermore, the rsdp property doesn't exist on EFI
> boot.
I meant to share just the very basic creation of a chosen node, but you
are right, it might not be worth it.
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 23/35] arm: acpi add status override table
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (21 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 22/35] xen/arm: Create chosen " parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 16:14 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 24/35] arm : acpi add xen environment table parth.dixit
` (12 subsequent siblings)
35 siblings, 1 reply; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, julien.grall, tim, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
From: Parth Dixit <parth.dixit@linaro.org>
Status override table is used to hide devices from DOM0
that are used by xen
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/include/acpi/actbl2.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 6aad200..38e35d6 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -79,6 +79,7 @@
#define ACPI_SIG_WDAT "WDAT" /* Watchdog Action Table */
#define ACPI_SIG_WDDT "WDDT" /* Watchdog Timer Description Table */
#define ACPI_SIG_WDRT "WDRT" /* Watchdog Resource Table */
+#define ACPI_SIG_STAO "STAO" /* Status Override Table */
#ifdef ACPI_UNDEFINED_TABLES
/*
@@ -895,6 +896,19 @@ struct acpi_table_uefi {
};
/*******************************************************************************
+ *
+ * STAO - Status Override Table
+ * Version 1
+ *
+ ******************************************************************************/
+
+struct acpi_table_stao {
+ struct acpi_table_header header; /* Common ACPI table header */
+ u8 uart; /* Indicates presence of SPCR table */
+ u8 devpath[1]; /* Full namepath of uart device in ACPI namespace */
+};
+
+/*******************************************************************************
*
* WAET - Windows ACPI Emulated devices Table
* Version 1
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 23/35] arm: acpi add status override table
2015-02-04 14:02 ` [PATCH RFC 23/35] arm: acpi add status override table parth.dixit
@ 2015-02-05 16:14 ` Stefano Stabellini
0 siblings, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 16:14 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, julien.grall, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> Status override table is used to hide devices from DOM0
> that are used by xen
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/include/acpi/actbl2.h | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
> index 6aad200..38e35d6 100644
> --- a/xen/include/acpi/actbl2.h
> +++ b/xen/include/acpi/actbl2.h
> @@ -79,6 +79,7 @@
> #define ACPI_SIG_WDAT "WDAT" /* Watchdog Action Table */
> #define ACPI_SIG_WDDT "WDDT" /* Watchdog Timer Description Table */
> #define ACPI_SIG_WDRT "WDRT" /* Watchdog Resource Table */
> +#define ACPI_SIG_STAO "STAO" /* Status Override Table */
^ align the comment please
> #ifdef ACPI_UNDEFINED_TABLES
> /*
> @@ -895,6 +896,19 @@ struct acpi_table_uefi {
> };
>
> /*******************************************************************************
> + *
> + * STAO - Status Override Table
> + * Version 1
Actually the currently published version is 0.3
> + ******************************************************************************/
> +
> +struct acpi_table_stao {
> + struct acpi_table_header header; /* Common ACPI table header */
> + u8 uart; /* Indicates presence of SPCR table */
> + u8 devpath[1]; /* Full namepath of uart device in ACPI namespace */
> +};
> +
> +/*******************************************************************************
> *
> * WAET - Windows ACPI Emulated devices Table
> * Version 1
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 24/35] arm : acpi add xen environment table
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (22 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 23/35] arm: acpi add status override table parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 16:16 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 25/35] arm: acpi add helper functions to map memory regions parth.dixit
` (11 subsequent siblings)
35 siblings, 1 reply; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, julien.grall, tim, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
From: Parth Dixit <parth.dixit@linaro.org>
Xen environment table is ACPI table that is used to pass grant table
and event channel interrupt information to dom0.
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/include/acpi/actbl2.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 38e35d6..129ce70 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -80,6 +80,7 @@
#define ACPI_SIG_WDDT "WDDT" /* Watchdog Timer Description Table */
#define ACPI_SIG_WDRT "WDRT" /* Watchdog Resource Table */
#define ACPI_SIG_STAO "STAO" /* Status Override Table */
+#define ACPI_SIG_XENV "XENV" /* Xen Environment Table */
#ifdef ACPI_UNDEFINED_TABLES
/*
@@ -910,6 +911,21 @@ struct acpi_table_stao {
/*******************************************************************************
*
+ * XENV - Xen Environment Table
+ * Version 1
+ *
+ ******************************************************************************/
+
+struct acpi_table_xenv {
+ struct acpi_table_header header; /* Common ACPI table header */
+ u64 gnt_start; /* Starting address of Xen grant table region */
+ u64 gnt_size; /* Size of Xen grant table region */
+ u32 evt_intr; /* Xen event channel interrupt */
+ u8 evt_intr_flag; /* Flags for event channel interrupt */
+};
+
+/*******************************************************************************
+ *
* WAET - Windows ACPI Emulated devices Table
* Version 1
*
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 24/35] arm : acpi add xen environment table
2015-02-04 14:02 ` [PATCH RFC 24/35] arm : acpi add xen environment table parth.dixit
@ 2015-02-05 16:16 ` Stefano Stabellini
0 siblings, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 16:16 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, julien.grall, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> Xen environment table is ACPI table that is used to pass grant table
> and event channel interrupt information to dom0.
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/include/acpi/actbl2.h | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
> index 38e35d6..129ce70 100644
> --- a/xen/include/acpi/actbl2.h
> +++ b/xen/include/acpi/actbl2.h
> @@ -80,6 +80,7 @@
> #define ACPI_SIG_WDDT "WDDT" /* Watchdog Timer Description Table */
> #define ACPI_SIG_WDRT "WDRT" /* Watchdog Resource Table */
> #define ACPI_SIG_STAO "STAO" /* Status Override Table */
> +#define ACPI_SIG_XENV "XENV" /* Xen Environment Table */
^ please align this comment
> #ifdef ACPI_UNDEFINED_TABLES
> /*
> @@ -910,6 +911,21 @@ struct acpi_table_stao {
>
> /*******************************************************************************
> *
> + * XENV - Xen Environment Table
> + * Version 1
The latest published version is 0.2
> + ******************************************************************************/
> +
> +struct acpi_table_xenv {
> + struct acpi_table_header header; /* Common ACPI table header */
> + u64 gnt_start; /* Starting address of Xen grant table region */
> + u64 gnt_size; /* Size of Xen grant table region */
> + u32 evt_intr; /* Xen event channel interrupt */
> + u8 evt_intr_flag; /* Flags for event channel interrupt */
Please add appropriate #define for each of the possible flags.
> +};
> +
> +/*******************************************************************************
> + *
> * WAET - Windows ACPI Emulated devices Table
> * Version 1
> *
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 25/35] arm: acpi add helper functions to map memory regions
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (23 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 24/35] arm : acpi add xen environment table parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 4:03 ` Julien Grall
2015-02-04 14:02 ` [PATCH RFC 26/35] arm : acpi read mmio tables from uefi parth.dixit
` (10 subsequent siblings)
35 siblings, 1 reply; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, julien.grall, tim, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
From: Parth Dixit <parth.dixit@linaro.org>
For passing ACPI tables to dom0, UEFI memory needs to be mapped
by xen in dom0 address space. This patch adds helper functions for mapping.
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/arch/arm/p2m.c | 24 ++++++++++++++++++++++++
xen/include/asm-arm/p2m.h | 10 ++++++++++
2 files changed, 34 insertions(+)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 8809f5a..5593a91 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -943,6 +943,30 @@ int p2m_populate_ram(struct domain *d,
0, MATTR_MEM, p2m_ram_rw);
}
+int map_ram_regions(struct domain *d,
+ unsigned long start_gfn,
+ unsigned long nr,
+ unsigned long mfn)
+{
+ return apply_p2m_changes(d, INSERT,
+ pfn_to_paddr(start_gfn),
+ pfn_to_paddr(start_gfn + nr),
+ pfn_to_paddr(mfn),
+ MATTR_MEM, p2m_mmio_direct);
+}
+
+int unmap_ram_regions(struct domain *d,
+ unsigned long start_gfn,
+ unsigned long nr,
+ unsigned long mfn)
+{
+ return apply_p2m_changes(d, REMOVE,
+ pfn_to_paddr(start_gfn),
+ pfn_to_paddr(start_gfn + nr),
+ pfn_to_paddr(mfn),
+ MATTR_MEM, p2m_invalid);
+}
+
int map_mmio_regions(struct domain *d,
unsigned long start_gfn,
unsigned long nr,
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index da36504..be76ecd 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -132,6 +132,16 @@ int guest_physmap_add_entry(struct domain *d,
unsigned long page_order,
p2m_type_t t);
+int map_ram_regions(struct domain *d,
+ unsigned long start_gfn,
+ unsigned long nr_mfns,
+ unsigned long mfn);
+
+int unmap_ram_regions(struct domain *d,
+ unsigned long start_gfn,
+ unsigned long nr_mfns,
+ unsigned long mfn);
+
/* Untyped version for RAM only, for compatibility */
static inline int guest_physmap_add_page(struct domain *d,
unsigned long gfn,
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 25/35] arm: acpi add helper functions to map memory regions
2015-02-04 14:02 ` [PATCH RFC 25/35] arm: acpi add helper functions to map memory regions parth.dixit
@ 2015-02-05 4:03 ` Julien Grall
2015-02-05 16:21 ` Stefano Stabellini
0 siblings, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-05 4:03 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: christoffer.dall, tim, stefano.stabellini, ian.campbell, jbeulich
Hi parth,
Title: this is not acpi specific.
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> For passing ACPI tables to dom0, UEFI memory needs to be mapped
> by xen in dom0 address space. This patch adds helper functions for mapping.
I believe that this is not ACPI/RAM specific. Any cached MMIO regions
will have same issue.
This because Device memory is too strong and disallow unaligned access.
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/p2m.c | 24 ++++++++++++++++++++++++
> xen/include/asm-arm/p2m.h | 10 ++++++++++
> 2 files changed, 34 insertions(+)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 8809f5a..5593a91 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -943,6 +943,30 @@ int p2m_populate_ram(struct domain *d,
> 0, MATTR_MEM, p2m_ram_rw);
> }
>
> +int map_ram_regions(struct domain *d,
> + unsigned long start_gfn,
> + unsigned long nr,
> + unsigned long mfn)
I don't like the name of the function. It gives the impression that we
map any RAM region to the guest via this function.
Which is obviously wrong and should never be done.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 25/35] arm: acpi add helper functions to map memory regions
2015-02-05 4:03 ` Julien Grall
@ 2015-02-05 16:21 ` Stefano Stabellini
2015-02-06 0:35 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 16:21 UTC (permalink / raw)
To: Julien Grall
Cc: ian.campbell, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
On Thu, 5 Feb 2015, Julien Grall wrote:
> Hi parth,
>
> Title: this is not acpi specific.
>
> On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> > From: Parth Dixit <parth.dixit@linaro.org>
> >
> > For passing ACPI tables to dom0, UEFI memory needs to be mapped
> > by xen in dom0 address space. This patch adds helper functions for mapping.
>
> I believe that this is not ACPI/RAM specific. Any cached MMIO regions will
> have same issue.
>
> This because Device memory is too strong and disallow unaligned access.
>
> > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> > ---
> > xen/arch/arm/p2m.c | 24 ++++++++++++++++++++++++
> > xen/include/asm-arm/p2m.h | 10 ++++++++++
> > 2 files changed, 34 insertions(+)
> >
> > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > index 8809f5a..5593a91 100644
> > --- a/xen/arch/arm/p2m.c
> > +++ b/xen/arch/arm/p2m.c
> > @@ -943,6 +943,30 @@ int p2m_populate_ram(struct domain *d,
> > 0, MATTR_MEM, p2m_ram_rw);
> > }
> >
> > +int map_ram_regions(struct domain *d,
> > + unsigned long start_gfn,
> > + unsigned long nr,
> > + unsigned long mfn)
>
> I don't like the name of the function. It gives the impression that we map any
> RAM region to the guest via this function.
>
> Which is obviously wrong and should never be done.
map_mem_regions?
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 25/35] arm: acpi add helper functions to map memory regions
2015-02-05 16:21 ` Stefano Stabellini
@ 2015-02-06 0:35 ` Julien Grall
2015-02-06 14:12 ` Stefano Stabellini
0 siblings, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-06 0:35 UTC (permalink / raw)
To: Stefano Stabellini
Cc: ian.campbell, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
On 06/02/2015 00:21, Stefano Stabellini wrote:
> On Thu, 5 Feb 2015, Julien Grall wrote:
>> Hi parth,
>>
>> Title: this is not acpi specific.
>>
>> On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
>>> From: Parth Dixit <parth.dixit@linaro.org>
>>>
>>> For passing ACPI tables to dom0, UEFI memory needs to be mapped
>>> by xen in dom0 address space. This patch adds helper functions for mapping.
>>
>> I believe that this is not ACPI/RAM specific. Any cached MMIO regions will
>> have same issue.
>>
>> This because Device memory is too strong and disallow unaligned access.
>>
>>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>>> ---
>>> xen/arch/arm/p2m.c | 24 ++++++++++++++++++++++++
>>> xen/include/asm-arm/p2m.h | 10 ++++++++++
>>> 2 files changed, 34 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>>> index 8809f5a..5593a91 100644
>>> --- a/xen/arch/arm/p2m.c
>>> +++ b/xen/arch/arm/p2m.c
>>> @@ -943,6 +943,30 @@ int p2m_populate_ram(struct domain *d,
>>> 0, MATTR_MEM, p2m_ram_rw);
>>> }
>>>
>>> +int map_ram_regions(struct domain *d,
>>> + unsigned long start_gfn,
>>> + unsigned long nr,
>>> + unsigned long mfn)
>>
>> I don't like the name of the function. It gives the impression that we map any
>> RAM region to the guest via this function.
>>
>> Which is obviously wrong and should never be done.
>
> map_mem_regions?
It's still unclear, what mem mean? is an MMIO region? Is it cached,
uncached? Is it read-only/read-write.
We already have a function map_mmio_regions. Maybe it would make sense
to extend it to give more control about the mapping (cached/uncached,
read-only, read-write,....). But this function is common with x86. So
I'm not sure about what to do.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 25/35] arm: acpi add helper functions to map memory regions
2015-02-06 0:35 ` Julien Grall
@ 2015-02-06 14:12 ` Stefano Stabellini
2015-02-11 6:49 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-06 14:12 UTC (permalink / raw)
To: Julien Grall
Cc: ian.campbell, Stefano Stabellini, tim, xen-devel,
stefano.stabellini, jbeulich, parth.dixit, christoffer.dall
On Fri, 6 Feb 2015, Julien Grall wrote:
> On 06/02/2015 00:21, Stefano Stabellini wrote:
> > On Thu, 5 Feb 2015, Julien Grall wrote:
> > > Hi parth,
> > >
> > > Title: this is not acpi specific.
> > >
> > > On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> > > > From: Parth Dixit <parth.dixit@linaro.org>
> > > >
> > > > For passing ACPI tables to dom0, UEFI memory needs to be mapped
> > > > by xen in dom0 address space. This patch adds helper functions for
> > > > mapping.
> > >
> > > I believe that this is not ACPI/RAM specific. Any cached MMIO regions will
> > > have same issue.
> > >
> > > This because Device memory is too strong and disallow unaligned access.
> > >
> > > > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> > > > ---
> > > > xen/arch/arm/p2m.c | 24 ++++++++++++++++++++++++
> > > > xen/include/asm-arm/p2m.h | 10 ++++++++++
> > > > 2 files changed, 34 insertions(+)
> > > >
> > > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > > index 8809f5a..5593a91 100644
> > > > --- a/xen/arch/arm/p2m.c
> > > > +++ b/xen/arch/arm/p2m.c
> > > > @@ -943,6 +943,30 @@ int p2m_populate_ram(struct domain *d,
> > > > 0, MATTR_MEM, p2m_ram_rw);
> > > > }
> > > >
> > > > +int map_ram_regions(struct domain *d,
> > > > + unsigned long start_gfn,
> > > > + unsigned long nr,
> > > > + unsigned long mfn)
> > >
> > > I don't like the name of the function. It gives the impression that we map
> > > any
> > > RAM region to the guest via this function.
> > >
> > > Which is obviously wrong and should never be done.
> >
> > map_mem_regions?
>
> It's still unclear, what mem mean? is an MMIO region? Is it cached, uncached?
> Is it read-only/read-write.
>
> We already have a function map_mmio_regions. Maybe it would make sense to
> extend it to give more control about the mapping (cached/uncached, read-only,
> read-write,....). But this function is common with x86. So I'm not sure about
> what to do.
Usually mmio refers to device memory and not just from the caching
attributes point of view. I would rather not use map_mmio_regions for
something that doesn't belong to a device.
That said, it is difficult to come up with a good name.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 25/35] arm: acpi add helper functions to map memory regions
2015-02-06 14:12 ` Stefano Stabellini
@ 2015-02-11 6:49 ` Julien Grall
0 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-11 6:49 UTC (permalink / raw)
To: Stefano Stabellini
Cc: ian.campbell, tim, xen-devel, stefano.stabellini, jbeulich,
parth.dixit, christoffer.dall
Hi Stefano,
On 06/02/2015 22:12, Stefano Stabellini wrote:
> On Fri, 6 Feb 2015, Julien Grall wrote:
>> On 06/02/2015 00:21, Stefano Stabellini wrote:
>>> On Thu, 5 Feb 2015, Julien Grall wrote:
>>>> Hi parth,
>>>>
>>>> Title: this is not acpi specific.
>>>>
>>>> On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
>>>>> From: Parth Dixit <parth.dixit@linaro.org>
>>>>>
>>>>> For passing ACPI tables to dom0, UEFI memory needs to be mapped
>>>>> by xen in dom0 address space. This patch adds helper functions for
>>>>> mapping.
>>>>
>>>> I believe that this is not ACPI/RAM specific. Any cached MMIO regions will
>>>> have same issue.
>>>>
>>>> This because Device memory is too strong and disallow unaligned access.
>>>>
>>>>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>>>>> ---
>>>>> xen/arch/arm/p2m.c | 24 ++++++++++++++++++++++++
>>>>> xen/include/asm-arm/p2m.h | 10 ++++++++++
>>>>> 2 files changed, 34 insertions(+)
>>>>>
>>>>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>>>>> index 8809f5a..5593a91 100644
>>>>> --- a/xen/arch/arm/p2m.c
>>>>> +++ b/xen/arch/arm/p2m.c
>>>>> @@ -943,6 +943,30 @@ int p2m_populate_ram(struct domain *d,
>>>>> 0, MATTR_MEM, p2m_ram_rw);
>>>>> }
>>>>>
>>>>> +int map_ram_regions(struct domain *d,
>>>>> + unsigned long start_gfn,
>>>>> + unsigned long nr,
>>>>> + unsigned long mfn)
>>>>
>>>> I don't like the name of the function. It gives the impression that we map
>>>> any
>>>> RAM region to the guest via this function.
>>>>
>>>> Which is obviously wrong and should never be done.
>>>
>>> map_mem_regions?
>>
>> It's still unclear, what mem mean? is an MMIO region? Is it cached, uncached?
>> Is it read-only/read-write.
>>
>> We already have a function map_mmio_regions. Maybe it would make sense to
>> extend it to give more control about the mapping (cached/uncached, read-only,
>> read-write,....). But this function is common with x86. So I'm not sure about
>> what to do.
>
> Usually mmio refers to device memory and not just from the caching
> attributes point of view.
I didn't find anything which state ACPI is always living in the RAM. It
could also be in the ROM.
> I would rather not use map_mmio_regions for
> something that doesn't belong to a device.
The current MMIO code assume that the memory will always be non-cached
(MATTR_DEVICE). This will lead to various issue in the guest when it's
trying to access cached BARs.
It would be good to have a common helper handling this case because we
will have to handle it for PCI sooner or later.
> That said, it is difficult to come up with a good name.
Maybe we could introduce a function map_region which the following prototype
map_region(strut domain *d, unsigned long start_gfn,
unsigned long nr, unsigned long mfn,
int mattr, p2m_type_t type)
We could also drop add new types (either real or virtual) to
differentiate the use cases. This is because we can infer the mattr
(MATTR_DEVICE/MATTR_MEM).
At the same time, it would clean up a bit the current code by dropping
one parameter.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 26/35] arm : acpi read mmio tables from uefi
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (24 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 25/35] arm: acpi add helper functions to map memory regions parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 4:17 ` Julien Grall
2015-02-05 16:34 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 27/35] arm: acpi map mmio regions to dom0 parth.dixit
` (9 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, julien.grall, tim, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
From: Parth Dixit <parth.dixit@linaro.org>
For ACPI on arm device initialization is done by dom0 after parsing DSDT.
xen requires mmio region information described in uefi tables
for mapping it to dom0.
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/arch/arm/efi/efi-boot.h | 16 ++++++++++++++++
xen/arch/arm/setup.c | 1 +
xen/include/asm-arm/setup.h | 1 +
3 files changed, 18 insertions(+)
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index 639942d..535f484 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -127,6 +127,8 @@ static EFI_STATUS __init efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
{
int Index;
int i = 0;
+ int j = 0;
+
EFI_MEMORY_DESCRIPTOR *desc_ptr = map;
for ( Index = 0; Index < (mmap_size / desc_size); Index++ )
@@ -145,10 +147,24 @@ static EFI_STATUS __init efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
break;
}
}
+ else if ( desc_ptr->Type == EfiMemoryMappedIO
+ || desc_ptr->Type == EfiMemoryMappedIOPortSpace )
+ {
+ acpi_mmio.bank[j].start = desc_ptr->PhysicalStart;
+ acpi_mmio.bank[j].size = desc_ptr->NumberOfPages * EFI_PAGE_SIZE;
+ if ( ++j >= NR_MEM_BANKS )
+ {
+ PrintStr(L"Warning: All ");
+ DisplayUint(NR_MEM_BANKS, -1);
+ PrintStr(L" acpi meminfo mem banks exhausted.\r\n");
+ break;
+ }
+ }
desc_ptr = NextMemoryDescriptor(desc_ptr, desc_size);
}
bootinfo.mem.nr_banks = i;
+ acpi_mmio.nr_banks = j;
return EFI_SUCCESS;
}
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 93c8a8a..930746b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -50,6 +50,7 @@
#include <asm-arm/cputype.h>
struct bootinfo __initdata bootinfo;
+struct meminfo __initdata acpi_mmio;
struct cpuinfo_arm __read_mostly boot_cpu_data;
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index ba5a67d..5ea9ed6 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -46,6 +46,7 @@ struct bootinfo {
};
extern struct bootinfo bootinfo;
+extern struct meminfo acpi_mmio;
void arch_init_memory(void);
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 26/35] arm : acpi read mmio tables from uefi
2015-02-04 14:02 ` [PATCH RFC 26/35] arm : acpi read mmio tables from uefi parth.dixit
@ 2015-02-05 4:17 ` Julien Grall
2015-02-05 16:34 ` Stefano Stabellini
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-05 4:17 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: christoffer.dall, tim, stefano.stabellini, ian.campbell, jbeulich
Hi Parth,
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> For ACPI on arm device initialization is done by dom0 after parsing DSDT.
For ACPI on ARM, device ...
> xen requires mmio region information described in uefi tables
> for mapping it to dom0.
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/efi/efi-boot.h | 16 ++++++++++++++++
> xen/arch/arm/setup.c | 1 +
> xen/include/asm-arm/setup.h | 1 +
> 3 files changed, 18 insertions(+)
>
> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> index 639942d..535f484 100644
> --- a/xen/arch/arm/efi/efi-boot.h
> +++ b/xen/arch/arm/efi/efi-boot.h
> @@ -127,6 +127,8 @@ static EFI_STATUS __init efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
> {
> int Index;
> int i = 0;
> + int j = 0;
> +
> EFI_MEMORY_DESCRIPTOR *desc_ptr = map;
>
> for ( Index = 0; Index < (mmap_size / desc_size); Index++ )
> @@ -145,10 +147,24 @@ static EFI_STATUS __init efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
> break;
> }
> }
> + else if ( desc_ptr->Type == EfiMemoryMappedIO
> + || desc_ptr->Type == EfiMemoryMappedIOPortSpace )
I would turn the function into a switch case. if ... else if ... is
really difficult to read and ...
> + {
> + acpi_mmio.bank[j].start = desc_ptr->PhysicalStart;
> + acpi_mmio.bank[j].size = desc_ptr->NumberOfPages * EFI_PAGE_SIZE;
> + if ( ++j >= NR_MEM_BANKS )
> + {
> + PrintStr(L"Warning: All ");
> + DisplayUint(NR_MEM_BANKS, -1);
> + PrintStr(L" acpi meminfo mem banks exhausted.\r\n");
> + break;
... make this such problem appears.
While the number of MMIO banks has expired, we should continue to loop
to get the RAM regions. Leaving the loop will make less obvious the
further issue (such as no memory bank found).
> + }
> + }
> desc_ptr = NextMemoryDescriptor(desc_ptr, desc_size);
> }
>
> bootinfo.mem.nr_banks = i;
> + acpi_mmio.nr_banks = j;
> return EFI_SUCCESS;
> }
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 93c8a8a..930746b 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -50,6 +50,7 @@
> #include <asm-arm/cputype.h>
>
> struct bootinfo __initdata bootinfo;
#ifdef CONFIG_ACPI?
> +struct meminfo __initdata acpi_mmio;
>
> struct cpuinfo_arm __read_mostly boot_cpu_data;
>
> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> index ba5a67d..5ea9ed6 100644
> --- a/xen/include/asm-arm/setup.h
> +++ b/xen/include/asm-arm/setup.h
> @@ -46,6 +46,7 @@ struct bootinfo {
> };
>
> extern struct bootinfo bootinfo;
> +extern struct meminfo acpi_mmio;
I'm not sure that it's the right things to use meminfo. It only has 64
banks...
Could not we re-read at runtime the UEFI memory map?
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 26/35] arm : acpi read mmio tables from uefi
2015-02-04 14:02 ` [PATCH RFC 26/35] arm : acpi read mmio tables from uefi parth.dixit
2015-02-05 4:17 ` Julien Grall
@ 2015-02-05 16:34 ` Stefano Stabellini
2015-02-06 0:38 ` Julien Grall
1 sibling, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 16:34 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, julien.grall, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
#
> From: Parth Dixit <parth.dixit@linaro.org>
>
> For ACPI on arm device initialization is done by dom0 after parsing DSDT.
> xen requires mmio region information described in uefi tables
> for mapping it to dom0.
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/efi/efi-boot.h | 16 ++++++++++++++++
> xen/arch/arm/setup.c | 1 +
> xen/include/asm-arm/setup.h | 1 +
> 3 files changed, 18 insertions(+)
>
> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> index 639942d..535f484 100644
> --- a/xen/arch/arm/efi/efi-boot.h
> +++ b/xen/arch/arm/efi/efi-boot.h
> @@ -127,6 +127,8 @@ static EFI_STATUS __init efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
> {
> int Index;
> int i = 0;
> + int j = 0;
> +
> EFI_MEMORY_DESCRIPTOR *desc_ptr = map;
>
> for ( Index = 0; Index < (mmap_size / desc_size); Index++ )
> @@ -145,10 +147,24 @@ static EFI_STATUS __init efi_process_memory_map_bootinfo(EFI_MEMORY_DESCRIPTOR *
> break;
> }
> }
> + else if ( desc_ptr->Type == EfiMemoryMappedIO
> + || desc_ptr->Type == EfiMemoryMappedIOPortSpace )
It might be worth turning the if above into a switch.
> + {
> + acpi_mmio.bank[j].start = desc_ptr->PhysicalStart;
> + acpi_mmio.bank[j].size = desc_ptr->NumberOfPages * EFI_PAGE_SIZE;
> + if ( ++j >= NR_MEM_BANKS )
> + {
> + PrintStr(L"Warning: All ");
> + DisplayUint(NR_MEM_BANKS, -1);
> + PrintStr(L" acpi meminfo mem banks exhausted.\r\n");
> + break;
> + }
Please use the same pattern used above: first check, then assign to
acpi_mmio, finally increment j.
> + }
> desc_ptr = NextMemoryDescriptor(desc_ptr, desc_size);
> }
>
> bootinfo.mem.nr_banks = i;
> + acpi_mmio.nr_banks = j;
> return EFI_SUCCESS;
> }
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 93c8a8a..930746b 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -50,6 +50,7 @@
> #include <asm-arm/cputype.h>
>
> struct bootinfo __initdata bootinfo;
> +struct meminfo __initdata acpi_mmio;
>
> struct cpuinfo_arm __read_mostly boot_cpu_data;
>
> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> index ba5a67d..5ea9ed6 100644
> --- a/xen/include/asm-arm/setup.h
> +++ b/xen/include/asm-arm/setup.h
> @@ -46,6 +46,7 @@ struct bootinfo {
> };
>
> extern struct bootinfo bootinfo;
> +extern struct meminfo acpi_mmio;
It might make sense to reuse bootinfo.mem.
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 26/35] arm : acpi read mmio tables from uefi
2015-02-05 16:34 ` Stefano Stabellini
@ 2015-02-06 0:38 ` Julien Grall
2015-02-06 14:17 ` Stefano Stabellini
0 siblings, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-06 0:38 UTC (permalink / raw)
To: Stefano Stabellini, Parth Dixit
Cc: ian.campbell, tim, xen-devel, stefano.stabellini, jbeulich,
christoffer.dall
On 06/02/2015 00:34, Stefano Stabellini wrote:
>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> index 93c8a8a..930746b 100644
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -50,6 +50,7 @@
>> #include <asm-arm/cputype.h>
>>
>> struct bootinfo __initdata bootinfo;
>> +struct meminfo __initdata acpi_mmio;
>>
>> struct cpuinfo_arm __read_mostly boot_cpu_data;
>>
>> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
>> index ba5a67d..5ea9ed6 100644
>> --- a/xen/include/asm-arm/setup.h
>> +++ b/xen/include/asm-arm/setup.h
>> @@ -46,6 +46,7 @@ struct bootinfo {
>> };
>>
>> extern struct bootinfo bootinfo;
>> +extern struct meminfo acpi_mmio;
>
> It might make sense to reuse bootinfo.mem.
Do you mean by extending the meminfo structure with a flags indicating
if it's a RAM or MMIO range?
I guess it might be good, but I'm concerned about the static size of the
array, 64 may not be suffisant.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 26/35] arm : acpi read mmio tables from uefi
2015-02-06 0:38 ` Julien Grall
@ 2015-02-06 14:17 ` Stefano Stabellini
2015-02-11 9:14 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-06 14:17 UTC (permalink / raw)
To: Julien Grall
Cc: ian.campbell, Stefano Stabellini, tim, xen-devel,
stefano.stabellini, jbeulich, Parth Dixit, christoffer.dall
On Fri, 6 Feb 2015, Julien Grall wrote:
> On 06/02/2015 00:34, Stefano Stabellini wrote:
> > > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > > index 93c8a8a..930746b 100644
> > > --- a/xen/arch/arm/setup.c
> > > +++ b/xen/arch/arm/setup.c
> > > @@ -50,6 +50,7 @@
> > > #include <asm-arm/cputype.h>
> > >
> > > struct bootinfo __initdata bootinfo;
> > > +struct meminfo __initdata acpi_mmio;
> > >
> > > struct cpuinfo_arm __read_mostly boot_cpu_data;
> > >
> > > diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> > > index ba5a67d..5ea9ed6 100644
> > > --- a/xen/include/asm-arm/setup.h
> > > +++ b/xen/include/asm-arm/setup.h
> > > @@ -46,6 +46,7 @@ struct bootinfo {
> > > };
> > >
> > > extern struct bootinfo bootinfo;
> > > +extern struct meminfo acpi_mmio;
> >
> > It might make sense to reuse bootinfo.mem.
>
> Do you mean by extending the meminfo structure with a flags indicating if it's
> a RAM or MMIO range?
Right. We could avoid introducing acpi_mmio and instead storing the
banks info in bootinfo.mem, that I am guessing it would be unused on
acpi?
> I guess it might be good, but I'm concerned about the static size of the
> array, 64 may not be suffisant.
Yes, you are right about that. Do we have any ideas on how many banks
are available on a few real systems?
The alternative would be to create a list.
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 26/35] arm : acpi read mmio tables from uefi
2015-02-06 14:17 ` Stefano Stabellini
@ 2015-02-11 9:14 ` Julien Grall
0 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-11 9:14 UTC (permalink / raw)
To: Stefano Stabellini
Cc: ian.campbell, tim, xen-devel, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
Hi Stefano,
On 06/02/2015 22:17, Stefano Stabellini wrote:
> On Fri, 6 Feb 2015, Julien Grall wrote:
>> On 06/02/2015 00:34, Stefano Stabellini wrote:
>>>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>>>> index 93c8a8a..930746b 100644
>>>> --- a/xen/arch/arm/setup.c
>>>> +++ b/xen/arch/arm/setup.c
>>>> @@ -50,6 +50,7 @@
>>>> #include <asm-arm/cputype.h>
>>>>
>>>> struct bootinfo __initdata bootinfo;
>>>> +struct meminfo __initdata acpi_mmio;
>>>>
>>>> struct cpuinfo_arm __read_mostly boot_cpu_data;
>>>>
>>>> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
>>>> index ba5a67d..5ea9ed6 100644
>>>> --- a/xen/include/asm-arm/setup.h
>>>> +++ b/xen/include/asm-arm/setup.h
>>>> @@ -46,6 +46,7 @@ struct bootinfo {
>>>> };
>>>>
>>>> extern struct bootinfo bootinfo;
>>>> +extern struct meminfo acpi_mmio;
>>>
>>> It might make sense to reuse bootinfo.mem.
>>
>> Do you mean by extending the meminfo structure with a flags indicating if it's
>> a RAM or MMIO range?
>
> Right. We could avoid introducing acpi_mmio and instead storing the
> banks info in bootinfo.mem, that I am guessing it would be unused on
> acpi?
It's used by EFI to store the memory bank. So we can't reuse it for
another purpose.
But we could extend the structure to add a type.
Although, let's wait until we know if we can use UEFI to get the MMIO
region.
>
>> I guess it might be good, but I'm concerned about the static size of the
>> array, 64 may not be suffisant.
>
> Yes, you are right about that. Do we have any ideas on how many banks
> are available on a few real systems?
I have no ideas.
> The alternative would be to create a list.
At that time, we can't use the boot allocator (memory has not been
populate). We would have to use the AllocatePages().
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 27/35] arm: acpi map mmio regions to dom0
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (25 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 26/35] arm : acpi read mmio tables from uefi parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 16:49 ` Stefano Stabellini
2015-02-11 9:26 ` Julien Grall
2015-02-04 14:02 ` [PATCH RFC 28/35] arm: acpi map acpi tables in dom0 parth.dixit
` (8 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, julien.grall, tim, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
From: Parth Dixit <parth.dixit@linaro.org>
map mmio regions described in uefi tables to dom0 address space
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/arch/arm/domain_build.c | 54 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d781c63..49eb52a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1235,6 +1235,56 @@ static int make_chosen_node(const struct domain *d, const struct kernel_info *ki
return res;
}
+static int acpi_map_mmio(struct domain *d)
+{
+ int i,res;
+ u64 addr,size;
+
+ for( i = 0; i < acpi_mmio.nr_banks; i++ )
+ {
+ addr = acpi_mmio.bank[i].start;
+ size = acpi_mmio.bank[i].size;
+
+ res = iomem_permit_access(d, paddr_to_pfn(addr & PAGE_MASK),
+ paddr_to_pfn(PAGE_ALIGN(addr + size - 1)));
+ if ( res )
+ {
+ printk(XENLOG_ERR "Unable to permit to dom%d access to"
+ " 0x%"PRIx64" - 0x%"PRIx64"\n",
+ d->domain_id,
+ addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+ }
+
+ res = map_mmio_regions(d,
+ paddr_to_pfn(addr & PAGE_MASK),
+ DIV_ROUND_UP(size, PAGE_SIZE),
+ paddr_to_pfn(addr & PAGE_MASK));
+ if ( res )
+ {
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+ " - 0x%"PRIx64" in domain %d\n",
+ addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1,
+ d->domain_id);
+ return res;
+ }
+
+ }
+
+ return 0;
+}
+
+static int map_acpi_regions(struct domain *d)
+{
+ int res;
+
+ res = acpi_map_mmio(d);
+ if ( res )
+ return res;
+
+ return 0;
+}
+
/*
* Prepare a minimal DTB for DOM0 which contains
* bootargs, memory information,
@@ -1264,6 +1314,10 @@ static int prepare_dtb_acpi(struct domain *d, struct kernel_info *kinfo)
if ( ret < 0 )
goto err;
+ ret = map_acpi_regions(d);
+ if ( ret < 0 )
+ goto err;
+
ret = fdt_begin_node(kinfo->fdt, "/");
if ( ret < 0 )
goto err;
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 27/35] arm: acpi map mmio regions to dom0
2015-02-04 14:02 ` [PATCH RFC 27/35] arm: acpi map mmio regions to dom0 parth.dixit
@ 2015-02-05 16:49 ` Stefano Stabellini
2015-02-05 19:40 ` Parth Dixit
2015-02-11 9:26 ` Julien Grall
1 sibling, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 16:49 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, julien.grall, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> map mmio regions described in uefi tables to dom0 address space
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/domain_build.c | 54 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d781c63..49eb52a 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1235,6 +1235,56 @@ static int make_chosen_node(const struct domain *d, const struct kernel_info *ki
> return res;
> }
>
> +static int acpi_map_mmio(struct domain *d)
> +{
> + int i,res;
> + u64 addr,size;
> +
> + for( i = 0; i < acpi_mmio.nr_banks; i++ )
> + {
> + addr = acpi_mmio.bank[i].start;
> + size = acpi_mmio.bank[i].size;
> +
> + res = iomem_permit_access(d, paddr_to_pfn(addr & PAGE_MASK),
> + paddr_to_pfn(PAGE_ALIGN(addr + size - 1)));
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to permit to dom%d access to"
> + " 0x%"PRIx64" - 0x%"PRIx64"\n",
> + d->domain_id,
> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> + return res;
> + }
> +
> + res = map_mmio_regions(d,
> + paddr_to_pfn(addr & PAGE_MASK),
> + DIV_ROUND_UP(size, PAGE_SIZE),
> + paddr_to_pfn(addr & PAGE_MASK));
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> + " - 0x%"PRIx64" in domain %d\n",
> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1,
> + d->domain_id);
> + return res;
> + }
> +
> + }
> +
> + return 0;
> +}
> +
> +static int map_acpi_regions(struct domain *d)
> +{
> + int res;
> +
> + res = acpi_map_mmio(d);
> + if ( res )
> + return res;
> +
> + return 0;
> +}
I don't think that splitting the code in two functions is useful. Just
implement the remapping here.
> /*
> * Prepare a minimal DTB for DOM0 which contains
> * bootargs, memory information,
> @@ -1264,6 +1314,10 @@ static int prepare_dtb_acpi(struct domain *d, struct kernel_info *kinfo)
> if ( ret < 0 )
> goto err;
>
> + ret = map_acpi_regions(d);
> + if ( ret < 0 )
> + goto err;
Do they also need to described in the mini dtb for dom0?
If not, how is dom0 going to retrieve the list of mmio regions? I guess
via the acpi tables?
> ret = fdt_begin_node(kinfo->fdt, "/");
> if ( ret < 0 )
> goto err;
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 27/35] arm: acpi map mmio regions to dom0
2015-02-05 16:49 ` Stefano Stabellini
@ 2015-02-05 19:40 ` Parth Dixit
2015-02-06 0:44 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Parth Dixit @ 2015-02-05 19:40 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Ian Campbell, Julien Grall, tim, xen-devel, Stefano Stabellini,
Jan Beulich, Christoffer Dall
On 5 February 2015 at 22:19, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
>> From: Parth Dixit <parth.dixit@linaro.org>
>>
>> map mmio regions described in uefi tables to dom0 address space
>>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>> xen/arch/arm/domain_build.c | 54 +++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 54 insertions(+)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index d781c63..49eb52a 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1235,6 +1235,56 @@ static int make_chosen_node(const struct domain *d, const struct kernel_info *ki
>> return res;
>> }
>>
>> +static int acpi_map_mmio(struct domain *d)
>> +{
>> + int i,res;
>> + u64 addr,size;
>> +
>> + for( i = 0; i < acpi_mmio.nr_banks; i++ )
>> + {
>> + addr = acpi_mmio.bank[i].start;
>> + size = acpi_mmio.bank[i].size;
>> +
>> + res = iomem_permit_access(d, paddr_to_pfn(addr & PAGE_MASK),
>> + paddr_to_pfn(PAGE_ALIGN(addr + size - 1)));
>> + if ( res )
>> + {
>> + printk(XENLOG_ERR "Unable to permit to dom%d access to"
>> + " 0x%"PRIx64" - 0x%"PRIx64"\n",
>> + d->domain_id,
>> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
>> + return res;
>> + }
>> +
>> + res = map_mmio_regions(d,
>> + paddr_to_pfn(addr & PAGE_MASK),
>> + DIV_ROUND_UP(size, PAGE_SIZE),
>> + paddr_to_pfn(addr & PAGE_MASK));
>> + if ( res )
>> + {
>> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
>> + " - 0x%"PRIx64" in domain %d\n",
>> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1,
>> + d->domain_id);
>> + return res;
>> + }
>> +
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int map_acpi_regions(struct domain *d)
>> +{
>> + int res;
>> +
>> + res = acpi_map_mmio(d);
>> + if ( res )
>> + return res;
>> +
>> + return 0;
>> +}
>
> I don't think that splitting the code in two functions is useful. Just
> implement the remapping here.
ok, will take care in next patchset.
>
>> /*
>> * Prepare a minimal DTB for DOM0 which contains
>> * bootargs, memory information,
>> @@ -1264,6 +1314,10 @@ static int prepare_dtb_acpi(struct domain *d, struct kernel_info *kinfo)
>> if ( ret < 0 )
>> goto err;
>>
>> + ret = map_acpi_regions(d);
>> + if ( ret < 0 )
>> + goto err;
>
> Do they also need to described in the mini dtb for dom0?
> If not, how is dom0 going to retrieve the list of mmio regions? I guess
> via the acpi tables?
right , dom0 retrieves it via acpi tables.
>
>> ret = fdt_begin_node(kinfo->fdt, "/");
>> if ( ret < 0 )
>> goto err;
>> --
>> 1.9.1
>>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 27/35] arm: acpi map mmio regions to dom0
2015-02-05 19:40 ` Parth Dixit
@ 2015-02-06 0:44 ` Julien Grall
2015-02-06 14:21 ` Stefano Stabellini
0 siblings, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-06 0:44 UTC (permalink / raw)
To: Parth Dixit, Stefano Stabellini
Cc: Ian Campbell, tim, xen-devel, Stefano Stabellini, Jan Beulich,
Christoffer Dall
On 06/02/2015 03:40, Parth Dixit wrote:
>>> +static int map_acpi_regions(struct domain *d)
>>> +{
>>> + int res;
>>> +
>>> + res = acpi_map_mmio(d);
>>> + if ( res )
>>> + return res;
>>> +
>>> + return 0;
>>> +}
>>
>> I don't think that splitting the code in two functions is useful. Just
>> implement the remapping here.
> ok, will take care in next patchset.
I agree that the splitting doesn't make really sense right now (only one
call is done). But the next following patches add few more calls (such
has mapping ACPI blob...).
So I would keep the splitting here. I would also rename the function to
prepare_acpi to make clear that we setups ACPI for DOM0.
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 27/35] arm: acpi map mmio regions to dom0
2015-02-06 0:44 ` Julien Grall
@ 2015-02-06 14:21 ` Stefano Stabellini
0 siblings, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-06 14:21 UTC (permalink / raw)
To: Julien Grall
Cc: Ian Campbell, Stefano Stabellini, tim, xen-devel,
Stefano Stabellini, Jan Beulich, Parth Dixit, Christoffer Dall
On Fri, 6 Feb 2015, Julien Grall wrote:
> On 06/02/2015 03:40, Parth Dixit wrote:
> > > > +static int map_acpi_regions(struct domain *d)
> > > > +{
> > > > + int res;
> > > > +
> > > > + res = acpi_map_mmio(d);
> > > > + if ( res )
> > > > + return res;
> > > > +
> > > > + return 0;
> > > > +}
> > >
> > > I don't think that splitting the code in two functions is useful. Just
> > > implement the remapping here.
> > ok, will take care in next patchset.
>
> I agree that the splitting doesn't make really sense right now (only one call
> is done). But the next following patches add few more calls (such has mapping
> ACPI blob...).
>
> So I would keep the splitting here. I would also rename the function to
> prepare_acpi to make clear that we setups ACPI for DOM0.
OK
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 27/35] arm: acpi map mmio regions to dom0
2015-02-04 14:02 ` [PATCH RFC 27/35] arm: acpi map mmio regions to dom0 parth.dixit
2015-02-05 16:49 ` Stefano Stabellini
@ 2015-02-11 9:26 ` Julien Grall
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-11 9:26 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: christoffer.dall, tim, stefano.stabellini, ian.campbell, jbeulich
Hi Parth,
On 04/02/2015 22:02, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> map mmio regions described in uefi tables to dom0 address space
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/domain_build.c | 54 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d781c63..49eb52a 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1235,6 +1235,56 @@ static int make_chosen_node(const struct domain *d, const struct kernel_info *ki
> return res;
> }
>
> +static int acpi_map_mmio(struct domain *d)
> +{
> + int i,res;
> + u64 addr,size;
Missing space after the comma.
> +
> + for( i = 0; i < acpi_mmio.nr_banks; i++ )
> + {
> + addr = acpi_mmio.bank[i].start;
> + size = acpi_mmio.bank[i].size;
> +
> + res = iomem_permit_access(d, paddr_to_pfn(addr & PAGE_MASK),
There is multiple place within this loop which use paddr_to_pfn(addr &
PAGE_MASK). I would create a temporary variable to store the value and
use it everywhere.
> + paddr_to_pfn(PAGE_ALIGN(addr + size - 1)));
The indentation is wrong.
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to permit to dom%d access to"
> + " 0x%"PRIx64" - 0x%"PRIx64"\n",
> + d->domain_id,
> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> + return res;
> + }
> +
> + res = map_mmio_regions(d,
> + paddr_to_pfn(addr & PAGE_MASK),
> + DIV_ROUND_UP(size, PAGE_SIZE),
> + paddr_to_pfn(addr & PAGE_MASK));
Ditto
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 28/35] arm: acpi map acpi tables in dom0
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (26 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 27/35] arm: acpi map mmio regions to dom0 parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 4:29 ` Julien Grall
2015-02-05 16:55 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 29/35] arm : acpi enable PSCI and hvc in acpi FADT table parth.dixit
` (7 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, julien.grall, tim, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
From: Parth Dixit <parth.dixit@linaro.org>
map acpi tables described in uefi table to dom0 address space
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/arch/arm/arm64/acpi/arm-core.c | 43 ++++++++++++++++++++++++++++++++++++++
xen/arch/arm/domain_build.c | 4 ++++
xen/include/asm-arm/acpi.h | 1 +
3 files changed, 48 insertions(+)
diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
index cc11fce..6707e4c 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -31,6 +31,7 @@
#include <asm/cputype.h>
#include <asm/acpi.h>
+#include <asm/p2m.h>
/*
* We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
@@ -241,6 +242,48 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table)
return 0;
}
+int acpi_map_tables(struct domain *d)
+{
+ int i,res;
+ u64 addr, size;
+
+ /* map rsdp table */
+ addr = acpi_os_get_root_pointer();
+ size = sizeof(struct acpi_table_rsdp);
+
+ res = map_ram_regions(d,
+ paddr_to_pfn(addr & PAGE_MASK),
+ DIV_ROUND_UP(size, PAGE_SIZE),
+ paddr_to_pfn(addr & PAGE_MASK));
+ if ( res )
+ {
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+ " - 0x%"PRIx64" in domain \n",
+ addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+ }
+
+ for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
+ {
+ addr = acpi_gbl_root_table_list.tables[i].address;
+ size = acpi_gbl_root_table_list.tables[i].length;
+
+ res = map_ram_regions(d,
+ paddr_to_pfn(addr & PAGE_MASK),
+ DIV_ROUND_UP(size, PAGE_SIZE),
+ paddr_to_pfn(addr & PAGE_MASK));
+ if ( res )
+ {
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+ " - 0x%"PRIx64" in domain \n",
+ addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+ }
+ }
+
+ return 0;
+}
+
/*
* acpi_boot_table_init() called from setup_arch(), always.
* 1. find RSDP and get its address, and then find XSDT
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 49eb52a..a504064 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1278,6 +1278,10 @@ static int map_acpi_regions(struct domain *d)
{
int res;
+ res = acpi_map_tables(d);
+ if ( res )
+ return res;
+
res = acpi_map_mmio(d);
if ( res )
return res;
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 01ce28d..4f52cd6 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -108,5 +108,6 @@ static inline void acpi_disable_pci(void)
#define MAX_GIC_CPU_INTERFACE 65535
#define MAX_GIC_DISTRIBUTOR 1 /* should be the same as MAX_GIC_NR */
extern int __init acpi_gic_init(void);
+int acpi_map_tables(struct domain *d);
#endif /*_ASM_ARM_ACPI_H*/
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 28/35] arm: acpi map acpi tables in dom0
2015-02-04 14:02 ` [PATCH RFC 28/35] arm: acpi map acpi tables in dom0 parth.dixit
@ 2015-02-05 4:29 ` Julien Grall
2015-02-05 16:55 ` Stefano Stabellini
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-05 4:29 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: christoffer.dall, tim, stefano.stabellini, ian.campbell, jbeulich
Hi Parth,
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> map acpi tables described in uefi table to dom0 address space
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 43 ++++++++++++++++++++++++++++++++++++++
> xen/arch/arm/domain_build.c | 4 ++++
> xen/include/asm-arm/acpi.h | 1 +
> 3 files changed, 48 insertions(+)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index cc11fce..6707e4c 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -31,6 +31,7 @@
>
> #include <asm/cputype.h>
> #include <asm/acpi.h>
> +#include <asm/p2m.h>
>
> /*
> * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> @@ -241,6 +242,48 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table)
> return 0;
> }
>
> +int acpi_map_tables(struct domain *d)
This should be __init
> +{
> + int i,res;
> + u64 addr, size;
> +
> + /* map rsdp table */
> + addr = acpi_os_get_root_pointer();
> + size = sizeof(struct acpi_table_rsdp);
> +
> + res = map_ram_regions(d,
> + paddr_to_pfn(addr & PAGE_MASK),
> + DIV_ROUND_UP(size, PAGE_SIZE),
> + paddr_to_pfn(addr & PAGE_MASK));
It's not related to this patch. As ACPI may reside in RAM, this mean
that the ACPI region should be marked as reserved to avoid Xen
allocating the memory for a guest.
Did you take care of it?
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> + " - 0x%"PRIx64" in domain \n",
> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> + return res;
> + }
> +
> + for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
> + {
> + addr = acpi_gbl_root_table_list.tables[i].address;
> + size = acpi_gbl_root_table_list.tables[i].length;
> +
> + res = map_ram_regions(d,
> + paddr_to_pfn(addr & PAGE_MASK),
> + DIV_ROUND_UP(size, PAGE_SIZE),
> + paddr_to_pfn(addr & PAGE_MASK));
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> + " - 0x%"PRIx64" in domain \n",
> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> + return res;
> + }
> + }
> +
> + return 0;
> +}
> +
> /*
> * acpi_boot_table_init() called from setup_arch(), always.
> * 1. find RSDP and get its address, and then find XSDT
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 49eb52a..a504064 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1278,6 +1278,10 @@ static int map_acpi_regions(struct domain *d)
> {
> int res;
>
> + res = acpi_map_tables(d);
> + if ( res )
> + return res;
> +
> res = acpi_map_mmio(d);
> if ( res )
> return res;
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> index 01ce28d..4f52cd6 100644
> --- a/xen/include/asm-arm/acpi.h
> +++ b/xen/include/asm-arm/acpi.h
> @@ -108,5 +108,6 @@ static inline void acpi_disable_pci(void)
> #define MAX_GIC_CPU_INTERFACE 65535
> #define MAX_GIC_DISTRIBUTOR 1 /* should be the same as MAX_GIC_NR */
> extern int __init acpi_gic_init(void);
> +int acpi_map_tables(struct domain *d);
>
> #endif /*_ASM_ARM_ACPI_H*/
>
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 28/35] arm: acpi map acpi tables in dom0
2015-02-04 14:02 ` [PATCH RFC 28/35] arm: acpi map acpi tables in dom0 parth.dixit
2015-02-05 4:29 ` Julien Grall
@ 2015-02-05 16:55 ` Stefano Stabellini
2015-02-05 19:38 ` Parth Dixit
1 sibling, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 16:55 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, julien.grall, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> map acpi tables described in uefi table to dom0 address space
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 43 ++++++++++++++++++++++++++++++++++++++
> xen/arch/arm/domain_build.c | 4 ++++
> xen/include/asm-arm/acpi.h | 1 +
> 3 files changed, 48 insertions(+)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index cc11fce..6707e4c 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -31,6 +31,7 @@
>
> #include <asm/cputype.h>
> #include <asm/acpi.h>
> +#include <asm/p2m.h>
>
> /*
> * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> @@ -241,6 +242,48 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table)
> return 0;
> }
>
> +int acpi_map_tables(struct domain *d)
> +{
> + int i,res;
> + u64 addr, size;
> +
> + /* map rsdp table */
> + addr = acpi_os_get_root_pointer();
I cannot seem to find the patch that actually adds the rsdp to the mini
dtb. It would make sense to have that change in this patch.
> + size = sizeof(struct acpi_table_rsdp);
> +
> + res = map_ram_regions(d,
> + paddr_to_pfn(addr & PAGE_MASK),
> + DIV_ROUND_UP(size, PAGE_SIZE),
> + paddr_to_pfn(addr & PAGE_MASK));
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> + " - 0x%"PRIx64" in domain \n",
> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> + return res;
> + }
> +
> + for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
> + {
> + addr = acpi_gbl_root_table_list.tables[i].address;
> + size = acpi_gbl_root_table_list.tables[i].length;
> +
> + res = map_ram_regions(d,
> + paddr_to_pfn(addr & PAGE_MASK),
> + DIV_ROUND_UP(size, PAGE_SIZE),
> + paddr_to_pfn(addr & PAGE_MASK));
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> + " - 0x%"PRIx64" in domain \n",
> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> + return res;
> + }
> + }
> +
> + return 0;
> +}
> +
> /*
> * acpi_boot_table_init() called from setup_arch(), always.
> * 1. find RSDP and get its address, and then find XSDT
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 49eb52a..a504064 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1278,6 +1278,10 @@ static int map_acpi_regions(struct domain *d)
> {
> int res;
>
> + res = acpi_map_tables(d);
> + if ( res )
> + return res;
> +
> res = acpi_map_mmio(d);
> if ( res )
> return res;
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> index 01ce28d..4f52cd6 100644
> --- a/xen/include/asm-arm/acpi.h
> +++ b/xen/include/asm-arm/acpi.h
> @@ -108,5 +108,6 @@ static inline void acpi_disable_pci(void)
> #define MAX_GIC_CPU_INTERFACE 65535
> #define MAX_GIC_DISTRIBUTOR 1 /* should be the same as MAX_GIC_NR */
> extern int __init acpi_gic_init(void);
> +int acpi_map_tables(struct domain *d);
>
> #endif /*_ASM_ARM_ACPI_H*/
> --
> 1.9.1
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 28/35] arm: acpi map acpi tables in dom0
2015-02-05 16:55 ` Stefano Stabellini
@ 2015-02-05 19:38 ` Parth Dixit
2015-02-06 14:23 ` Stefano Stabellini
0 siblings, 1 reply; 166+ messages in thread
From: Parth Dixit @ 2015-02-05 19:38 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Ian Campbell, Julien Grall, tim, xen-devel, Stefano Stabellini,
Jan Beulich, Christoffer Dall
On 5 February 2015 at 22:25, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
>> From: Parth Dixit <parth.dixit@linaro.org>
>>
>> map acpi tables described in uefi table to dom0 address space
>>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>> xen/arch/arm/arm64/acpi/arm-core.c | 43 ++++++++++++++++++++++++++++++++++++++
>> xen/arch/arm/domain_build.c | 4 ++++
>> xen/include/asm-arm/acpi.h | 1 +
>> 3 files changed, 48 insertions(+)
>>
>> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
>> index cc11fce..6707e4c 100644
>> --- a/xen/arch/arm/arm64/acpi/arm-core.c
>> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
>> @@ -31,6 +31,7 @@
>>
>> #include <asm/cputype.h>
>> #include <asm/acpi.h>
>> +#include <asm/p2m.h>
>>
>> /*
>> * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>> @@ -241,6 +242,48 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table)
>> return 0;
>> }
>>
>> +int acpi_map_tables(struct domain *d)
>> +{
>> + int i,res;
>> + u64 addr, size;
>> +
>> + /* map rsdp table */
>> + addr = acpi_os_get_root_pointer();
>
> I cannot seem to find the patch that actually adds the rsdp to the mini
> dtb. It would make sense to have that change in this patch.
it is added earlier in patch 22, "create chosen node"
should i merge it with this patch?
>
>> + size = sizeof(struct acpi_table_rsdp);
>> +
>> + res = map_ram_regions(d,
>> + paddr_to_pfn(addr & PAGE_MASK),
>> + DIV_ROUND_UP(size, PAGE_SIZE),
>> + paddr_to_pfn(addr & PAGE_MASK));
>> + if ( res )
>> + {
>> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
>> + " - 0x%"PRIx64" in domain \n",
>> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
>> + return res;
>> + }
>> +
>> + for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
>> + {
>> + addr = acpi_gbl_root_table_list.tables[i].address;
>> + size = acpi_gbl_root_table_list.tables[i].length;
>> +
>> + res = map_ram_regions(d,
>> + paddr_to_pfn(addr & PAGE_MASK),
>> + DIV_ROUND_UP(size, PAGE_SIZE),
>> + paddr_to_pfn(addr & PAGE_MASK));
>> + if ( res )
>> + {
>> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
>> + " - 0x%"PRIx64" in domain \n",
>> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
>> + return res;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> /*
>> * acpi_boot_table_init() called from setup_arch(), always.
>> * 1. find RSDP and get its address, and then find XSDT
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 49eb52a..a504064 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1278,6 +1278,10 @@ static int map_acpi_regions(struct domain *d)
>> {
>> int res;
>>
>> + res = acpi_map_tables(d);
>> + if ( res )
>> + return res;
>> +
>> res = acpi_map_mmio(d);
>> if ( res )
>> return res;
>> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
>> index 01ce28d..4f52cd6 100644
>> --- a/xen/include/asm-arm/acpi.h
>> +++ b/xen/include/asm-arm/acpi.h
>> @@ -108,5 +108,6 @@ static inline void acpi_disable_pci(void)
>> #define MAX_GIC_CPU_INTERFACE 65535
>> #define MAX_GIC_DISTRIBUTOR 1 /* should be the same as MAX_GIC_NR */
>> extern int __init acpi_gic_init(void);
>> +int acpi_map_tables(struct domain *d);
>>
>> #endif /*_ASM_ARM_ACPI_H*/
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 28/35] arm: acpi map acpi tables in dom0
2015-02-05 19:38 ` Parth Dixit
@ 2015-02-06 14:23 ` Stefano Stabellini
0 siblings, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-06 14:23 UTC (permalink / raw)
To: Parth Dixit
Cc: Ian Campbell, Stefano Stabellini, Julien Grall, tim, xen-devel,
Stefano Stabellini, Jan Beulich, Christoffer Dall
On Fri, 6 Feb 2015, Parth Dixit wrote:
> On 5 February 2015 at 22:25, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> >> From: Parth Dixit <parth.dixit@linaro.org>
> >>
> >> map acpi tables described in uefi table to dom0 address space
> >>
> >> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> >> ---
> >> xen/arch/arm/arm64/acpi/arm-core.c | 43 ++++++++++++++++++++++++++++++++++++++
> >> xen/arch/arm/domain_build.c | 4 ++++
> >> xen/include/asm-arm/acpi.h | 1 +
> >> 3 files changed, 48 insertions(+)
> >>
> >> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> >> index cc11fce..6707e4c 100644
> >> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> >> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> >> @@ -31,6 +31,7 @@
> >>
> >> #include <asm/cputype.h>
> >> #include <asm/acpi.h>
> >> +#include <asm/p2m.h>
> >>
> >> /*
> >> * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> >> @@ -241,6 +242,48 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table)
> >> return 0;
> >> }
> >>
> >> +int acpi_map_tables(struct domain *d)
> >> +{
> >> + int i,res;
> >> + u64 addr, size;
> >> +
> >> + /* map rsdp table */
> >> + addr = acpi_os_get_root_pointer();
> >
> > I cannot seem to find the patch that actually adds the rsdp to the mini
> > dtb. It would make sense to have that change in this patch.
> it is added earlier in patch 22, "create chosen node"
> should i merge it with this patch?
Yes, please
> >> + size = sizeof(struct acpi_table_rsdp);
> >> +
> >> + res = map_ram_regions(d,
> >> + paddr_to_pfn(addr & PAGE_MASK),
> >> + DIV_ROUND_UP(size, PAGE_SIZE),
> >> + paddr_to_pfn(addr & PAGE_MASK));
> >> + if ( res )
> >> + {
> >> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> >> + " - 0x%"PRIx64" in domain \n",
> >> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> >> + return res;
> >> + }
> >> +
> >> + for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
> >> + {
> >> + addr = acpi_gbl_root_table_list.tables[i].address;
> >> + size = acpi_gbl_root_table_list.tables[i].length;
> >> +
> >> + res = map_ram_regions(d,
> >> + paddr_to_pfn(addr & PAGE_MASK),
> >> + DIV_ROUND_UP(size, PAGE_SIZE),
> >> + paddr_to_pfn(addr & PAGE_MASK));
> >> + if ( res )
> >> + {
> >> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> >> + " - 0x%"PRIx64" in domain \n",
> >> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> >> + return res;
> >> + }
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
> >> /*
> >> * acpi_boot_table_init() called from setup_arch(), always.
> >> * 1. find RSDP and get its address, and then find XSDT
> >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> >> index 49eb52a..a504064 100644
> >> --- a/xen/arch/arm/domain_build.c
> >> +++ b/xen/arch/arm/domain_build.c
> >> @@ -1278,6 +1278,10 @@ static int map_acpi_regions(struct domain *d)
> >> {
> >> int res;
> >>
> >> + res = acpi_map_tables(d);
> >> + if ( res )
> >> + return res;
> >> +
> >> res = acpi_map_mmio(d);
> >> if ( res )
> >> return res;
> >> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> >> index 01ce28d..4f52cd6 100644
> >> --- a/xen/include/asm-arm/acpi.h
> >> +++ b/xen/include/asm-arm/acpi.h
> >> @@ -108,5 +108,6 @@ static inline void acpi_disable_pci(void)
> >> #define MAX_GIC_CPU_INTERFACE 65535
> >> #define MAX_GIC_DISTRIBUTOR 1 /* should be the same as MAX_GIC_NR */
> >> extern int __init acpi_gic_init(void);
> >> +int acpi_map_tables(struct domain *d);
> >>
> >> #endif /*_ASM_ARM_ACPI_H*/
> >> --
> >> 1.9.1
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> >>
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 29/35] arm : acpi enable PSCI and hvc in acpi FADT table
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (27 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 28/35] arm: acpi map acpi tables in dom0 parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 4:33 ` Julien Grall
2015-02-05 17:12 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 30/35] arm : acpi map XSDT table to dom0 parth.dixit
` (6 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, julien.grall, tim, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
From: Parth Dixit <parth.dixit@linaro.org>
Enable PSCI and hvc flags in FADT table so that dom0 uses PSCI to
boot vcpu's
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/arch/arm/arm64/acpi/arm-core.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
index 6707e4c..9a26202 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -28,6 +28,7 @@
#include <xen/errno.h>
#include <xen/stdbool.h>
#include <xen/cpumask.h>
+#include <acpi/actables.h>
#include <asm/cputype.h>
#include <asm/acpi.h>
@@ -242,6 +243,19 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table)
return 0;
}
+static void set_psci_fadt(void)
+{
+ struct acpi_table_fadt *fadt=NULL;
+ struct acpi_table_header *table=NULL;
+ u8 checksum;
+
+ acpi_get_table(ACPI_SIG_FADT, 0, &table);
+ fadt = (struct acpi_table_fadt *)table;
+ fadt->arm_boot_flags |= ( ACPI_FADT_PSCI_COMPLIANT | ACPI_FADT_PSCI_USE_HVC );
+ checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, fadt), fadt->header.length);
+ fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
+}
+
int acpi_map_tables(struct domain *d)
{
int i,res;
@@ -263,6 +277,8 @@ int acpi_map_tables(struct domain *d)
return res;
}
+ set_psci_fadt();
+
for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
{
addr = acpi_gbl_root_table_list.tables[i].address;
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 29/35] arm : acpi enable PSCI and hvc in acpi FADT table
2015-02-04 14:02 ` [PATCH RFC 29/35] arm : acpi enable PSCI and hvc in acpi FADT table parth.dixit
@ 2015-02-05 4:33 ` Julien Grall
2015-02-05 17:12 ` Stefano Stabellini
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-05 4:33 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: christoffer.dall, tim, stefano.stabellini, ian.campbell, jbeulich
Hi Parth,
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> Enable PSCI and hvc flags in FADT table so that dom0 uses PSCI to
> boot vcpu's
VCPUs
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index 6707e4c..9a26202 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -28,6 +28,7 @@
> #include <xen/errno.h>
> #include <xen/stdbool.h>
> #include <xen/cpumask.h>
> +#include <acpi/actables.h>
>
> #include <asm/cputype.h>
> #include <asm/acpi.h>
> @@ -242,6 +243,19 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table)
> return 0;
> }
>
> +static void set_psci_fadt(void)
> +{
> + struct acpi_table_fadt *fadt=NULL;
> + struct acpi_table_header *table=NULL;
> + u8 checksum;
> +
> + acpi_get_table(ACPI_SIG_FADT, 0, &table);
> + fadt = (struct acpi_table_fadt *)table;
> + fadt->arm_boot_flags |= ( ACPI_FADT_PSCI_COMPLIANT | ACPI_FADT_PSCI_USE_HVC );
> + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, fadt), fadt->header.length);
> + fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
> +}
> +
> int acpi_map_tables(struct domain *d)
> {
> int i,res;
> @@ -263,6 +277,8 @@ int acpi_map_tables(struct domain *d)
> return res;
> }
>
> + set_psci_fadt();
> +
With this change, the name of the function (acpi_map_tables) doesn't
seem correct.
> for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
> {
> addr = acpi_gbl_root_table_list.tables[i].address;
>
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 29/35] arm : acpi enable PSCI and hvc in acpi FADT table
2015-02-04 14:02 ` [PATCH RFC 29/35] arm : acpi enable PSCI and hvc in acpi FADT table parth.dixit
2015-02-05 4:33 ` Julien Grall
@ 2015-02-05 17:12 ` Stefano Stabellini
2015-02-06 0:47 ` Julien Grall
1 sibling, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 17:12 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, julien.grall, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> Enable PSCI and hvc flags in FADT table so that dom0 uses PSCI to
> boot vcpu's
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index 6707e4c..9a26202 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -28,6 +28,7 @@
> #include <xen/errno.h>
> #include <xen/stdbool.h>
> #include <xen/cpumask.h>
> +#include <acpi/actables.h>
>
> #include <asm/cputype.h>
> #include <asm/acpi.h>
> @@ -242,6 +243,19 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table)
> return 0;
> }
>
> +static void set_psci_fadt(void)
> +{
> + struct acpi_table_fadt *fadt=NULL;
> + struct acpi_table_header *table=NULL;
> + u8 checksum;
> +
> + acpi_get_table(ACPI_SIG_FADT, 0, &table);
> + fadt = (struct acpi_table_fadt *)table;
> + fadt->arm_boot_flags |= ( ACPI_FADT_PSCI_COMPLIANT | ACPI_FADT_PSCI_USE_HVC );
Are we actually allowed to modify the real acpi table passed by the firmware?
Could it be read-only?
If we can change it, do we need a dsb() before the acpi_tb_checksum?
> + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, fadt), fadt->header.length);
> + fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
and here?
> +}
>
> int acpi_map_tables(struct domain *d)
> {
> int i,res;
> @@ -263,6 +277,8 @@ int acpi_map_tables(struct domain *d)
> return res;
> }
>
> + set_psci_fadt();
> +
> for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
> {
> addr = acpi_gbl_root_table_list.tables[i].address;
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 29/35] arm : acpi enable PSCI and hvc in acpi FADT table
2015-02-05 17:12 ` Stefano Stabellini
@ 2015-02-06 0:47 ` Julien Grall
2015-02-06 15:13 ` Stefano Stabellini
0 siblings, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-06 0:47 UTC (permalink / raw)
To: Stefano Stabellini, Parth Dixit
Cc: ian.campbell, tim, xen-devel, stefano.stabellini, jbeulich,
christoffer.dall
Hi Parth,
On 06/02/2015 01:12, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
>> From: Parth Dixit <parth.dixit@linaro.org>
>>
>> Enable PSCI and hvc flags in FADT table so that dom0 uses PSCI to
>> boot vcpu's
>>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>> xen/arch/arm/arm64/acpi/arm-core.c | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
>> index 6707e4c..9a26202 100644
>> --- a/xen/arch/arm/arm64/acpi/arm-core.c
>> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
>> @@ -28,6 +28,7 @@
>> #include <xen/errno.h>
>> #include <xen/stdbool.h>
>> #include <xen/cpumask.h>
>> +#include <acpi/actables.h>
>>
>> #include <asm/cputype.h>
>> #include <asm/acpi.h>
>> @@ -242,6 +243,19 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table)
>> return 0;
>> }
>>
>> +static void set_psci_fadt(void)
>> +{
>> + struct acpi_table_fadt *fadt=NULL;
>> + struct acpi_table_header *table=NULL;
>> + u8 checksum;
>> +
>> + acpi_get_table(ACPI_SIG_FADT, 0, &table);
>> + fadt = (struct acpi_table_fadt *)table;
>> + fadt->arm_boot_flags |= ( ACPI_FADT_PSCI_COMPLIANT | ACPI_FADT_PSCI_USE_HVC );
>
> Are we actually allowed to modify the real acpi table passed by the firmware?
> Could it be read-only?
>
> If we can change it, do we need a dsb() before the acpi_tb_checksum?
IIRC, the ACPI memory region is mapped cached and preparing the ACPI
blob is only done in one processor. So the dsb() is not necessary here.
But ... that made me think that we should clear the cache after changes
in the table. We can't assume that the guest will map with cache
attribute the ACPI tables.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 29/35] arm : acpi enable PSCI and hvc in acpi FADT table
2015-02-06 0:47 ` Julien Grall
@ 2015-02-06 15:13 ` Stefano Stabellini
0 siblings, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-06 15:13 UTC (permalink / raw)
To: Julien Grall
Cc: ian.campbell, Stefano Stabellini, tim, xen-devel,
stefano.stabellini, jbeulich, Parth Dixit, christoffer.dall
On Fri, 6 Feb 2015, Julien Grall wrote:
> Hi Parth,
>
> On 06/02/2015 01:12, Stefano Stabellini wrote:
> > On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> > > From: Parth Dixit <parth.dixit@linaro.org>
> > >
> > > Enable PSCI and hvc flags in FADT table so that dom0 uses PSCI to
> > > boot vcpu's
> > >
> > > Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> > > ---
> > > xen/arch/arm/arm64/acpi/arm-core.c | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/xen/arch/arm/arm64/acpi/arm-core.c
> > > b/xen/arch/arm/arm64/acpi/arm-core.c
> > > index 6707e4c..9a26202 100644
> > > --- a/xen/arch/arm/arm64/acpi/arm-core.c
> > > +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> > > @@ -28,6 +28,7 @@
> > > #include <xen/errno.h>
> > > #include <xen/stdbool.h>
> > > #include <xen/cpumask.h>
> > > +#include <acpi/actables.h>
> > >
> > > #include <asm/cputype.h>
> > > #include <asm/acpi.h>
> > > @@ -242,6 +243,19 @@ static int __init acpi_parse_fadt(struct
> > > acpi_table_header *table)
> > > return 0;
> > > }
> > >
> > > +static void set_psci_fadt(void)
> > > +{
> > > + struct acpi_table_fadt *fadt=NULL;
> > > + struct acpi_table_header *table=NULL;
> > > + u8 checksum;
> > > +
> > > + acpi_get_table(ACPI_SIG_FADT, 0, &table);
> > > + fadt = (struct acpi_table_fadt *)table;
> > > + fadt->arm_boot_flags |= ( ACPI_FADT_PSCI_COMPLIANT |
> > > ACPI_FADT_PSCI_USE_HVC );
> >
> > Are we actually allowed to modify the real acpi table passed by the
> > firmware?
> > Could it be read-only?
> >
> > If we can change it, do we need a dsb() before the acpi_tb_checksum?
>
> IIRC, the ACPI memory region is mapped cached and preparing the ACPI blob is
> only done in one processor. So the dsb() is not necessary here.
I was being paranoid and thinking that the memory dependency might not
be explicit enough and could get a very keen compiler confused, ending
up with reordering the checksum calculation and the field update.
However as we specify -fno-strict-aliasing to compile Xen, I think that
we are allowed to assume that the compiler won't do that.
> But ... that made me think that we should clear the cache after changes in the
> table. We can't assume that the guest will map with cache attribute the ACPI
> tables.
You are right and because we cannot guess what caching attributes dom0
is going to use, we also need to make sure to clean the dcache and unmap
the relative pages in Xen because we don't want to have the same page
mapped with two different caching attributes in the system.
The alternative would be to mandate that dom0 maps all the acpi pages as
cached memory always. In practice I think it is going to be the case
for Linux. But I don't like to set this kind of restrictions to Dom0.
To summarize, the code sequence should be something like:
change a field in an acpi table
update checksum
clean_dcache_va_range on the table
[...]
unmap acpi table pages in Xen
map acpi pages in the guest
[...]
boot dom0
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 30/35] arm : acpi map XSDT table to dom0
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (28 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 29/35] arm : acpi enable PSCI and hvc in acpi FADT table parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 4:46 ` Julien Grall
2015-02-05 17:24 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 31/35] arm : acpi map status override " parth.dixit
` (5 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, julien.grall, tim, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
From: Parth Dixit <parth.dixit@linaro.org>
XSDT table cannot be passed as is to dom0 because new tables specific to xen
need to be added to its table entries
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/arch/arm/arm64/acpi/arm-core.c | 65 ++++++++++++++++++++++++++++++++++++--
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
index 9a26202..a210596 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -256,13 +256,74 @@ static void set_psci_fadt(void)
fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
}
+#define NR_NEW_XEN_TABLES 2
+
+static int map_xsdt_table(struct domain *d, u64 *xsdt)
+{
+ int res;
+ u64 size;
+ u64 addr = *xsdt;
+ u64 *new_xsdt;
+ struct acpi_table_header *table;
+ u64 *table_entry;
+ u8 checksum;
+
+ /* map xsdt table */
+ table = acpi_os_map_memory(addr, sizeof(struct acpi_table_header) );
+ size = table->length ;
+ acpi_os_unmap_memory(table, sizeof(struct acpi_table_header) );
+
+ table = acpi_os_map_memory(addr, size);
+ size += ( NR_NEW_XEN_TABLES*sizeof(acpi_native_uint) );
+ new_xsdt = ACPI_ALLOCATE_ZEROED(size);
+ if( new_xsdt == NULL)
+ return -ENOMEM;
+ ACPI_MEMCPY(new_xsdt, table,table->length);
+ acpi_os_unmap_memory(table, table->length);
+
+ table = (struct acpi_table_header *) new_xsdt;
+ table->length = size;
+ *xsdt = addr = virt_to_maddr(new_xsdt);
+
+ /* map xsdt region */
+ res = map_ram_regions(d,
+ paddr_to_pfn(addr & PAGE_MASK),
+ DIV_ROUND_UP(size, PAGE_SIZE),
+ paddr_to_pfn(addr & PAGE_MASK));
+ if ( res )
+ {
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+ " - 0x%"PRIx64" in domain \n",
+ addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+ }
+
+ table_entry = ACPI_CAST_PTR(u64,
+ ( ACPI_CAST_PTR(u8, new_xsdt) + sizeof(struct acpi_table_header) ) );
+ table_entry +=
+ ( ( (size - sizeof(struct acpi_table_header) ) /
+ sizeof(acpi_native_uint) ) );
+
+ checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table), table->length);
+ table->checksum = (u8)( table->checksum - checksum );
+ return 0;
+}
+
int acpi_map_tables(struct domain *d)
{
int i,res;
- u64 addr, size;
+ u64 addr, size, rsdp;
+ struct acpi_table_rsdp *rsdt;
+
+ addr = rsdp = acpi_os_get_root_pointer();
+ rsdt = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp) );
+ addr = rsdt->xsdt_physical_address;
+ map_xsdt_table(d, &addr);
+ rsdt->xsdt_physical_address = addr;
+ acpi_os_unmap_memory(rsdt, sizeof(struct acpi_table_rsdp) );
/* map rsdp table */
- addr = acpi_os_get_root_pointer();
+ addr = rsdp;
size = sizeof(struct acpi_table_rsdp);
res = map_ram_regions(d,
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 30/35] arm : acpi map XSDT table to dom0
2015-02-04 14:02 ` [PATCH RFC 30/35] arm : acpi map XSDT table to dom0 parth.dixit
@ 2015-02-05 4:46 ` Julien Grall
2015-02-05 17:24 ` Stefano Stabellini
1 sibling, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-05 4:46 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: christoffer.dall, tim, stefano.stabellini, ian.campbell, jbeulich
Hi Parth,
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> XSDT table cannot be passed as is to dom0 because new tables specific to xen
> need to be added to its table entries
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 65 ++++++++++++++++++++++++++++++++++++--
> 1 file changed, 63 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index 9a26202..a210596 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -256,13 +256,74 @@ static void set_psci_fadt(void)
> fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
> }
>
> +#define NR_NEW_XEN_TABLES 2
Please add a comment to specify what is the 2 new tables.
> +
> +static int map_xsdt_table(struct domain *d, u64 *xsdt)
> +{
> + int res;
> + u64 size;
> + u64 addr = *xsdt;
> + u64 *new_xsdt;
> + struct acpi_table_header *table;
> + u64 *table_entry;
> + u8 checksum;
> +
> + /* map xsdt table */
> + table = acpi_os_map_memory(addr, sizeof(struct acpi_table_header) );
No space before the last )
Also acpi_os_map_memory can fail.
> + size = table->length ;
No space before the ;
> + acpi_os_unmap_memory(table, sizeof(struct acpi_table_header) );
Ditto
> +
> + table = acpi_os_map_memory(addr, size);
acpi_os_map_memory can fail
> + size += ( NR_NEW_XEN_TABLES*sizeof(acpi_native_uint) );
(NR_NEW_XEN_TABLELS * sizeof(...));
> + new_xsdt = ACPI_ALLOCATE_ZEROED(size);
> + if( new_xsdt == NULL)
if ( ... )
> + return -ENOMEM;
> + ACPI_MEMCPY(new_xsdt, table,table->length);
Missing space after the comma.
> + acpi_os_unmap_memory(table, table->length);
> +
> + table = (struct acpi_table_header *) new_xsdt;
> + table->length = size;
> + *xsdt = addr = virt_to_maddr(new_xsdt);
> +
> + /* map xsdt region */
> + res = map_ram_regions(d,
> + paddr_to_pfn(addr & PAGE_MASK),
> + DIV_ROUND_UP(size, PAGE_SIZE),
> + paddr_to_pfn(addr & PAGE_MASK));
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> + " - 0x%"PRIx64" in domain \n",
> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> + return res;
> + }
> +
> + table_entry = ACPI_CAST_PTR(u64,
> + ( ACPI_CAST_PTR(u8, new_xsdt) + sizeof(struct acpi_table_header) ) );
Too much space in general.
> + table_entry +=
> + ( ( (size - sizeof(struct acpi_table_header) ) /
> + sizeof(acpi_native_uint) ) );
Ditto
> +
> + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table), table->length);
> + table->checksum = (u8)( table->checksum - checksum );
(table->checksum - checksum);
Also I'm not sure the the u8 cast is useful.
> + return 0;
> +}
> +
> int acpi_map_tables(struct domain *d)
> {
> int i,res;
> - u64 addr, size;
> + u64 addr, size, rsdp;
> + struct acpi_table_rsdp *rsdt;
> +
> + addr = rsdp = acpi_os_get_root_pointer();
Why do you set addr, but only use below rather than rsdp?
> + rsdt = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp) );
No space before )
> + addr = rsdt->xsdt_physical_address;
> + map_xsdt_table(d, &addr);
> + rsdt->xsdt_physical_address = addr;
> + acpi_os_unmap_memory(rsdt, sizeof(struct acpi_table_rsdp) );
No space before )
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 30/35] arm : acpi map XSDT table to dom0
2015-02-04 14:02 ` [PATCH RFC 30/35] arm : acpi map XSDT table to dom0 parth.dixit
2015-02-05 4:46 ` Julien Grall
@ 2015-02-05 17:24 ` Stefano Stabellini
1 sibling, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 17:24 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, julien.grall, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> XSDT table cannot be passed as is to dom0 because new tables specific to xen
> need to be added to its table entries
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 65 ++++++++++++++++++++++++++++++++++++--
> 1 file changed, 63 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index 9a26202..a210596 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -256,13 +256,74 @@ static void set_psci_fadt(void)
> fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
> }
>
> +#define NR_NEW_XEN_TABLES 2
> +
> +static int map_xsdt_table(struct domain *d, u64 *xsdt)
> +{
> + int res;
> + u64 size;
> + u64 addr = *xsdt;
> + u64 *new_xsdt;
> + struct acpi_table_header *table;
> + u64 *table_entry;
> + u8 checksum;
> +
> + /* map xsdt table */
> + table = acpi_os_map_memory(addr, sizeof(struct acpi_table_header) );
> + size = table->length ;
> + acpi_os_unmap_memory(table, sizeof(struct acpi_table_header) );
> +
> + table = acpi_os_map_memory(addr, size);
> + size += ( NR_NEW_XEN_TABLES*sizeof(acpi_native_uint) );
> + new_xsdt = ACPI_ALLOCATE_ZEROED(size);
> + if( new_xsdt == NULL)
> + return -ENOMEM;
> + ACPI_MEMCPY(new_xsdt, table,table->length);
code style, see CODING_STYLE
> + acpi_os_unmap_memory(table, table->length);
> +
> + table = (struct acpi_table_header *) new_xsdt;
> + table->length = size;
> + *xsdt = addr = virt_to_maddr(new_xsdt);
> +
> + /* map xsdt region */
> + res = map_ram_regions(d,
> + paddr_to_pfn(addr & PAGE_MASK),
> + DIV_ROUND_UP(size, PAGE_SIZE),
> + paddr_to_pfn(addr & PAGE_MASK));
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> + " - 0x%"PRIx64" in domain \n",
> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> + return res;
> + }
> +
> + table_entry = ACPI_CAST_PTR(u64,
> + ( ACPI_CAST_PTR(u8, new_xsdt) + sizeof(struct acpi_table_header) ) );
> + table_entry +=
> + ( ( (size - sizeof(struct acpi_table_header) ) /
> + sizeof(acpi_native_uint) ) );
I guess here you are going to add the STAO and XENV, right?
If so, please add at least a comment in this patch, otherwise can be
confusing to read.
> + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table), table->length);
> + table->checksum = (u8)( table->checksum - checksum );
> + return 0;
> +}
> +
> int acpi_map_tables(struct domain *d)
> {
> int i,res;
> - u64 addr, size;
> + u64 addr, size, rsdp;
> + struct acpi_table_rsdp *rsdt;
> +
> + addr = rsdp = acpi_os_get_root_pointer();
> + rsdt = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp) );
> + addr = rsdt->xsdt_physical_address;
> + map_xsdt_table(d, &addr);
> + rsdt->xsdt_physical_address = addr;
> + acpi_os_unmap_memory(rsdt, sizeof(struct acpi_table_rsdp) );
No need to update the checksum in acpi_table_rsdp?
> /* map rsdp table */
> - addr = acpi_os_get_root_pointer();
> + addr = rsdp;
> size = sizeof(struct acpi_table_rsdp);
>
> res = map_ram_regions(d,
> --
> 1.9.1
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 31/35] arm : acpi map status override table to dom0
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (29 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 30/35] arm : acpi map XSDT table to dom0 parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 5:24 ` Julien Grall
2015-02-05 17:27 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 32/35] arm : acpi map xen environment " parth.dixit
` (4 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, julien.grall, tim, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
From: Parth Dixit <parth.dixit@linaro.org>
hide UART used by xen by indicating it in STAO table
and map it to dom0
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/arch/arm/arm64/acpi/arm-core.c | 50 ++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
index a210596..9fd02f9 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -256,6 +256,48 @@ static void set_psci_fadt(void)
fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
}
+static int map_stao_table(struct domain *d, u64 *mstao)
+{
+ u64 addr;
+ u64 size;
+ int res;
+ u8 checksum;
+ struct acpi_table_stao *stao=NULL;
+
+ stao = ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_table_stao) );
+ if( stao == NULL )
+ return -ENOMEM;
+
+ ACPI_MEMCPY(stao->header.signature,ACPI_SIG_STAO, 4);
+ stao->header.length = sizeof(struct acpi_table_header) + 1;
+ stao->header.checksum = 0;
+ ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
+ ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
+ stao->header.revision = 1;
+ ACPI_MEMCPY(stao->header.asl_compiler_id, "INTL", 4);
+ stao->header.asl_compiler_revision = 0x20140828;
+ stao->uart = 1;
+ size = sizeof(struct acpi_table_stao);
+ checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), size);
+ stao->header.checksum = (u8)( stao->header.checksum - checksum );
+ *mstao = addr = virt_to_maddr(stao);
+
+ res = map_ram_regions(d,
+ paddr_to_pfn(addr & PAGE_MASK),
+ DIV_ROUND_UP(size, PAGE_SIZE),
+ paddr_to_pfn(addr & PAGE_MASK));
+ if ( res )
+ {
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+ " - 0x%"PRIx64" in domain \n",
+ addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+ }
+
+ return 0;
+}
+
+
#define NR_NEW_XEN_TABLES 2
static int map_xsdt_table(struct domain *d, u64 *xsdt)
@@ -304,6 +346,14 @@ static int map_xsdt_table(struct domain *d, u64 *xsdt)
( ( (size - sizeof(struct acpi_table_header) ) /
sizeof(acpi_native_uint) ) );
+ /* map stao table */
+ map_stao_table(d, &addr);
+ if(res)
+ return res;
+
+ table_entry--;
+ *table_entry = addr ;
+
checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table), table->length);
table->checksum = (u8)( table->checksum - checksum );
return 0;
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 31/35] arm : acpi map status override table to dom0
2015-02-04 14:02 ` [PATCH RFC 31/35] arm : acpi map status override " parth.dixit
@ 2015-02-05 5:24 ` Julien Grall
2015-02-05 10:57 ` Parth Dixit
2015-02-05 17:27 ` Stefano Stabellini
1 sibling, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-05 5:24 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: christoffer.dall, tim, stefano.stabellini, ian.campbell, jbeulich
Hi Parth,
You don't only map the status override table. You also create it.
I would update the commit title to reflect it.
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> hide UART used by xen by indicating it in STAO table
> and map it to dom0
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 50 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index a210596..9fd02f9 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -256,6 +256,48 @@ static void set_psci_fadt(void)
> fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
> }
>
> +static int map_stao_table(struct domain *d, u64 *mstao)
> +{
> + u64 addr;
> + u64 size;
> + int res;
> + u8 checksum;
> + struct acpi_table_stao *stao=NULL;
stao = NULL
> +
> + stao = ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_table_stao) );
No space before the last )
> + if( stao == NULL )
> + return -ENOMEM;
> +
> + ACPI_MEMCPY(stao->header.signature,ACPI_SIG_STAO, 4);
Space after comma
> + stao->header.length = sizeof(struct acpi_table_header) + 1;
> + stao->header.checksum = 0;
> + ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
> + ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
I though the plan was to use a Xen OEM ID?
> + stao->header.revision = 1;
> + ACPI_MEMCPY(stao->header.asl_compiler_id, "INTL", 4);
> + stao->header.asl_compiler_revision = 0x20140828;
Where does this revision comes from?
> + stao->uart = 1;
What about the devpath?
> + size = sizeof(struct acpi_table_stao);
> + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), size);
> + stao->header.checksum = (u8)( stao->header.checksum - checksum );
No space before the last )
> + *mstao = addr = virt_to_maddr(stao);
> +
> + res = map_ram_regions(d,
> + paddr_to_pfn(addr & PAGE_MASK),
> + DIV_ROUND_UP(size, PAGE_SIZE),
> + paddr_to_pfn(addr & PAGE_MASK));
I'm concerned with this mapping, as long as most of the others.
map_ram_regions is mapping Read/Write the region. In this case, the STAO
size may not be aligned to PAGE_SIZE.
So we may end up to map to DOM0 RW Xen memory. Even if DOM0 is a trusted
domain, we should never let DOM0 write in Xen memory.
IIRC, the plan was to map at least RO all the ACPI tables.
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> + " - 0x%"PRIx64" in domain \n",
> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> + return res;
> + }
> +
> + return 0;
> +}
> +
> +
> #define NR_NEW_XEN_TABLES 2
>
> static int map_xsdt_table(struct domain *d, u64 *xsdt)
> @@ -304,6 +346,14 @@ static int map_xsdt_table(struct domain *d, u64 *xsdt)
> ( ( (size - sizeof(struct acpi_table_header) ) /
> sizeof(acpi_native_uint) ) );
>
> + /* map stao table */
> + map_stao_table(d, &addr);
> + if(res)
if ( ... )
> + return res;
> +
> + table_entry--;
> + *table_entry = addr ;
> +
No space before ;
> checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table), table->length);
> table->checksum = (u8)( table->checksum - checksum );
No space before the last )
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 31/35] arm : acpi map status override table to dom0
2015-02-05 5:24 ` Julien Grall
@ 2015-02-05 10:57 ` Parth Dixit
2015-02-05 11:47 ` Ian Campbell
2015-02-05 14:39 ` Julien Grall
0 siblings, 2 replies; 166+ messages in thread
From: Parth Dixit @ 2015-02-05 10:57 UTC (permalink / raw)
To: Julien Grall
Cc: Ian Campbell, tim, xen-devel, Stefano Stabellini, Jan Beulich,
Christoffer Dall
On 5 February 2015 at 10:54, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Parth,
>
> You don't only map the status override table. You also create it.
> I would update the commit title to reflect it.
>
Sure, will take care in next patchset
> On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
>>
>> From: Parth Dixit <parth.dixit@linaro.org>
>>
>> hide UART used by xen by indicating it in STAO table
>> and map it to dom0
>>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>> xen/arch/arm/arm64/acpi/arm-core.c | 50
>> ++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 50 insertions(+)
>>
>> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c
>> b/xen/arch/arm/arm64/acpi/arm-core.c
>> index a210596..9fd02f9 100644
>> --- a/xen/arch/arm/arm64/acpi/arm-core.c
>> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
>> @@ -256,6 +256,48 @@ static void set_psci_fadt(void)
>> fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
>> }
>>
>> +static int map_stao_table(struct domain *d, u64 *mstao)
>> +{
>> + u64 addr;
>> + u64 size;
>> + int res;
>> + u8 checksum;
>> + struct acpi_table_stao *stao=NULL;
>
>
> stao = NULL
>
>> +
>> + stao = ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_table_stao) );
>
>
> No space before the last )
>
>> + if( stao == NULL )
>> + return -ENOMEM;
>> +
>> + ACPI_MEMCPY(stao->header.signature,ACPI_SIG_STAO, 4);
>
>
> Space after comma
>
>> + stao->header.length = sizeof(struct acpi_table_header) + 1;
>> + stao->header.checksum = 0;
>> + ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
>> + ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
>
>
> I though the plan was to use a Xen OEM ID?
yes, but its not clear what should be used as xen oem id is not finalized yet.
>> + stao->header.revision = 1;
>> + ACPI_MEMCPY(stao->header.asl_compiler_id, "INTL", 4);
>> + stao->header.asl_compiler_revision = 0x20140828;
>
>
> Where does this revision comes from?
from the spec
>> + stao->uart = 1;
>
>
> What about the devpath?
there is no table for devpath yet, it would require table specific handling
(mostly parsing) and it can then be updated in it, or maybe i can
create separate structure
which can be used here but element would be added at runtime for each table.
what do you think?
>> + size = sizeof(struct acpi_table_stao);
>> + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), size);
>> + stao->header.checksum = (u8)( stao->header.checksum - checksum );
>
>
> No space before the last )
>
>> + *mstao = addr = virt_to_maddr(stao);
>> +
>> + res = map_ram_regions(d,
>> + paddr_to_pfn(addr & PAGE_MASK),
>> + DIV_ROUND_UP(size, PAGE_SIZE),
>> + paddr_to_pfn(addr & PAGE_MASK));
>
>
> I'm concerned with this mapping, as long as most of the others.
> map_ram_regions is mapping Read/Write the region. In this case, the STAO
> size may not be aligned to PAGE_SIZE.
>
> So we may end up to map to DOM0 RW Xen memory. Even if DOM0 is a trusted
> domain, we should never let DOM0 write in Xen memory.
>
> IIRC, the plan was to map at least RO all the ACPI tables.
Sure, i'll map them to RO in next patchset.
>> + if ( res )
>> + {
>> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
>> + " - 0x%"PRIx64" in domain \n",
>> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
>> + return res;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +
>> #define NR_NEW_XEN_TABLES 2
>>
>> static int map_xsdt_table(struct domain *d, u64 *xsdt)
>> @@ -304,6 +346,14 @@ static int map_xsdt_table(struct domain *d, u64
>> *xsdt)
>> ( ( (size - sizeof(struct acpi_table_header) ) /
>> sizeof(acpi_native_uint) ) );
>>
>> + /* map stao table */
>> + map_stao_table(d, &addr);
>> + if(res)
>
>
> if ( ... )
>
>> + return res;
>> +
>> + table_entry--;
>> + *table_entry = addr ;
>> +
>
>
> No space before ;
>
>> checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table),
>> table->length);
>> table->checksum = (u8)( table->checksum - checksum );
>
>
> No space before the last )
>
> Regards,
>
> --
> Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 31/35] arm : acpi map status override table to dom0
2015-02-05 10:57 ` Parth Dixit
@ 2015-02-05 11:47 ` Ian Campbell
2015-02-11 9:45 ` Julien Grall
2015-02-05 14:39 ` Julien Grall
1 sibling, 1 reply; 166+ messages in thread
From: Ian Campbell @ 2015-02-05 11:47 UTC (permalink / raw)
To: Parth Dixit
Cc: Julien Grall, tim, xen-devel, Stefano Stabellini, Jan Beulich,
Christoffer Dall
On Thu, 2015-02-05 at 16:27 +0530, Parth Dixit wrote:
> >> + stao->header.length = sizeof(struct acpi_table_header) + 1;
> >> + stao->header.checksum = 0;
> >> + ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
> >> + ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
> >
> >
> > I though the plan was to use a Xen OEM ID?
> yes, but its not clear what should be used as xen oem id is not finalized yet.
Are these IDs the ones defined for x86 in
tools/firmware/hvmloader/acpi/acpi2_0.h:
#define ACPI_OEM_ID "Xen"
#define ACPI_OEM_TABLE_ID "HVM"
#define ACPI_OEM_REVISION 0
#define ACPI_CREATOR_ID ASCII32('H','V','M','L') /* HVMLoader */
#define ACPI_CREATOR_REVISION 0
? If so we should reuse them, although maybe not OEM_TABLE_ID and
CREATOR_ID since those are x86/HVM specific.
What is the process for assigning those? Given our unique OEM_ID are we
allowed to just declare them ourselves?
Ian.
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 31/35] arm : acpi map status override table to dom0
2015-02-05 11:47 ` Ian Campbell
@ 2015-02-11 9:45 ` Julien Grall
2015-02-12 6:50 ` Stefano Stabellini
0 siblings, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-11 9:45 UTC (permalink / raw)
To: Ian Campbell, Parth Dixit
Cc: tim, Stefano Stabellini, Christoffer Dall, Jan Beulich, xen-devel
Hi Ian,
On 05/02/2015 19:47, Ian Campbell wrote:
> On Thu, 2015-02-05 at 16:27 +0530, Parth Dixit wrote:
>>>> + stao->header.length = sizeof(struct acpi_table_header) + 1;
>>>> + stao->header.checksum = 0;
>>>> + ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
>>>> + ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
>>>
>>>
>>> I though the plan was to use a Xen OEM ID?
>> yes, but its not clear what should be used as xen oem id is not finalized yet.
>
> Are these IDs the ones defined for x86 in
> tools/firmware/hvmloader/acpi/acpi2_0.h:
> #define ACPI_OEM_ID "Xen"
> #define ACPI_OEM_TABLE_ID "HVM"
> #define ACPI_OEM_REVISION 0
>
> #define ACPI_CREATOR_ID ASCII32('H','V','M','L') /* HVMLoader */
> #define ACPI_CREATOR_REVISION 0
>
> ? If so we should reuse them, although maybe not OEM_TABLE_ID and
> CREATOR_ID since those are x86/HVM specific.
I didn't know that HVMLoader was using one.
"XenVMM" was decided for ARM (see see
http://wiki.xenproject.org/mediawiki/images/c/c4/Xen-environment-table.pdf).
Although, it would be good to have a single OEM ID for Xen project.
> What is the process for assigning those? Given our unique OEM_ID are we
> allowed to just declare them ourselves?
Stefano sent an email to the ACPI guys to know the process. I guess the
x86 one has not been declared?
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 31/35] arm : acpi map status override table to dom0
2015-02-11 9:45 ` Julien Grall
@ 2015-02-12 6:50 ` Stefano Stabellini
0 siblings, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-12 6:50 UTC (permalink / raw)
To: Julien Grall
Cc: Ian Campbell, tim, xen-devel, Stefano Stabellini, Jan Beulich,
Parth Dixit, Christoffer Dall
On Wed, 11 Feb 2015, Julien Grall wrote:
> Hi Ian,
>
> On 05/02/2015 19:47, Ian Campbell wrote:
> > On Thu, 2015-02-05 at 16:27 +0530, Parth Dixit wrote:
> > > > > + stao->header.length = sizeof(struct acpi_table_header) + 1;
> > > > > + stao->header.checksum = 0;
> > > > > + ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
> > > > > + ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
> > > >
> > > >
> > > > I though the plan was to use a Xen OEM ID?
> > > yes, but its not clear what should be used as xen oem id is not finalized
> > > yet.
> >
> > Are these IDs the ones defined for x86 in
> > tools/firmware/hvmloader/acpi/acpi2_0.h:
> > #define ACPI_OEM_ID "Xen"
> > #define ACPI_OEM_TABLE_ID "HVM"
> > #define ACPI_OEM_REVISION 0
> >
> > #define ACPI_CREATOR_ID ASCII32('H','V','M','L') /*
> > HVMLoader */
> > #define ACPI_CREATOR_REVISION 0
> >
> > ? If so we should reuse them, although maybe not OEM_TABLE_ID and
> > CREATOR_ID since those are x86/HVM specific.
>
> I didn't know that HVMLoader was using one.
>
> "XenVMM" was decided for ARM (see see
> http://wiki.xenproject.org/mediawiki/images/c/c4/Xen-environment-table.pdf).
>
> Although, it would be good to have a single OEM ID for Xen project.
>
> > What is the process for assigning those? Given our unique OEM_ID are we
> > allowed to just declare them ourselves?
>
> Stefano sent an email to the ACPI guys to know the process. I guess the x86
> one has not been declared?
I don't know the process but on x86 we are already using "Xen" as
OEM_ID, see tools/firmware/hvmloader/acpi/acpi2_0.h
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 31/35] arm : acpi map status override table to dom0
2015-02-05 10:57 ` Parth Dixit
2015-02-05 11:47 ` Ian Campbell
@ 2015-02-05 14:39 ` Julien Grall
2015-02-05 17:39 ` Stefano Stabellini
1 sibling, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-05 14:39 UTC (permalink / raw)
To: Parth Dixit
Cc: Ian Campbell, tim, xen-devel, Stefano Stabellini, Jan Beulich,
Christoffer Dall
Hi Parth,
On 05/02/2015 18:57, Parth Dixit wrote:
> On 5 February 2015 at 10:54, Julien Grall <julien.grall@linaro.org> wrote:
>> On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
>>> + stao->header.length = sizeof(struct acpi_table_header) + 1;
>>> + stao->header.checksum = 0;
>>> + ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
>>> + ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
>>
>>
>> I though the plan was to use a Xen OEM ID?
> yes, but its not clear what should be used as xen oem id is not finalized yet.
I though we decided a name on the email, what is missing?
>>> + stao->header.revision = 1;
>>> + ACPI_MEMCPY(stao->header.asl_compiler_id, "INTL", 4);
>>> + stao->header.asl_compiler_revision = 0x20140828;
>>
>>
>> Where does this revision comes from?
> from the spec
What do you mean? I didn't know that the spec requires a specific
compiler version... IHMO, this would be wrong.
>>> + stao->uart = 1;
>>
>>
>> What about the devpath?
> there is no table for devpath yet, it would require table specific handling
> (mostly parsing) and it can then be updated in it, or maybe i can
> create separate structure
> which can be used here but element would be added at runtime for each table.
> what do you think?
The devpath is a list of device blacklisted by path, right? If so, the
comment on the field devpath is wrong. Also, it's defined as u8[1],
which is very confusing.
>>> + size = sizeof(struct acpi_table_stao);
>>> + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), size);
>>> + stao->header.checksum = (u8)( stao->header.checksum - checksum );
>>
>>
>> No space before the last )
>>
>>> + *mstao = addr = virt_to_maddr(stao);
>>> +
>>> + res = map_ram_regions(d,
>>> + paddr_to_pfn(addr & PAGE_MASK),
>>> + DIV_ROUND_UP(size, PAGE_SIZE),
>>> + paddr_to_pfn(addr & PAGE_MASK));
>>
>>
>> I'm concerned with this mapping, as long as most of the others.
>> map_ram_regions is mapping Read/Write the region. In this case, the STAO
>> size may not be aligned to PAGE_SIZE.
>>
>> So we may end up to map to DOM0 RW Xen memory. Even if DOM0 is a trusted
>> domain, we should never let DOM0 write in Xen memory.
>>
>> IIRC, the plan was to map at least RO all the ACPI tables.
> Sure, i'll map them to RO in next patchset.
I didn't say this is the right solution ;). It was something I recall
from a discussion we had few months ago.
So before using this solution, can anyone (re-)confirm me that the ACPI
tables should not be modified by the guest? If so, this should also be
written somewhere for documentation purpose. It may save time in the
future :).
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 31/35] arm : acpi map status override table to dom0
2015-02-05 14:39 ` Julien Grall
@ 2015-02-05 17:39 ` Stefano Stabellini
2015-02-06 0:54 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 17:39 UTC (permalink / raw)
To: Julien Grall
Cc: Ian Campbell, tim, xen-devel, Stefano Stabellini, Jan Beulich,
Parth Dixit, Christoffer Dall
On Thu, 5 Feb 2015, Julien Grall wrote:
> Hi Parth,
>
> On 05/02/2015 18:57, Parth Dixit wrote:
> > On 5 February 2015 at 10:54, Julien Grall <julien.grall@linaro.org> wrote:
> > > On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> > > > + stao->header.length = sizeof(struct acpi_table_header) + 1;
> > > > + stao->header.checksum = 0;
> > > > + ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
> > > > + ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
> > >
> > >
> > > I though the plan was to use a Xen OEM ID?
> > yes, but its not clear what should be used as xen oem id is not finalized
> > yet.
>
> I though we decided a name on the email, what is missing?
>
> > > > + stao->header.revision = 1;
> > > > + ACPI_MEMCPY(stao->header.asl_compiler_id, "INTL", 4);
> > > > + stao->header.asl_compiler_revision = 0x20140828;
> > >
> > >
> > > Where does this revision comes from?
> > from the spec
>
> What do you mean? I didn't know that the spec requires a specific compiler
> version... IHMO, this would be wrong.
>
> > > > + stao->uart = 1;
> > >
> > >
> > > What about the devpath?
> > there is no table for devpath yet, it would require table specific handling
> > (mostly parsing) and it can then be updated in it, or maybe i can
> > create separate structure
> > which can be used here but element would be added at runtime for each table.
> > what do you think?
>
> The devpath is a list of device blacklisted by path, right? If so, the comment
> on the field devpath is wrong. Also, it's defined as u8[1], which is very
> confusing.
>
> > > > + size = sizeof(struct acpi_table_stao);
> > > > + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), size);
> > > > + stao->header.checksum = (u8)( stao->header.checksum - checksum );
> > >
> > >
> > > No space before the last )
> > >
> > > > + *mstao = addr = virt_to_maddr(stao);
> > > > +
> > > > + res = map_ram_regions(d,
> > > > + paddr_to_pfn(addr & PAGE_MASK),
> > > > + DIV_ROUND_UP(size, PAGE_SIZE),
> > > > + paddr_to_pfn(addr & PAGE_MASK));
> > >
> > >
> > > I'm concerned with this mapping, as long as most of the others.
> > > map_ram_regions is mapping Read/Write the region. In this case, the STAO
> > > size may not be aligned to PAGE_SIZE.
> > >
> > > So we may end up to map to DOM0 RW Xen memory. Even if DOM0 is a trusted
> > > domain, we should never let DOM0 write in Xen memory.
> > >
> > > IIRC, the plan was to map at least RO all the ACPI tables.
> > Sure, i'll map them to RO in next patchset.
>
> I didn't say this is the right solution ;). It was something I recall from a
> discussion we had few months ago.
>
> So before using this solution, can anyone (re-)confirm me that the ACPI tables
> should not be modified by the guest? If so, this should also be written
> somewhere for documentation purpose. It may save time in the future :).
At this point we are completely trusting dom0 with the ACPI tables, I am
not sure how much we would gain by mapping the tables RO.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 31/35] arm : acpi map status override table to dom0
2015-02-05 17:39 ` Stefano Stabellini
@ 2015-02-06 0:54 ` Julien Grall
2015-02-06 14:32 ` Stefano Stabellini
0 siblings, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-06 0:54 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Ian Campbell, tim, xen-devel, Stefano Stabellini, Jan Beulich,
Parth Dixit, Christoffer Dall
On 06/02/2015 01:39, Stefano Stabellini wrote:
> On Thu, 5 Feb 2015, Julien Grall wrote:
>> Hi Parth,
>>
>> On 05/02/2015 18:57, Parth Dixit wrote:
>>> On 5 February 2015 at 10:54, Julien Grall <julien.grall@linaro.org> wrote:
>>>> On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
>>>>> + stao->header.length = sizeof(struct acpi_table_header) + 1;
>>>>> + stao->header.checksum = 0;
>>>>> + ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
>>>>> + ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
>>>>
>>>>
>>>> I though the plan was to use a Xen OEM ID?
>>> yes, but its not clear what should be used as xen oem id is not finalized
>>> yet.
>>
>> I though we decided a name on the email, what is missing?
>>
>>>>> + stao->header.revision = 1;
>>>>> + ACPI_MEMCPY(stao->header.asl_compiler_id, "INTL", 4);
>>>>> + stao->header.asl_compiler_revision = 0x20140828;
>>>>
>>>>
>>>> Where does this revision comes from?
>>> from the spec
>>
>> What do you mean? I didn't know that the spec requires a specific compiler
>> version... IHMO, this would be wrong.
>>
>>>>> + stao->uart = 1;
>>>>
>>>>
>>>> What about the devpath?
>>> there is no table for devpath yet, it would require table specific handling
>>> (mostly parsing) and it can then be updated in it, or maybe i can
>>> create separate structure
>>> which can be used here but element would be added at runtime for each table.
>>> what do you think?
>>
>> The devpath is a list of device blacklisted by path, right? If so, the comment
>> on the field devpath is wrong. Also, it's defined as u8[1], which is very
>> confusing.
>>
>>>>> + size = sizeof(struct acpi_table_stao);
>>>>> + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), size);
>>>>> + stao->header.checksum = (u8)( stao->header.checksum - checksum );
>>>>
>>>>
>>>> No space before the last )
>>>>
>>>>> + *mstao = addr = virt_to_maddr(stao);
>>>>> +
>>>>> + res = map_ram_regions(d,
>>>>> + paddr_to_pfn(addr & PAGE_MASK),
>>>>> + DIV_ROUND_UP(size, PAGE_SIZE),
>>>>> + paddr_to_pfn(addr & PAGE_MASK));
>>>>
>>>>
>>>> I'm concerned with this mapping, as long as most of the others.
>>>> map_ram_regions is mapping Read/Write the region. In this case, the STAO
>>>> size may not be aligned to PAGE_SIZE.
>>>>
>>>> So we may end up to map to DOM0 RW Xen memory. Even if DOM0 is a trusted
>>>> domain, we should never let DOM0 write in Xen memory.
>>>>
>>>> IIRC, the plan was to map at least RO all the ACPI tables.
>>> Sure, i'll map them to RO in next patchset.
>>
>> I didn't say this is the right solution ;). It was something I recall from a
>> discussion we had few months ago.
>>
>> So before using this solution, can anyone (re-)confirm me that the ACPI tables
>> should not be modified by the guest? If so, this should also be written
>> somewhere for documentation purpose. It may save time in the future :).
>
> At this point we are completely trusting dom0 with the ACPI tables, I am
> not sure how much we would gain by mapping the tables RO.
I agree that we trust DOM0... but in this specific case, because of the
page-alignment requirement, we may expose Xen memory/Guest data.
The Read-Only solution would avoid DOM0 to write in the such zone and
mess up the hypervisor by mistake.
FYI, we had a thread about it a couple of months ago. And it was
confirmed that ACPI is RO at least from guest POV. (I could re-forward
you the mail if necessary). So it's better to map Read-Only just in case.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 31/35] arm : acpi map status override table to dom0
2015-02-06 0:54 ` Julien Grall
@ 2015-02-06 14:32 ` Stefano Stabellini
0 siblings, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-06 14:32 UTC (permalink / raw)
To: Julien Grall
Cc: Ian Campbell, Stefano Stabellini, tim, xen-devel,
Stefano Stabellini, Jan Beulich, Parth Dixit, Christoffer Dall
On Fri, 6 Feb 2015, Julien Grall wrote:
> On 06/02/2015 01:39, Stefano Stabellini wrote:
> > On Thu, 5 Feb 2015, Julien Grall wrote:
> > > Hi Parth,
> > >
> > > On 05/02/2015 18:57, Parth Dixit wrote:
> > > > On 5 February 2015 at 10:54, Julien Grall <julien.grall@linaro.org>
> > > > wrote:
> > > > > On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> > > > > > + stao->header.length = sizeof(struct acpi_table_header) + 1;
> > > > > > + stao->header.checksum = 0;
> > > > > > + ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
> > > > > > + ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
> > > > >
> > > > >
> > > > > I though the plan was to use a Xen OEM ID?
> > > > yes, but its not clear what should be used as xen oem id is not
> > > > finalized
> > > > yet.
> > >
> > > I though we decided a name on the email, what is missing?
> > >
> > > > > > + stao->header.revision = 1;
> > > > > > + ACPI_MEMCPY(stao->header.asl_compiler_id, "INTL", 4);
> > > > > > + stao->header.asl_compiler_revision = 0x20140828;
> > > > >
> > > > >
> > > > > Where does this revision comes from?
> > > > from the spec
> > >
> > > What do you mean? I didn't know that the spec requires a specific compiler
> > > version... IHMO, this would be wrong.
> > >
> > > > > > + stao->uart = 1;
> > > > >
> > > > >
> > > > > What about the devpath?
> > > > there is no table for devpath yet, it would require table specific
> > > > handling
> > > > (mostly parsing) and it can then be updated in it, or maybe i can
> > > > create separate structure
> > > > which can be used here but element would be added at runtime for each
> > > > table.
> > > > what do you think?
> > >
> > > The devpath is a list of device blacklisted by path, right? If so, the
> > > comment
> > > on the field devpath is wrong. Also, it's defined as u8[1], which is very
> > > confusing.
> > >
> > > > > > + size = sizeof(struct acpi_table_stao);
> > > > > > + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), size);
> > > > > > + stao->header.checksum = (u8)( stao->header.checksum - checksum
> > > > > > );
> > > > >
> > > > >
> > > > > No space before the last )
> > > > >
> > > > > > + *mstao = addr = virt_to_maddr(stao);
> > > > > > +
> > > > > > + res = map_ram_regions(d,
> > > > > > + paddr_to_pfn(addr & PAGE_MASK),
> > > > > > + DIV_ROUND_UP(size, PAGE_SIZE),
> > > > > > + paddr_to_pfn(addr & PAGE_MASK));
> > > > >
> > > > >
> > > > > I'm concerned with this mapping, as long as most of the others.
> > > > > map_ram_regions is mapping Read/Write the region. In this case, the
> > > > > STAO
> > > > > size may not be aligned to PAGE_SIZE.
> > > > >
> > > > > So we may end up to map to DOM0 RW Xen memory. Even if DOM0 is a
> > > > > trusted
> > > > > domain, we should never let DOM0 write in Xen memory.
> > > > >
> > > > > IIRC, the plan was to map at least RO all the ACPI tables.
> > > > Sure, i'll map them to RO in next patchset.
> > >
> > > I didn't say this is the right solution ;). It was something I recall from
> > > a
> > > discussion we had few months ago.
> > >
> > > So before using this solution, can anyone (re-)confirm me that the ACPI
> > > tables
> > > should not be modified by the guest? If so, this should also be written
> > > somewhere for documentation purpose. It may save time in the future :).
> >
> > At this point we are completely trusting dom0 with the ACPI tables, I am
> > not sure how much we would gain by mapping the tables RO.
>
> I agree that we trust DOM0... but in this specific case, because of the
> page-alignment requirement, we may expose Xen memory/Guest data.
This would be terrible!
I was assuming that all ACPI tables addresses are page aligned and sizes
are page aligned too. Is that true?
If not, is unacceptable to map them the entire page RW in Dom0.
> The Read-Only solution would avoid DOM0 to write in the such zone and mess up
> the hypervisor by mistake.
It is the minimum that we can do.
> FYI, we had a thread about it a couple of months ago. And it was confirmed
> that ACPI is RO at least from guest POV. (I could re-forward you the mail if
> necessary). So it's better to map Read-Only just in case.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 31/35] arm : acpi map status override table to dom0
2015-02-04 14:02 ` [PATCH RFC 31/35] arm : acpi map status override " parth.dixit
2015-02-05 5:24 ` Julien Grall
@ 2015-02-05 17:27 ` Stefano Stabellini
1 sibling, 0 replies; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 17:27 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, julien.grall, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> hide UART used by xen by indicating it in STAO table
> and map it to dom0
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
Please check CODING_STYLE
> xen/arch/arm/arm64/acpi/arm-core.c | 50 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index a210596..9fd02f9 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -256,6 +256,48 @@ static void set_psci_fadt(void)
> fadt->header.checksum = (u8)( fadt->header.checksum-checksum );
> }
>
> +static int map_stao_table(struct domain *d, u64 *mstao)
> +{
> + u64 addr;
> + u64 size;
> + int res;
> + u8 checksum;
> + struct acpi_table_stao *stao=NULL;
> +
> + stao = ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_table_stao) );
> + if( stao == NULL )
> + return -ENOMEM;
> +
> + ACPI_MEMCPY(stao->header.signature,ACPI_SIG_STAO, 4);
> + stao->header.length = sizeof(struct acpi_table_header) + 1;
> + stao->header.checksum = 0;
> + ACPI_MEMCPY(stao->header.oem_id, "LINARO", 6);
> + ACPI_MEMCPY(stao->header.oem_table_id, "RTSMVEV8", 8);
> + stao->header.revision = 1;
> + ACPI_MEMCPY(stao->header.asl_compiler_id, "INTL", 4);
> + stao->header.asl_compiler_revision = 0x20140828;
> + stao->uart = 1;
> + size = sizeof(struct acpi_table_stao);
> + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, stao), size);
> + stao->header.checksum = (u8)( stao->header.checksum - checksum );
> + *mstao = addr = virt_to_maddr(stao);
> +
> + res = map_ram_regions(d,
> + paddr_to_pfn(addr & PAGE_MASK),
> + DIV_ROUND_UP(size, PAGE_SIZE),
> + paddr_to_pfn(addr & PAGE_MASK));
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> + " - 0x%"PRIx64" in domain \n",
> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> + return res;
> + }
> +
> + return 0;
> +}
> +
> +
> #define NR_NEW_XEN_TABLES 2
>
> static int map_xsdt_table(struct domain *d, u64 *xsdt)
> @@ -304,6 +346,14 @@ static int map_xsdt_table(struct domain *d, u64 *xsdt)
> ( ( (size - sizeof(struct acpi_table_header) ) /
> sizeof(acpi_native_uint) ) );
>
> + /* map stao table */
> + map_stao_table(d, &addr);
> + if(res)
> + return res;
> +
> + table_entry--;
> + *table_entry = addr ;
> +
> checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, table), table->length);
> table->checksum = (u8)( table->checksum - checksum );
> return 0;
> --
> 1.9.1
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 32/35] arm : acpi map xen environment table to dom0
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (30 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 31/35] arm : acpi map status override " parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 5:29 ` Julien Grall
2015-02-05 17:36 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 33/35] arm : acpi enable efi for acpi parth.dixit
` (3 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, julien.grall, tim, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
From: Parth Dixit <parth.dixit@linaro.org>
xen environment table contains the grant table address,size and event
channel interrupt information required by dom0.
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/arch/arm/arm64/acpi/arm-core.c | 52 +++++++++++++++++++++++++++++++++++++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
index 9fd02f9..9e9285c 100644
--- a/xen/arch/arm/arm64/acpi/arm-core.c
+++ b/xen/arch/arm/arm64/acpi/arm-core.c
@@ -33,7 +33,6 @@
#include <asm/cputype.h>
#include <asm/acpi.h>
#include <asm/p2m.h>
-
/*
* We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
* variable is still required by the ACPI core
@@ -297,6 +296,49 @@ static int map_stao_table(struct domain *d, u64 *mstao)
return 0;
}
+static int map_xenv_table(struct domain *d, u64 *mxenv)
+{
+ u64 addr;
+ u64 size;
+ int res;
+ u8 checksum;
+ struct acpi_table_xenv *xenv=NULL;
+
+ xenv = ACPI_ALLOCATE_ZEROED( sizeof(struct acpi_table_xenv) );
+ if( xenv == NULL )
+ return -ENOMEM;
+
+ ACPI_MEMCPY(xenv->header.signature, ACPI_SIG_XENV, 4);
+ xenv->header.length = sizeof(struct acpi_table_header)+12;
+ xenv->header.checksum = 0;
+ ACPI_MEMCPY(xenv->header.oem_id, "XenVMM", 6);
+ ACPI_MEMCPY(xenv->header.oem_table_id, "RTSMVEV8", 8);
+ xenv->header.revision = 1;
+ ACPI_MEMCPY(xenv->header.asl_compiler_id, "INTL", 4);
+ xenv->header.asl_compiler_revision = 0x20140828;
+ xenv->gnt_start = 0x00000010000000;
+ xenv->gnt_size = 0x20000;
+ xenv->evt_intr = 31;
+ xenv->evt_intr_flag =3;
+ size = sizeof(struct acpi_table_xenv);
+ checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, xenv), size);
+ xenv->header.checksum = (u8)( xenv->header.checksum - checksum );
+ *mxenv = addr = virt_to_maddr(xenv);
+
+ res = map_ram_regions(d,
+ paddr_to_pfn(addr & PAGE_MASK),
+ DIV_ROUND_UP(size, PAGE_SIZE),
+ paddr_to_pfn(addr & PAGE_MASK));
+ if ( res )
+ {
+ printk(XENLOG_ERR "Unable to map 0x%"PRIx64
+ " - 0x%"PRIx64" in domain \n",
+ addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ return res;
+ }
+
+ return 0;
+}
#define NR_NEW_XEN_TABLES 2
@@ -346,6 +388,14 @@ static int map_xsdt_table(struct domain *d, u64 *xsdt)
( ( (size - sizeof(struct acpi_table_header) ) /
sizeof(acpi_native_uint) ) );
+ /* map xen env table */
+ res = map_xenv_table(d, &addr);
+ if(res)
+ return res;
+
+ table_entry--;
+ *table_entry = addr ;
+
/* map stao table */
map_stao_table(d, &addr);
if(res)
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 32/35] arm : acpi map xen environment table to dom0
2015-02-04 14:02 ` [PATCH RFC 32/35] arm : acpi map xen environment " parth.dixit
@ 2015-02-05 5:29 ` Julien Grall
2015-02-05 10:49 ` Parth Dixit
2015-02-05 17:36 ` Stefano Stabellini
1 sibling, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-05 5:29 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: christoffer.dall, tim, stefano.stabellini, ian.campbell, jbeulich
Hi Parth,
As for the STAO table, this is not only mapping but also creating the table.
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> xen environment table contains the grant table address,size and event
, size
> channel interrupt information required by dom0.
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 52 +++++++++++++++++++++++++++++++++++++-
> 1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index 9fd02f9..9e9285c 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -33,7 +33,6 @@
> #include <asm/cputype.h>
> #include <asm/acpi.h>
> #include <asm/p2m.h>
> -
Spurious change.
> /*
> * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> * variable is still required by the ACPI core
> @@ -297,6 +296,49 @@ static int map_stao_table(struct domain *d, u64 *mstao)
> return 0;
> }
>
> +static int map_xenv_table(struct domain *d, u64 *mxenv)
> +{
> + u64 addr;
> + u64 size;
> + int res;
> + u8 checksum;
> + struct acpi_table_xenv *xenv=NULL;
*xenv = NULL
> +
> + xenv = ACPI_ALLOCATE_ZEROED( sizeof(struct acpi_table_xenv) );
No space necessary after the first ( and before the last )
> + if( xenv == NULL )
> + return -ENOMEM;
> +
> + ACPI_MEMCPY(xenv->header.signature, ACPI_SIG_XENV, 4);
> + xenv->header.length = sizeof(struct acpi_table_header)+12;
Where does the 12 comes from?
> + xenv->header.checksum = 0;
> + ACPI_MEMCPY(xenv->header.oem_id, "XenVMM", 6);
> + ACPI_MEMCPY(xenv->header.oem_table_id, "RTSMVEV8", 8);
RTSMVEV8? Why?
> + xenv->header.revision = 1;
> + ACPI_MEMCPY(xenv->header.asl_compiler_id, "INTL", 4);
> + xenv->header.asl_compiler_revision = 0x20140828;
Why this compiler revision?
> + xenv->gnt_start = 0x00000010000000;
> + xenv->gnt_size = 0x20000;
This is hardcoded. Even if you precise it in the cover letter, you
should make clear in the patch that we have hardcoded.
> + xenv->evt_intr = 31;
> + xenv->evt_intr_flag =3;
Ditto
Also intr_flag = 3; and please use define rather than a value.
> + size = sizeof(struct acpi_table_xenv);
> + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, xenv), size);
> + xenv->header.checksum = (u8)( xenv->header.checksum - checksum );
No space after the ( and before )
> + *mxenv = addr = virt_to_maddr(xenv);
> +
> + res = map_ram_regions(d,
> + paddr_to_pfn(addr & PAGE_MASK),
> + DIV_ROUND_UP(size, PAGE_SIZE),
> + paddr_to_pfn(addr & PAGE_MASK));
Same remark as for the Xen Environment table (see patch #31).
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> + " - 0x%"PRIx64" in domain \n",
> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> + return res;
> + }
> +
> + return 0;
> +}
>
> #define NR_NEW_XEN_TABLES 2
>
> @@ -346,6 +388,14 @@ static int map_xsdt_table(struct domain *d, u64 *xsdt)
> ( ( (size - sizeof(struct acpi_table_header) ) /
> sizeof(acpi_native_uint) ) );
>
> + /* map xen env table */
> + res = map_xenv_table(d, &addr);
> + if(res)
> + return res;
> +
> + table_entry--;
> + *table_entry = addr ;
> +
No space before ;
> /* map stao table */
> map_stao_table(d, &addr);
> if(res)
>
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 32/35] arm : acpi map xen environment table to dom0
2015-02-05 5:29 ` Julien Grall
@ 2015-02-05 10:49 ` Parth Dixit
0 siblings, 0 replies; 166+ messages in thread
From: Parth Dixit @ 2015-02-05 10:49 UTC (permalink / raw)
To: Julien Grall
Cc: Ian Campbell, tim, xen-devel, Stefano Stabellini, Jan Beulich,
Christoffer Dall
On 5 February 2015 at 10:59, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Parth,
>
> As for the STAO table, this is not only mapping but also creating the table.
>
> On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
>>
>> From: Parth Dixit <parth.dixit@linaro.org>
>>
>> xen environment table contains the grant table address,size and event
>
>
> , size
>
>> channel interrupt information required by dom0.
>>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>> xen/arch/arm/arm64/acpi/arm-core.c | 52
>> +++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 51 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c
>> b/xen/arch/arm/arm64/acpi/arm-core.c
>> index 9fd02f9..9e9285c 100644
>> --- a/xen/arch/arm/arm64/acpi/arm-core.c
>> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
>> @@ -33,7 +33,6 @@
>> #include <asm/cputype.h>
>> #include <asm/acpi.h>
>> #include <asm/p2m.h>
>> -
>
>
> Spurious change.
>
>> /*
>> * We never plan to use RSDT on arm/arm64 as its deprecated in spec but
>> this
>> * variable is still required by the ACPI core
>> @@ -297,6 +296,49 @@ static int map_stao_table(struct domain *d, u64
>> *mstao)
>> return 0;
>> }
>>
>> +static int map_xenv_table(struct domain *d, u64 *mxenv)
>> +{
>> + u64 addr;
>> + u64 size;
>> + int res;
>> + u8 checksum;
>> + struct acpi_table_xenv *xenv=NULL;
>
>
> *xenv = NULL
>
>> +
>> + xenv = ACPI_ALLOCATE_ZEROED( sizeof(struct acpi_table_xenv) );
>
>
> No space necessary after the first ( and before the last )
>
>> + if( xenv == NULL )
>> + return -ENOMEM;
>> +
>> + ACPI_MEMCPY(xenv->header.signature, ACPI_SIG_XENV, 4);
>> + xenv->header.length = sizeof(struct acpi_table_header)+12;
>
>
> Where does the 12 comes from?
its total size - sizeof(struct acpi_table_header)
i will remove the hardcoing, as this table does not contain variable
length element
i can use sizeof at compile time to determine total size.
will take care in next patch
>> + xenv->header.checksum = 0;
>> + ACPI_MEMCPY(xenv->header.oem_id, "XenVMM", 6);
>> + ACPI_MEMCPY(xenv->header.oem_table_id, "RTSMVEV8", 8);
>
>
> RTSMVEV8? Why?
Because oem id is not finalized yet
>> + xenv->header.revision = 1;
>> + ACPI_MEMCPY(xenv->header.asl_compiler_id, "INTL", 4);
>> + xenv->header.asl_compiler_revision = 0x20140828;
>
>
> Why this compiler revision?
will remove it in next patchset, base it on the id of any existing table.
>> + xenv->gnt_start = 0x00000010000000;
>> + xenv->gnt_size = 0x20000;
>
>
> This is hardcoded. Even if you precise it in the cover letter, you should
> make clear in the patch that we have hardcoded.
sure, will do it in next patchset
>> + xenv->evt_intr = 31;
>> + xenv->evt_intr_flag =3;
>
>
> Ditto
>
> Also intr_flag = 3; and please use define rather than a value.
>
>> + size = sizeof(struct acpi_table_xenv);
>> + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, xenv), size);
>> + xenv->header.checksum = (u8)( xenv->header.checksum - checksum );
>
>
> No space after the ( and before )
>
>> + *mxenv = addr = virt_to_maddr(xenv);
>> +
>> + res = map_ram_regions(d,
>> + paddr_to_pfn(addr & PAGE_MASK),
>> + DIV_ROUND_UP(size, PAGE_SIZE),
>> + paddr_to_pfn(addr & PAGE_MASK));
>
>
> Same remark as for the Xen Environment table (see patch #31).
>
>> + if ( res )
>> + {
>> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
>> + " - 0x%"PRIx64" in domain \n",
>> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
>> + return res;
>> + }
>> +
>> + return 0;
>> +}
>>
>> #define NR_NEW_XEN_TABLES 2
>>
>> @@ -346,6 +388,14 @@ static int map_xsdt_table(struct domain *d, u64
>> *xsdt)
>> ( ( (size - sizeof(struct acpi_table_header) ) /
>> sizeof(acpi_native_uint) ) );
>>
>> + /* map xen env table */
>> + res = map_xenv_table(d, &addr);
>> + if(res)
>> + return res;
>> +
>> + table_entry--;
>> + *table_entry = addr ;
>> +
>
>
> No space before ;
>
>> /* map stao table */
>> map_stao_table(d, &addr);
>> if(res)
>>
>
> Regards,
>
> --
> Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 32/35] arm : acpi map xen environment table to dom0
2015-02-04 14:02 ` [PATCH RFC 32/35] arm : acpi map xen environment " parth.dixit
2015-02-05 5:29 ` Julien Grall
@ 2015-02-05 17:36 ` Stefano Stabellini
2015-02-06 0:57 ` Julien Grall
1 sibling, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 17:36 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, julien.grall, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> xen environment table contains the grant table address,size and event
> channel interrupt information required by dom0.
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/arm64/acpi/arm-core.c | 52 +++++++++++++++++++++++++++++++++++++-
> 1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
> index 9fd02f9..9e9285c 100644
> --- a/xen/arch/arm/arm64/acpi/arm-core.c
> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
> @@ -33,7 +33,6 @@
> #include <asm/cputype.h>
> #include <asm/acpi.h>
> #include <asm/p2m.h>
> -
> /*
> * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> * variable is still required by the ACPI core
Spurious change
> @@ -297,6 +296,49 @@ static int map_stao_table(struct domain *d, u64 *mstao)
> return 0;
> }
>
> +static int map_xenv_table(struct domain *d, u64 *mxenv)
> +{
> + u64 addr;
> + u64 size;
> + int res;
> + u8 checksum;
> + struct acpi_table_xenv *xenv=NULL;
> +
> + xenv = ACPI_ALLOCATE_ZEROED( sizeof(struct acpi_table_xenv) );
> + if( xenv == NULL )
> + return -ENOMEM;
> +
> + ACPI_MEMCPY(xenv->header.signature, ACPI_SIG_XENV, 4);
> + xenv->header.length = sizeof(struct acpi_table_header)+12;
> + xenv->header.checksum = 0;
> + ACPI_MEMCPY(xenv->header.oem_id, "XenVMM", 6);
> + ACPI_MEMCPY(xenv->header.oem_table_id, "RTSMVEV8", 8);
> + xenv->header.revision = 1;
> + ACPI_MEMCPY(xenv->header.asl_compiler_id, "INTL", 4);
> + xenv->header.asl_compiler_revision = 0x20140828;
> + xenv->gnt_start = 0x00000010000000;
> + xenv->gnt_size = 0x20000;
> + xenv->evt_intr = 31;
> + xenv->evt_intr_flag =3;
> + size = sizeof(struct acpi_table_xenv);
As per all the other checksum calculation, I wonder whether we need a
memory barrier here.
> + checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, xenv), size);
> + xenv->header.checksum = (u8)( xenv->header.checksum - checksum );
> + *mxenv = addr = virt_to_maddr(xenv);
Given that this is way before we start dom0, I don't think we need any
memory barriers here.
> + res = map_ram_regions(d,
> + paddr_to_pfn(addr & PAGE_MASK),
> + DIV_ROUND_UP(size, PAGE_SIZE),
> + paddr_to_pfn(addr & PAGE_MASK));
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> + " - 0x%"PRIx64" in domain \n",
> + addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> + return res;
> + }
> +
> + return 0;
> +}
>
> #define NR_NEW_XEN_TABLES 2
>
> @@ -346,6 +388,14 @@ static int map_xsdt_table(struct domain *d, u64 *xsdt)
> ( ( (size - sizeof(struct acpi_table_header) ) /
> sizeof(acpi_native_uint) ) );
>
> + /* map xen env table */
> + res = map_xenv_table(d, &addr);
> + if(res)
> + return res;
> +
> + table_entry--;
> + *table_entry = addr ;
> +
> /* map stao table */
> map_stao_table(d, &addr);
> if(res)
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 32/35] arm : acpi map xen environment table to dom0
2015-02-05 17:36 ` Stefano Stabellini
@ 2015-02-06 0:57 ` Julien Grall
0 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-06 0:57 UTC (permalink / raw)
To: Stefano Stabellini, Parth Dixit
Cc: ian.campbell, tim, xen-devel, stefano.stabellini, jbeulich,
christoffer.dall
Hi Stefano,
On 06/02/2015 01:36, Stefano Stabellini wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
>> From: Parth Dixit <parth.dixit@linaro.org>
>>
>> xen environment table contains the grant table address,size and event
>> channel interrupt information required by dom0.
>>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>> xen/arch/arm/arm64/acpi/arm-core.c | 52 +++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 51 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/arm64/acpi/arm-core.c b/xen/arch/arm/arm64/acpi/arm-core.c
>> index 9fd02f9..9e9285c 100644
>> --- a/xen/arch/arm/arm64/acpi/arm-core.c
>> +++ b/xen/arch/arm/arm64/acpi/arm-core.c
>> @@ -33,7 +33,6 @@
>> #include <asm/cputype.h>
>> #include <asm/acpi.h>
>> #include <asm/p2m.h>
>> -
>> /*
>> * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>> * variable is still required by the ACPI core
>
> Spurious change
>
>
>> @@ -297,6 +296,49 @@ static int map_stao_table(struct domain *d, u64 *mstao)
>> return 0;
>> }
>>
>> +static int map_xenv_table(struct domain *d, u64 *mxenv)
>> +{
>> + u64 addr;
>> + u64 size;
>> + int res;
>> + u8 checksum;
>> + struct acpi_table_xenv *xenv=NULL;
>> +
>> + xenv = ACPI_ALLOCATE_ZEROED( sizeof(struct acpi_table_xenv) );
>> + if( xenv == NULL )
>> + return -ENOMEM;
>> +
>> + ACPI_MEMCPY(xenv->header.signature, ACPI_SIG_XENV, 4);
>> + xenv->header.length = sizeof(struct acpi_table_header)+12;
>> + xenv->header.checksum = 0;
>> + ACPI_MEMCPY(xenv->header.oem_id, "XenVMM", 6);
>> + ACPI_MEMCPY(xenv->header.oem_table_id, "RTSMVEV8", 8);
>> + xenv->header.revision = 1;
>> + ACPI_MEMCPY(xenv->header.asl_compiler_id, "INTL", 4);
>> + xenv->header.asl_compiler_revision = 0x20140828;
>> + xenv->gnt_start = 0x00000010000000;
>> + xenv->gnt_size = 0x20000;
>> + xenv->evt_intr = 31;
>> + xenv->evt_intr_flag =3;
>> + size = sizeof(struct acpi_table_xenv);
>
> As per all the other checksum calculation, I wonder whether we need a
> memory barrier here.
I don't see why the memory barrier is necessary, the checksum and the
modification of the table is done on the same processor.
But cleaning/invalidate the cache after the checksum may be required.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 33/35] arm : acpi enable efi for acpi
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (31 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 32/35] arm : acpi map xen environment " parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 5:31 ` Julien Grall
2015-02-11 9:51 ` Usage of efi_enabled - Was: " Julien Grall
2015-02-04 14:02 ` [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies parth.dixit
` (2 subsequent siblings)
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, julien.grall, tim, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
From: Parth Dixit <parth.dixit@linaro.org>
efi should be enabled to fetch the root pointer from uefi
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/common/efi/runtime.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index c840e08..c8b8642 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
#ifndef COMPAT
#ifdef CONFIG_ARM /* Disabled until runtime services implemented */
+
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+const bool_t efi_enabled = 1;
+#else
const bool_t efi_enabled = 0;
+#endif
+
#else
# include <asm/i387.h>
# include <asm/xstate.h>
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi
2015-02-04 14:02 ` [PATCH RFC 33/35] arm : acpi enable efi for acpi parth.dixit
@ 2015-02-05 5:31 ` Julien Grall
2015-02-05 10:32 ` Parth Dixit
2015-02-05 11:58 ` Jan Beulich
2015-02-11 9:51 ` Usage of efi_enabled - Was: " Julien Grall
1 sibling, 2 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-05 5:31 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: christoffer.dall, tim, stefano.stabellini, ian.campbell, jbeulich
Hi Parth,
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> efi should be enabled to fetch the root pointer from uefi
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/common/efi/runtime.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
> index c840e08..c8b8642 100644
> --- a/xen/common/efi/runtime.c
> +++ b/xen/common/efi/runtime.c
> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
> #ifndef COMPAT
>
> #ifdef CONFIG_ARM /* Disabled until runtime services implemented */
This comment seems irrelevant now.
> +
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
#ifdef CONFIG_ACPI
> +const bool_t efi_enabled = 1;
> +#else
> const bool_t efi_enabled = 0;
> +#endif
> +
> #else
> # include <asm/i387.h>
> # include <asm/xstate.h>
>
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi
2015-02-05 5:31 ` Julien Grall
@ 2015-02-05 10:32 ` Parth Dixit
2015-02-05 11:58 ` Jan Beulich
1 sibling, 0 replies; 166+ messages in thread
From: Parth Dixit @ 2015-02-05 10:32 UTC (permalink / raw)
To: Julien Grall
Cc: Ian Campbell, tim, xen-devel, Stefano Stabellini, Jan Beulich,
Christoffer Dall
On 5 February 2015 at 11:01, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Parth,
>
> On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
>>
>> From: Parth Dixit <parth.dixit@linaro.org>
>>
>> efi should be enabled to fetch the root pointer from uefi
>>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>> xen/common/efi/runtime.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
>> index c840e08..c8b8642 100644
>> --- a/xen/common/efi/runtime.c
>> +++ b/xen/common/efi/runtime.c
>> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
>> #ifndef COMPAT
>>
>> #ifdef CONFIG_ARM /* Disabled until runtime services implemented */
>
>
> This comment seems irrelevant now.
i will move it further down.
>> +
>> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>
>
> #ifdef CONFIG_ACPI
>
>> +const bool_t efi_enabled = 1;
>> +#else
>> const bool_t efi_enabled = 0;
>> +#endif
>> +
>> #else
>> # include <asm/i387.h>
>> # include <asm/xstate.h>
>>
>
> Regards,
>
> --
> Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi
2015-02-05 5:31 ` Julien Grall
2015-02-05 10:32 ` Parth Dixit
@ 2015-02-05 11:58 ` Jan Beulich
2015-02-05 12:05 ` Ian Campbell
1 sibling, 1 reply; 166+ messages in thread
From: Jan Beulich @ 2015-02-05 11:58 UTC (permalink / raw)
To: Julien Grall, parth.dixit, xen-devel
Cc: tim, stefano.stabellini, ian.campbell, christoffer.dall
>>> On 05.02.15 at 06:31, <julien.grall@linaro.org> wrote:
>> --- a/xen/common/efi/runtime.c
>> +++ b/xen/common/efi/runtime.c
>> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
>> #ifndef COMPAT
>>
>> #ifdef CONFIG_ARM /* Disabled until runtime services implemented */
>
> This comment seems irrelevant now.
>
>> +
>> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>
> #ifdef CONFIG_ACPI
This is common code, and I can't see ACPI and EFI being always in the
same supported state (or else we could drop one of the two).
Jan
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi
2015-02-05 11:58 ` Jan Beulich
@ 2015-02-05 12:05 ` Ian Campbell
2015-02-11 9:57 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Ian Campbell @ 2015-02-05 12:05 UTC (permalink / raw)
To: Jan Beulich
Cc: Julien Grall, tim, xen-devel, stefano.stabellini, parth.dixit,
christoffer.dall
On Thu, 2015-02-05 at 11:58 +0000, Jan Beulich wrote:
> >>> On 05.02.15 at 06:31, <julien.grall@linaro.org> wrote:
> >> --- a/xen/common/efi/runtime.c
> >> +++ b/xen/common/efi/runtime.c
> >> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
> >> #ifndef COMPAT
> >>
> >> #ifdef CONFIG_ARM /* Disabled until runtime services implemented */
> >
> > This comment seems irrelevant now.
> >
> >> +
> >> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> >
> > #ifdef CONFIG_ACPI
>
> This is common code, and I can't see ACPI and EFI being always in the
> same supported state (or else we could drop one of the two).
EFI without ACPI is certainly a possibility on ARM64.
Ian.
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi
2015-02-05 12:05 ` Ian Campbell
@ 2015-02-11 9:57 ` Julien Grall
2015-02-11 10:31 ` Jan Beulich
0 siblings, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-11 9:57 UTC (permalink / raw)
To: Ian Campbell, Jan Beulich
Cc: stefano.stabellini, tim, parth.dixit, christoffer.dall, xen-devel
Hi Ian,
On 05/02/2015 20:05, Ian Campbell wrote:
> On Thu, 2015-02-05 at 11:58 +0000, Jan Beulich wrote:
>>>>> On 05.02.15 at 06:31, <julien.grall@linaro.org> wrote:
>>>> --- a/xen/common/efi/runtime.c
>>>> +++ b/xen/common/efi/runtime.c
>>>> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
>>>> #ifndef COMPAT
>>>>
>>>> #ifdef CONFIG_ARM /* Disabled until runtime services implemented */
>>>
>>> This comment seems irrelevant now.
>>>
>>>> +
>>>> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>>>
>>> #ifdef CONFIG_ACPI
>>
>> This is common code, and I can't see ACPI and EFI being always in the
>> same supported state (or else we could drop one of the two).
>
> EFI without ACPI is certainly a possibility on ARM64.
We would need to defined a new protocol in order to boot ACPI without EFI.
Currently the ACPI fetch the rsdp pointer in 2 differents way depending
of efi_enabled:
* efi_enabled == 1 => Use EFI to get the pointer
* efi_enabled == 0 => Use the x86 legacy mode
On ARM64, we have to use the first one. Maybe we should refactor
acpi_os_get_root_pointer?
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi
2015-02-11 9:57 ` Julien Grall
@ 2015-02-11 10:31 ` Jan Beulich
2015-02-11 14:34 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Jan Beulich @ 2015-02-11 10:31 UTC (permalink / raw)
To: Ian Campbell, Julien Grall
Cc: parth.dixit, tim, stefano.stabellini, christoffer.dall, xen-devel
>>> On 11.02.15 at 10:57, <julien.grall@linaro.org> wrote:
> Hi Ian,
>
> On 05/02/2015 20:05, Ian Campbell wrote:
>> On Thu, 2015-02-05 at 11:58 +0000, Jan Beulich wrote:
>>>>>> On 05.02.15 at 06:31, <julien.grall@linaro.org> wrote:
>>>>> --- a/xen/common/efi/runtime.c
>>>>> +++ b/xen/common/efi/runtime.c
>>>>> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
>>>>> #ifndef COMPAT
>>>>>
>>>>> #ifdef CONFIG_ARM /* Disabled until runtime services implemented */
>>>>
>>>> This comment seems irrelevant now.
>>>>
>>>>> +
>>>>> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>>>>
>>>> #ifdef CONFIG_ACPI
>>>
>>> This is common code, and I can't see ACPI and EFI being always in the
>>> same supported state (or else we could drop one of the two).
>>
>> EFI without ACPI is certainly a possibility on ARM64.
>
> We would need to defined a new protocol in order to boot ACPI without EFI.
>
> Currently the ACPI fetch the rsdp pointer in 2 differents way depending
> of efi_enabled:
> * efi_enabled == 1 => Use EFI to get the pointer
> * efi_enabled == 0 => Use the x86 legacy mode
>
> On ARM64, we have to use the first one.
How that when not booting from EFI? Surely you can't use x86
legacy mode, but if there is the possibility of ACPI without EFI
(the opposite of what Ian indicated would be a possibility), then
there ought to be another method to find RSDP on ARM too.
> Maybe we should refactor acpi_os_get_root_pointer?
If need be...
Jan
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi
2015-02-11 10:31 ` Jan Beulich
@ 2015-02-11 14:34 ` Julien Grall
0 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-11 14:34 UTC (permalink / raw)
To: Jan Beulich, Ian Campbell
Cc: parth.dixit, tim, stefano.stabellini, christoffer.dall, xen-devel
Hi Jan,
On 11/02/2015 18:31, Jan Beulich wrote:
>>>> On 11.02.15 at 10:57, <julien.grall@linaro.org> wrote:
>> Hi Ian,
>>
>> On 05/02/2015 20:05, Ian Campbell wrote:
>>> On Thu, 2015-02-05 at 11:58 +0000, Jan Beulich wrote:
>>>>>>> On 05.02.15 at 06:31, <julien.grall@linaro.org> wrote:
>>>>>> --- a/xen/common/efi/runtime.c
>>>>>> +++ b/xen/common/efi/runtime.c
>>>>>> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
>>>>>> #ifndef COMPAT
>>>>>>
>>>>>> #ifdef CONFIG_ARM /* Disabled until runtime services implemented */
>>>>>
>>>>> This comment seems irrelevant now.
>>>>>
>>>>>> +
>>>>>> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>>>>>
>>>>> #ifdef CONFIG_ACPI
>>>>
>>>> This is common code, and I can't see ACPI and EFI being always in the
>>>> same supported state (or else we could drop one of the two).
>>>
>>> EFI without ACPI is certainly a possibility on ARM64.
>>
>> We would need to defined a new protocol in order to boot ACPI without EFI.
>>
>> Currently the ACPI fetch the rsdp pointer in 2 differents way depending
>> of efi_enabled:
>> * efi_enabled == 1 => Use EFI to get the pointer
>> * efi_enabled == 0 => Use the x86 legacy mode
>>
>> On ARM64, we have to use the first one.
>
> How that when not booting from EFI? Surely you can't use x86
> legacy mode, but if there is the possibility of ACPI without EFI
> (the opposite of what Ian indicated would be a possibility), then
> there ought to be another method to find RSDP on ARM too.
I should have been more clear on my previous mail. I didn't try to
justify this patch (I think it's wrong too), but I wanted to expose our
current use-case for ACPI.
We would, obviously, have to implement it when a new way to get ACPI is
coming up. Currently, ACPI can only be retrieved via EFI on ARM64.
So if efi_enabled is not set, we should bail out rather than trying to
use the legacy mode. It would help to support correctly ARM64 platform
with only DT support (and not EFI).
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Usage of efi_enabled - Was: Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi
2015-02-04 14:02 ` [PATCH RFC 33/35] arm : acpi enable efi for acpi parth.dixit
2015-02-05 5:31 ` Julien Grall
@ 2015-02-11 9:51 ` Julien Grall
2015-02-11 10:28 ` Jan Beulich
1 sibling, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-11 9:51 UTC (permalink / raw)
To: Parth Dixit, xen-devel@lists.xen.org
Cc: ian.campbell, tim, Roy Franz, stefano.stabellini, jbeulich,
christoffer.dall
(Adding Roy)
Hi Jan and Roy,
On 04/02/2015 22:02, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> efi should be enabled to fetch the root pointer from uefi
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/common/efi/runtime.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
> index c840e08..c8b8642 100644
> --- a/xen/common/efi/runtime.c
> +++ b/xen/common/efi/runtime.c
> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
> #ifndef COMPAT
>
> #ifdef CONFIG_ARM /* Disabled until runtime services implemented */
> +
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> +const bool_t efi_enabled = 1;
> +#else
> const bool_t efi_enabled = 0;
> +#endif
> +
Thinking a bit more about this variable. The usage of the variable is
unclear. Does it mean that Xen is supporting EFI runtime or Xen has been
boot with EFI?
The binary produced on ARM64 always is able to boot with and without
EFI. So it would seems logical to me that the value of this variable may
change at runtime.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Usage of efi_enabled - Was: Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi
2015-02-11 9:51 ` Usage of efi_enabled - Was: " Julien Grall
@ 2015-02-11 10:28 ` Jan Beulich
2015-02-11 10:49 ` Ian Campbell
0 siblings, 1 reply; 166+ messages in thread
From: Jan Beulich @ 2015-02-11 10:28 UTC (permalink / raw)
To: Julien Grall, Parth Dixit
Cc: ian.campbell, tim, xen-devel@lists.xen.org, Roy Franz,
stefano.stabellini, christoffer.dall
>>> On 11.02.15 at 10:51, <julien.grall@linaro.org> wrote:
>> --- a/xen/common/efi/runtime.c
>> +++ b/xen/common/efi/runtime.c
>> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
>> #ifndef COMPAT
>>
>> #ifdef CONFIG_ARM /* Disabled until runtime services implemented */
>> +
>> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>> +const bool_t efi_enabled = 1;
>> +#else
>> const bool_t efi_enabled = 0;
>> +#endif
>> +
>
> Thinking a bit more about this variable. The usage of the variable is
> unclear. Does it mean that Xen is supporting EFI runtime or Xen has been
> boot with EFI?
The latter (it just so happens that it also means the former on x86
for the time being).
> The binary produced on ARM64 always is able to boot with and without
> EFI. So it would seems logical to me that the value of this variable may
> change at runtime.
Correct - other than (currently) on x86.
Jan
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: Usage of efi_enabled - Was: Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi
2015-02-11 10:28 ` Jan Beulich
@ 2015-02-11 10:49 ` Ian Campbell
2015-02-11 11:22 ` Jan Beulich
0 siblings, 1 reply; 166+ messages in thread
From: Ian Campbell @ 2015-02-11 10:49 UTC (permalink / raw)
To: Jan Beulich
Cc: Julien Grall, tim, xen-devel@lists.xen.org, Roy Franz,
stefano.stabellini, Parth Dixit, christoffer.dall
On Wed, 2015-02-11 at 10:28 +0000, Jan Beulich wrote:
> >>> On 11.02.15 at 10:51, <julien.grall@linaro.org> wrote:
> >> --- a/xen/common/efi/runtime.c
> >> +++ b/xen/common/efi/runtime.c
> >> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
> >> #ifndef COMPAT
> >>
> >> #ifdef CONFIG_ARM /* Disabled until runtime services implemented */
> >> +
> >> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> >> +const bool_t efi_enabled = 1;
> >> +#else
> >> const bool_t efi_enabled = 0;
> >> +#endif
> >> +
> >
> > Thinking a bit more about this variable. The usage of the variable is
> > unclear. Does it mean that Xen is supporting EFI runtime or Xen has been
> > boot with EFI?
>
> The latter (it just so happens that it also means the former on x86
> for the time being).
>
> > The binary produced on ARM64 always is able to boot with and without
> > EFI. So it would seems logical to me that the value of this variable may
> > change at runtime.
>
> Correct - other than (currently) on x86.
IOW it should become non-const on !x86?
Does that also imply that some code which is using it to signal
availability of Runtime Services should be switch to some other (new?)
variable?
Ian
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: Usage of efi_enabled - Was: Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi
2015-02-11 10:49 ` Ian Campbell
@ 2015-02-11 11:22 ` Jan Beulich
2015-02-12 4:18 ` Ian Campbell
0 siblings, 1 reply; 166+ messages in thread
From: Jan Beulich @ 2015-02-11 11:22 UTC (permalink / raw)
To: Ian Campbell
Cc: Julien Grall, tim, xen-devel@lists.xen.org, Roy Franz,
stefano.stabellini, Parth Dixit, christoffer.dall
>>> On 11.02.15 at 11:49, <ian.campbell@citrix.com> wrote:
> On Wed, 2015-02-11 at 10:28 +0000, Jan Beulich wrote:
>> >>> On 11.02.15 at 10:51, <julien.grall@linaro.org> wrote:
>> >> --- a/xen/common/efi/runtime.c
>> >> +++ b/xen/common/efi/runtime.c
>> >> @@ -11,7 +11,13 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16);
>> >> #ifndef COMPAT
>> >>
>> >> #ifdef CONFIG_ARM /* Disabled until runtime services implemented */
>> >> +
>> >> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>> >> +const bool_t efi_enabled = 1;
>> >> +#else
>> >> const bool_t efi_enabled = 0;
>> >> +#endif
>> >> +
>> >
>> > Thinking a bit more about this variable. The usage of the variable is
>> > unclear. Does it mean that Xen is supporting EFI runtime or Xen has been
>> > boot with EFI?
>>
>> The latter (it just so happens that it also means the former on x86
>> for the time being).
>>
>> > The binary produced on ARM64 always is able to boot with and without
>> > EFI. So it would seems logical to me that the value of this variable may
>> > change at runtime.
>>
>> Correct - other than (currently) on x86.
>
> IOW it should become non-const on !x86?
Yes. With Daniel's work it'll become non-const on x86 too at some
point.
> Does that also imply that some code which is using it to signal
> availability of Runtime Services should be switch to some other (new?)
> variable?
I hope not - we already have efi_rs_enable, and I would hope all
uses of runtime services are gated upon that. Of course turning
off efi_enabled may need to imply also clearing efi_rs_enable.
Jan
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: Usage of efi_enabled - Was: Re: [PATCH RFC 33/35] arm : acpi enable efi for acpi
2015-02-11 11:22 ` Jan Beulich
@ 2015-02-12 4:18 ` Ian Campbell
0 siblings, 0 replies; 166+ messages in thread
From: Ian Campbell @ 2015-02-12 4:18 UTC (permalink / raw)
To: Jan Beulich
Cc: Julien Grall, tim, xen-devel@lists.xen.org, Roy Franz,
stefano.stabellini, Parth Dixit, christoffer.dall
On Wed, 2015-02-11 at 11:22 +0000, Jan Beulich wrote:
> > Does that also imply that some code which is using it to signal
> > availability of Runtime Services should be switch to some other (new?)
> > variable?
>
> I hope not - we already have efi_rs_enable,
Good, I was just mislead by the nearby comment then (which sort of
implied that efi_enable == 0 due to no RTS support).
Ian.
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (32 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 33/35] arm : acpi enable efi for acpi parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-05 5:38 ` Julien Grall
2015-02-05 17:48 ` Stefano Stabellini
2015-02-04 14:02 ` [PATCH RFC 35/35] xen: arm64: Add ACPI support parth.dixit
2015-02-04 16:38 ` [PATCH RFC 00/35] Add ACPI support for arm64 on Xen Julien Grall
35 siblings, 2 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, julien.grall, tim, stefano.stabellini, jbeulich,
Parth Dixit, christoffer.dall
From: Parth Dixit <parth.dixit@linaro.org>
Some bugs are identified in edk2 and some of the functionality is not
yet merged. This patch contains workarounds for them
Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
---
xen/arch/arm/domain_build.c | 82 ++++++++++++++++++++++++++++++++++++++++++++-
xen/arch/arm/vgic.c | 16 +++++++++
xen/drivers/acpi/osl.c | 7 ++--
3 files changed, 102 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a504064..a425ef4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1234,7 +1234,87 @@ static int make_chosen_node(const struct domain *d, const struct kernel_info *ki
return res;
}
+#define ACPI_UEFI_MEM_STUB
+
+#ifdef ACPI_UEFI_MEM_STUB
+enum{
+ IO_NET0,
+ IO_SREG,
+ IO_VIRT,
+ IO_SCT0,
+ IO_AAC0,
+ IO_MMC0,
+ IO_KMI0,
+ IO_KMI1,
+ IO_SER1,
+ IO_SER2,
+ IO_SER3,
+ IO_WDT0,
+ IO_TIM0,
+ IO_TIM2,
+ IO_RTC0,
+ IO_TIM3,
+ IO_TIM4,
+ IO_MAX
+};
+#define INIT_IO( dev,addr,size ) [dev] = {addr,size}
+
+static const u64 acpi_mmio_region[][IO_MAX]=
+ {
+ INIT_IO(IO_NET0,0x1a000000,(PAGE_SIZE*16) ),
+ INIT_IO(IO_SREG,0x1c010000,PAGE_SIZE),
+ INIT_IO(IO_VIRT,0x1c130000,PAGE_SIZE),
+ INIT_IO(IO_SCT0,0x1c020000,PAGE_SIZE),
+ INIT_IO(IO_AAC0,0x1c040000,PAGE_SIZE),
+ INIT_IO(IO_MMC0,0x1c050000,PAGE_SIZE),
+ INIT_IO(IO_KMI0,0x1c060000,PAGE_SIZE),
+ INIT_IO(IO_KMI1,0x1c070000,PAGE_SIZE),
+ INIT_IO(IO_SER1,0x1c0a0000,PAGE_SIZE),
+ INIT_IO(IO_SER2,0x1c0b0000,PAGE_SIZE),
+ INIT_IO(IO_SER3,0x1c0c0000,PAGE_SIZE),
+ INIT_IO(IO_WDT0,0x1c0f0000,PAGE_SIZE),
+ INIT_IO(IO_TIM0,0x1c110000,PAGE_SIZE),
+ INIT_IO(IO_TIM2,0x1c120000,PAGE_SIZE),
+ INIT_IO(IO_RTC0,0x1c170000,PAGE_SIZE),
+ INIT_IO(IO_TIM3,0x2a810000,(PAGE_SIZE*16) ),
+ INIT_IO(IO_TIM4,0x2a830000,(PAGE_SIZE*16) ),
+ };
+
+int acpi_map_mmio(struct domain *d)
+{
+ int i,res;
+ u64 addr,size;
+
+ for (i = 0; i < IO_MAX; i++)
+ {
+ addr = acpi_mmio_region[i][0];
+ size = acpi_mmio_region[i][1];
+ res = iomem_permit_access(d, paddr_to_pfn(addr & PAGE_MASK),
+ paddr_to_pfn(PAGE_ALIGN(addr + size - 1)));
+ res = map_mmio_regions(d,
+ paddr_to_pfn(addr & PAGE_MASK),
+ DIV_ROUND_UP(size, PAGE_SIZE),
+ paddr_to_pfn(addr & PAGE_MASK));
+
+
+ }
+#if 0
+ for( i=32 ; i < 255 ; i++ )
+ {
+ res = vgic_reserve_virq(d, i);
+ res = route_irq_to_guest(d, i, NULL);
+ if ( res )
+ {
+ printk(XENLOG_ERR "Unable to route IRQ %u to domain %u\n",
+ i, d->domain_id);
+ }
+
+ }
+#endif
+ return 0;
+}
+#else
static int acpi_map_mmio(struct domain *d)
{
int i,res;
@@ -1273,7 +1353,7 @@ static int acpi_map_mmio(struct domain *d)
return 0;
}
-
+#endif
static int map_acpi_regions(struct domain *d)
{
int res;
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 97061ce..e74555d 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -254,6 +254,8 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
}
}
+#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
+
void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
{
struct domain *d = v->domain;
@@ -266,6 +268,20 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
irq = i + (32 * n);
+#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
+ if( ( n!=0 ) && is_hardware_domain(d) ){
+ struct vgic_irq_rank *vr = vgic_get_rank(v, n);
+ uint32_t tr;
+ tr = vr->icfg[i >> 4] ;
+
+ if( ( tr & VGIC_ICFG_MASK(i) ) )
+ acpi_set_irq(irq, DT_IRQ_TYPE_EDGE_BOTH);
+ else
+ acpi_set_irq(irq, DT_IRQ_TYPE_LEVEL_MASK);
+
+ route_irq_to_guest(d,irq,NULL);
+ }
+#endif
v_target = d->arch.vgic.handler->get_target_vcpu(v, irq);
p = irq_to_pending(v_target, irq);
set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index 73da9d9..2d78ba0 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list args)
acpi_physical_address __init acpi_os_get_root_pointer(void)
{
- if (efi_enabled) {
+ if (efi_enabled) {
if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
return efi.acpi20;
else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
@@ -198,8 +198,11 @@ acpi_os_write_memory(acpi_physical_address phys_addr, u32 value, u32 width)
return AE_OK;
}
-
+#ifdef CONFIG_X86
#define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
+#else
+#define is_xmalloc_memory(ptr) 1
+#endif
void *__init acpi_os_alloc_memory(size_t sz)
{
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies
2015-02-04 14:02 ` [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies parth.dixit
@ 2015-02-05 5:38 ` Julien Grall
2015-02-05 10:30 ` Parth Dixit
2015-02-05 17:48 ` Stefano Stabellini
1 sibling, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-05 5:38 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: christoffer.dall, tim, stefano.stabellini, ian.campbell, jbeulich
Hi Parth,
On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> Some bugs are identified in edk2 and some of the functionality is not
> yet merged. This patch contains workarounds for them
While I understand some workaround (based on your cover letter), some of
them is unclear to me and need explanation.
>
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
[..]
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 97061ce..e74555d 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -254,6 +254,8 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
> }
> }
>
> +#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
> +
> void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
> {
> struct domain *d = v->domain;
> @@ -266,6 +268,20 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>
> while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
> irq = i + (32 * n);
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> + if( ( n!=0 ) && is_hardware_domain(d) ){
> + struct vgic_irq_rank *vr = vgic_get_rank(v, n);
> + uint32_t tr;
> + tr = vr->icfg[i >> 4] ;
> +
> + if( ( tr & VGIC_ICFG_MASK(i) ) )
> + acpi_set_irq(irq, DT_IRQ_TYPE_EDGE_BOTH);
> + else
> + acpi_set_irq(irq, DT_IRQ_TYPE_LEVEL_MASK);
What's the status of the dynamic IRQ configuration?
> +
> + route_irq_to_guest(d,irq,NULL);
Hmmm, do you really plan to keep that here? What's your plan for this?
> + }
> +#endif
> v_target = d->arch.vgic.handler->get_target_vcpu(v, irq);
> p = irq_to_pending(v_target, irq);
> set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
> index 73da9d9..2d78ba0 100644
> --- a/xen/drivers/acpi/osl.c
> +++ b/xen/drivers/acpi/osl.c
> @@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list args)
>
> acpi_physical_address __init acpi_os_get_root_pointer(void)
> {
> - if (efi_enabled) {
> + if (efi_enabled) {
Spurious change
> if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
> return efi.acpi20;
> else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
> @@ -198,8 +198,11 @@ acpi_os_write_memory(acpi_physical_address phys_addr, u32 value, u32 width)
>
> return AE_OK;
> }
> -
> +#ifdef CONFIG_X86
> #define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
> +#else
> +#define is_xmalloc_memory(ptr) 1
> +#endif
Why? I though this was resolved?
> void *__init acpi_os_alloc_memory(size_t sz)
> {
>
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies
2015-02-05 5:38 ` Julien Grall
@ 2015-02-05 10:30 ` Parth Dixit
2015-02-05 14:59 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Parth Dixit @ 2015-02-05 10:30 UTC (permalink / raw)
To: Julien Grall
Cc: Ian Campbell, tim, xen-devel, Stefano Stabellini, Jan Beulich,
Christoffer Dall
On 5 February 2015 at 11:08, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Parth,
>
> On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
>>
>> From: Parth Dixit <parth.dixit@linaro.org>
>>
>> Some bugs are identified in edk2 and some of the functionality is not
>> yet merged. This patch contains workarounds for them
>
>
> While I understand some workaround (based on your cover letter), some of
> them is unclear to me and need explanation.
Sure, ask them, i'll reply to it.
>>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>
>
> [..]
>
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index 97061ce..e74555d 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -254,6 +254,8 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int
>> n)
>> }
>> }
>>
>> +#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
>> +
>> void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>> {
>> struct domain *d = v->domain;
>> @@ -266,6 +268,20 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int
>> n)
>>
>> while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
>> irq = i + (32 * n);
>> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>> + if( ( n!=0 ) && is_hardware_domain(d) ){
>> + struct vgic_irq_rank *vr = vgic_get_rank(v, n);
>> + uint32_t tr;
>> + tr = vr->icfg[i >> 4] ;
>> +
>> + if( ( tr & VGIC_ICFG_MASK(i) ) )
>> + acpi_set_irq(irq, DT_IRQ_TYPE_EDGE_BOTH);
>> + else
>> + acpi_set_irq(irq, DT_IRQ_TYPE_LEVEL_MASK);
>
>
> What's the status of the dynamic IRQ configuration?
It would be on top of your patches but this is the place where i am
planning to trap it.
I have not rebased it on top of your patches, so that needs to be done.
>> +
>> + route_irq_to_guest(d,irq,NULL);
>
>
> Hmmm, do you really plan to keep that here? What's your plan for this?
yes, but i am open to suggestions , if you think there is a better
place i'll move it there.
>> + }
>> +#endif
>> v_target = d->arch.vgic.handler->get_target_vcpu(v, irq);
>> p = irq_to_pending(v_target, irq);
>> set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
>> index 73da9d9..2d78ba0 100644
>> --- a/xen/drivers/acpi/osl.c
>> +++ b/xen/drivers/acpi/osl.c
>> @@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list
>> args)
>>
>> acpi_physical_address __init acpi_os_get_root_pointer(void)
>> {
>> - if (efi_enabled) {
>> + if (efi_enabled) {
>
>
> Spurious change
will take care in next patchset
>> if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
>> return efi.acpi20;
>> else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
>> @@ -198,8 +198,11 @@ acpi_os_write_memory(acpi_physical_address phys_addr,
>> u32 value, u32 width)
>>
>> return AE_OK;
>> }
>> -
>> +#ifdef CONFIG_X86
>> #define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
>> +#else
>> +#define is_xmalloc_memory(ptr) 1
>> +#endif
>
>
> Why? I though this was resolved?
i am not aware what was the resolution on it?
>> void *__init acpi_os_alloc_memory(size_t sz)
>> {
>>
>
> Regards,
>
> --
> Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies
2015-02-05 10:30 ` Parth Dixit
@ 2015-02-05 14:59 ` Julien Grall
2015-02-10 9:38 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-05 14:59 UTC (permalink / raw)
To: Parth Dixit
Cc: Ian Campbell, tim, xen-devel, Stefano Stabellini, Jan Beulich,
Christoffer Dall
Hi Parth,
On 05/02/2015 18:30, Parth Dixit wrote:
> On 5 February 2015 at 11:08, Julien Grall <julien.grall@linaro.org> wrote:
>> Hi Parth,
>>
>> On 04/02/2015 14:02, parth.dixit@linaro.org wrote:
>>>
>>> From: Parth Dixit <parth.dixit@linaro.org>
>>>
>>> Some bugs are identified in edk2 and some of the functionality is not
>>> yet merged. This patch contains workarounds for them
>>
>>
>> While I understand some workaround (based on your cover letter), some of
>> them is unclear to me and need explanation.
> Sure, ask them, i'll reply to it.
I asked them on the previous mail. It seems you answered all of them,
thanks :)
>>>
>>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>>> ---
>>
>>
>> [..]
>>
>>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>>> index 97061ce..e74555d 100644
>>> --- a/xen/arch/arm/vgic.c
>>> +++ b/xen/arch/arm/vgic.c
>>> @@ -254,6 +254,8 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int
>>> n)
>>> }
>>> }
>>>
>>> +#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
>>> +
>>> void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>>> {
>>> struct domain *d = v->domain;
>>> @@ -266,6 +268,20 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int
>>> n)
>>>
>>> while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
>>> irq = i + (32 * n);
>>> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>>> + if( ( n!=0 ) && is_hardware_domain(d) ){
>>> + struct vgic_irq_rank *vr = vgic_get_rank(v, n);
>>> + uint32_t tr;
>>> + tr = vr->icfg[i >> 4] ;
>>> +
>>> + if( ( tr & VGIC_ICFG_MASK(i) ) )
>>> + acpi_set_irq(irq, DT_IRQ_TYPE_EDGE_BOTH);
>>> + else
>>> + acpi_set_irq(irq, DT_IRQ_TYPE_LEVEL_MASK);
>>
>>
>> What's the status of the dynamic IRQ configuration?
> It would be on top of your patches but this is the place where i am
> planning to trap it.
> I have not rebased it on top of your patches, so that needs to be done.
Ok.
>>> +
>>> + route_irq_to_guest(d,irq,NULL);
>>
>>
>> Hmmm, do you really plan to keep that here? What's your plan for this?
> yes, but i am open to suggestions , if you think there is a better
> place i'll move it there.
Ok, when we discussed about it in december that wasn't the plan.
While I'm okay for the IRQ configuration (setting level/edge), the
routing should not be done here.
First at all, route_irq_to_guest could fail and enable doesn't handle
this use.
Then, DOM0 (aka the hardware domain) may not be able to use all the
interrupts (think about pass-through).
So, for IRQ routing there is 2 possibles solutions:
1) Route all the SPIs to the guest in Xen
2) Let DOM0 Linux requesting to route the IRQ via a PHYSDEV_op
IIRC, we deciced to choose the first solution for now. Even though none
of the solutions are perfect.
>>> + }
>>> +#endif
>>> v_target = d->arch.vgic.handler->get_target_vcpu(v, irq);
>>> p = irq_to_pending(v_target, irq);
>>> set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>>> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
>>> index 73da9d9..2d78ba0 100644
>>> --- a/xen/drivers/acpi/osl.c
>>> +++ b/xen/drivers/acpi/osl.c
>>> @@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list
>>> args)
>>>
>>> acpi_physical_address __init acpi_os_get_root_pointer(void)
>>> {
>>> - if (efi_enabled) {
>>> + if (efi_enabled) {
>>
>>
>> Spurious change
> will take care in next patchset
>>> if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
>>> return efi.acpi20;
>>> else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
>>> @@ -198,8 +198,11 @@ acpi_os_write_memory(acpi_physical_address phys_addr,
>>> u32 value, u32 width)
>>>
>>> return AE_OK;
>>> }
>>> -
>>> +#ifdef CONFIG_X86
>>> #define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
>>> +#else
>>> +#define is_xmalloc_memory(ptr) 1
>>> +#endif
>>
>>
>> Why? I though this was resolved?
> i am not aware what was the resolution on it?
I didn't have access on my IRC log in the plane. So I wasn't able to
find the discussion.
AFAIR, this issue was because we are allocating a chunk bigger than
PAGE_SIZE in acpi_tb_resize_root_table_list.
x86 manage to never allocate a chunk bigger than PAGE_SIZE. So I'm not
sure why ARM64 requires too. This would need more debug.
This macro is used to know if the memory has been allocated by the boot
allocator of the memory pool.
So 2 solutions:
1) We find a better way to use detect it
2) We avoid to allocate big chunk
I'm not sure which one is the easiest/better one.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies
2015-02-05 14:59 ` Julien Grall
@ 2015-02-10 9:38 ` Julien Grall
2015-02-10 10:01 ` Jan Beulich
0 siblings, 1 reply; 166+ messages in thread
From: Julien Grall @ 2015-02-10 9:38 UTC (permalink / raw)
To: Parth Dixit
Cc: Ian Campbell, tim, xen-devel, Stefano Stabellini, Jan Beulich,
Christoffer Dall
Hi Parth,
On 05/02/2015 22:59, Julien Grall wrote:
>>>> +#ifdef CONFIG_X86
>>>> #define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE
>>>> - 1))
>>>> +#else
>>>> +#define is_xmalloc_memory(ptr) 1
>>>> +#endif
>>>
>>>
>>> Why? I though this was resolved?
>> i am not aware what was the resolution on it?
>
> I didn't have access on my IRC log in the plane. So I wasn't able to
> find the discussion.
>
> AFAIR, this issue was because we are allocating a chunk bigger than
> PAGE_SIZE in acpi_tb_resize_root_table_list.
>
> x86 manage to never allocate a chunk bigger than PAGE_SIZE. So I'm not
> sure why ARM64 requires too. This would need more debug.
>
> This macro is used to know if the memory has been allocated by the boot
> allocator of the memory pool.
>
> So 2 solutions:
> 1) We find a better way to use detect it
> 2) We avoid to allocate big chunk
>
> I'm not sure which one is the easiest/better one.
So, I took time to understand better the issue. This is happening at the
first call of acpi_tb_resize_root_table_list (see stack trace at the end
of the mail).
We are trying to allocate ACPI_MAX_TABLES * sizeof (struct acpi_table_desc).
The size of the structure is 32 bytes which give a total allocation of
4096 bytes on both x86 and ARM64.
Why it's working on x86? This big allocation is done via the boot
allocator memory (because the system state is early boot). Hopefully, we
never have to resize it.
On ARM64, ACPI is initialized after the boot allocator has ended, so we
have to use xmalloc which will return a page-align pointer.
As ACPI on ARM64 will never use the boot allocator, maybe the
xmalloc_is_ptr is acceptable? It would require a big explanation which
it's safe.
What do you think?
[<0000000000284bfc>] acpi_os_zalloc_memory+0x5c/0x8c (PC)
[<0000000000284be8>] acpi_os_zalloc_memory+0x48/0x8c (LR)
[<000000000028571c>] acpi_tb_resize_root_table_list+0x94/0x124
[<00000000002857d0>] acpi_allocate_root_table+0x24/0x2c
[<0000000000285800>] acpi_initialize_tables+0x28/0x98
[<000000000028663c>] acpi_table_init+0x1c/0x88
[<000000000028bcbc>] acpi_boot_table_init+0x1c/0x48
[<0000000000289d08>] start_xen+0x574/0xcbc
[<0000000000200610>] paging+0x88/0xc0
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies
2015-02-10 9:38 ` Julien Grall
@ 2015-02-10 10:01 ` Jan Beulich
2015-02-10 10:26 ` Julien Grall
0 siblings, 1 reply; 166+ messages in thread
From: Jan Beulich @ 2015-02-10 10:01 UTC (permalink / raw)
To: Julien Grall, Parth Dixit
Cc: tim, Stefano Stabellini, Ian Campbell, Christoffer Dall,
xen-devel
>>> On 10.02.15 at 10:38, <julien.grall@linaro.org> wrote:
> Why it's working on x86? This big allocation is done via the boot
> allocator memory (because the system state is early boot). Hopefully, we
> never have to resize it.
>
> On ARM64, ACPI is initialized after the boot allocator has ended, so we
> have to use xmalloc which will return a page-align pointer.
>
> As ACPI on ARM64 will never use the boot allocator,
How come you're so certain? The reason why on x86 it needs to
be done this way is because of NUMA initialization. Are you not
expecting NUMA to become of interest to ARM? Or if you do, are
you sure you can get away without the same ordering that x86
uses?
> maybe the
> xmalloc_is_ptr is acceptable? It would require a big explanation which
> it's safe.
Indeed, it _might_ be acceptable, but certainly not without a proper
comment.
Jan
^ permalink raw reply [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies
2015-02-10 10:01 ` Jan Beulich
@ 2015-02-10 10:26 ` Julien Grall
0 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-10 10:26 UTC (permalink / raw)
To: Jan Beulich, Parth Dixit
Cc: tim, Stefano Stabellini, Ian Campbell, Christoffer Dall,
xen-devel
Hi Jan,
On 10/02/2015 18:01, Jan Beulich wrote:
>>>> On 10.02.15 at 10:38, <julien.grall@linaro.org> wrote:
>> Why it's working on x86? This big allocation is done via the boot
>> allocator memory (because the system state is early boot). Hopefully, we
>> never have to resize it.
>>
>> On ARM64, ACPI is initialized after the boot allocator has ended, so we
>> have to use xmalloc which will return a page-align pointer.
>>
>> As ACPI on ARM64 will never use the boot allocator,
>
> How come you're so certain? The reason why on x86 it needs to
> be done this way is because of NUMA initialization. Are you not
> expecting NUMA to become of interest to ARM? Or if you do, are
> you sure you can get away without the same ordering that x86
> uses?
I haven't though about it, sorry. Indeed, sooner or later NUMA
will be interesting for ARM. So yes, the ACPI initialization has
to be done before the boot_end_allocator.
I gave a try and it works for me (see patch below).
Parth, can you include this patch and drop the change about
is_xmalloc_memory?
Regards,
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 6651e78..6c7b3bf 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -600,8 +600,6 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
allocator. */
init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start),
pfn_to_paddr(boot_mfn_start));
-
- end_boot_allocator();
}
#else /* CONFIG_ARM_64 */
static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
@@ -670,8 +668,6 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
setup_frametable_mappings(ram_start, ram_end);
max_page = PFN_DOWN(ram_end);
-
- end_boot_allocator();
}
#endif
@@ -741,6 +737,12 @@ void __init start_xen(unsigned long boot_phys_offset,
setup_mm(fdt_paddr, fdt_size);
+#ifdef CONFIG_ACPI
+ acpi_boot_table_init();
+#endif
+
+ end_boot_allocator();
+
system_state = SYS_STATE_boot;
vm_init();
@@ -750,7 +752,6 @@ void __init start_xen(unsigned long boot_phys_offset,
*/
#if defined(CONFIG_ACPI) && defined(CONFIG_ARM_64)
- acpi_boot_table_init();
/* Get the boot CPU's MPIDR before cpu logical map is built */
cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
--
Julien Grall
^ permalink raw reply related [flat|nested] 166+ messages in thread
* Re: [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies
2015-02-04 14:02 ` [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies parth.dixit
2015-02-05 5:38 ` Julien Grall
@ 2015-02-05 17:48 ` Stefano Stabellini
2015-02-05 19:30 ` Parth Dixit
1 sibling, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-05 17:48 UTC (permalink / raw)
To: Parth Dixit
Cc: ian.campbell, julien.grall, tim, xen-devel, stefano.stabellini,
jbeulich, christoffer.dall
On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
>
> Some bugs are identified in edk2 and some of the functionality is not
> yet merged. This patch contains workarounds for them
A patch with a few workarounds left is OK, but you should explain
exactly what they are and why you weren't able to solve the relative
issues properly.
> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> ---
> xen/arch/arm/domain_build.c | 82 ++++++++++++++++++++++++++++++++++++++++++++-
> xen/arch/arm/vgic.c | 16 +++++++++
> xen/drivers/acpi/osl.c | 7 ++--
> 3 files changed, 102 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index a504064..a425ef4 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1234,7 +1234,87 @@ static int make_chosen_node(const struct domain *d, const struct kernel_info *ki
>
> return res;
> }
> +#define ACPI_UEFI_MEM_STUB
> +
> +#ifdef ACPI_UEFI_MEM_STUB
> +enum{
> + IO_NET0,
> + IO_SREG,
> + IO_VIRT,
> + IO_SCT0,
> + IO_AAC0,
> + IO_MMC0,
> + IO_KMI0,
> + IO_KMI1,
> + IO_SER1,
> + IO_SER2,
> + IO_SER3,
> + IO_WDT0,
> + IO_TIM0,
> + IO_TIM2,
> + IO_RTC0,
> + IO_TIM3,
> + IO_TIM4,
> + IO_MAX
> +};
> +#define INIT_IO( dev,addr,size ) [dev] = {addr,size}
> +
> +static const u64 acpi_mmio_region[][IO_MAX]=
> + {
> + INIT_IO(IO_NET0,0x1a000000,(PAGE_SIZE*16) ),
> + INIT_IO(IO_SREG,0x1c010000,PAGE_SIZE),
> + INIT_IO(IO_VIRT,0x1c130000,PAGE_SIZE),
> + INIT_IO(IO_SCT0,0x1c020000,PAGE_SIZE),
> + INIT_IO(IO_AAC0,0x1c040000,PAGE_SIZE),
> + INIT_IO(IO_MMC0,0x1c050000,PAGE_SIZE),
> + INIT_IO(IO_KMI0,0x1c060000,PAGE_SIZE),
> + INIT_IO(IO_KMI1,0x1c070000,PAGE_SIZE),
> + INIT_IO(IO_SER1,0x1c0a0000,PAGE_SIZE),
> + INIT_IO(IO_SER2,0x1c0b0000,PAGE_SIZE),
> + INIT_IO(IO_SER3,0x1c0c0000,PAGE_SIZE),
> + INIT_IO(IO_WDT0,0x1c0f0000,PAGE_SIZE),
> + INIT_IO(IO_TIM0,0x1c110000,PAGE_SIZE),
> + INIT_IO(IO_TIM2,0x1c120000,PAGE_SIZE),
> + INIT_IO(IO_RTC0,0x1c170000,PAGE_SIZE),
> + INIT_IO(IO_TIM3,0x2a810000,(PAGE_SIZE*16) ),
> + INIT_IO(IO_TIM4,0x2a830000,(PAGE_SIZE*16) ),
> + };
What is this?
> +int acpi_map_mmio(struct domain *d)
> +{
> + int i,res;
> + u64 addr,size;
> +
> + for (i = 0; i < IO_MAX; i++)
> + {
> + addr = acpi_mmio_region[i][0];
> + size = acpi_mmio_region[i][1];
>
> + res = iomem_permit_access(d, paddr_to_pfn(addr & PAGE_MASK),
> + paddr_to_pfn(PAGE_ALIGN(addr + size - 1)));
> + res = map_mmio_regions(d,
> + paddr_to_pfn(addr & PAGE_MASK),
> + DIV_ROUND_UP(size, PAGE_SIZE),
> + paddr_to_pfn(addr & PAGE_MASK));
> +
> +
> + }
> +#if 0
> + for( i=32 ; i < 255 ; i++ )
> + {
> + res = vgic_reserve_virq(d, i);
> + res = route_irq_to_guest(d, i, NULL);
> + if ( res )
> + {
> + printk(XENLOG_ERR "Unable to route IRQ %u to domain %u\n",
> + i, d->domain_id);
> + }
> +
> + }
> +#endif
> + return 0;
> +}
> +#else
> static int acpi_map_mmio(struct domain *d)
> {
> int i,res;
> @@ -1273,7 +1353,7 @@ static int acpi_map_mmio(struct domain *d)
>
> return 0;
> }
> -
> +#endif
This is pretty terrible. You are ifdef'ing out the entire function that
you introduced earlier.
> static int map_acpi_regions(struct domain *d)
> {
> int res;
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 97061ce..e74555d 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -254,6 +254,8 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
> }
> }
>
> +#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
> +
> void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
> {
> struct domain *d = v->domain;
> @@ -266,6 +268,20 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>
> while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
> irq = i + (32 * n);
> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> + if( ( n!=0 ) && is_hardware_domain(d) ){
> + struct vgic_irq_rank *vr = vgic_get_rank(v, n);
> + uint32_t tr;
> + tr = vr->icfg[i >> 4] ;
> +
> + if( ( tr & VGIC_ICFG_MASK(i) ) )
> + acpi_set_irq(irq, DT_IRQ_TYPE_EDGE_BOTH);
> + else
> + acpi_set_irq(irq, DT_IRQ_TYPE_LEVEL_MASK);
> +
> + route_irq_to_guest(d,irq,NULL);
> + }
> +#endif
Is this the code that currently assigns all the irqs to dom0?
> v_target = d->arch.vgic.handler->get_target_vcpu(v, irq);
> p = irq_to_pending(v_target, irq);
> set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
> index 73da9d9..2d78ba0 100644
> --- a/xen/drivers/acpi/osl.c
> +++ b/xen/drivers/acpi/osl.c
> @@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list args)
>
> acpi_physical_address __init acpi_os_get_root_pointer(void)
> {
> - if (efi_enabled) {
> + if (efi_enabled) {
> if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
> return efi.acpi20;
> else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
> @@ -198,8 +198,11 @@ acpi_os_write_memory(acpi_physical_address phys_addr, u32 value, u32 width)
>
> return AE_OK;
> }
> -
> +#ifdef CONFIG_X86
> #define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
> +#else
> +#define is_xmalloc_memory(ptr) 1
> +#endif
Why?
> void *__init acpi_os_alloc_memory(size_t sz)
> {
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies
2015-02-05 17:48 ` Stefano Stabellini
@ 2015-02-05 19:30 ` Parth Dixit
2015-02-06 14:38 ` Stefano Stabellini
0 siblings, 1 reply; 166+ messages in thread
From: Parth Dixit @ 2015-02-05 19:30 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Ian Campbell, Julien Grall, tim, xen-devel, Stefano Stabellini,
Jan Beulich, Christoffer Dall
On 5 February 2015 at 23:18, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
>> From: Parth Dixit <parth.dixit@linaro.org>
>>
>> Some bugs are identified in edk2 and some of the functionality is not
>> yet merged. This patch contains workarounds for them
>
> A patch with a few workarounds left is OK, but you should explain
> exactly what they are and why you weren't able to solve the relative
> issues properly.
>
>
>> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
>> ---
>> xen/arch/arm/domain_build.c | 82 ++++++++++++++++++++++++++++++++++++++++++++-
>> xen/arch/arm/vgic.c | 16 +++++++++
>> xen/drivers/acpi/osl.c | 7 ++--
>> 3 files changed, 102 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index a504064..a425ef4 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1234,7 +1234,87 @@ static int make_chosen_node(const struct domain *d, const struct kernel_info *ki
>>
>> return res;
>> }
>> +#define ACPI_UEFI_MEM_STUB
>> +
>> +#ifdef ACPI_UEFI_MEM_STUB
>> +enum{
>> + IO_NET0,
>> + IO_SREG,
>> + IO_VIRT,
>> + IO_SCT0,
>> + IO_AAC0,
>> + IO_MMC0,
>> + IO_KMI0,
>> + IO_KMI1,
>> + IO_SER1,
>> + IO_SER2,
>> + IO_SER3,
>> + IO_WDT0,
>> + IO_TIM0,
>> + IO_TIM2,
>> + IO_RTC0,
>> + IO_TIM3,
>> + IO_TIM4,
>> + IO_MAX
>> +};
>> +#define INIT_IO( dev,addr,size ) [dev] = {addr,size}
>> +
>> +static const u64 acpi_mmio_region[][IO_MAX]=
>> + {
>> + INIT_IO(IO_NET0,0x1a000000,(PAGE_SIZE*16) ),
>> + INIT_IO(IO_SREG,0x1c010000,PAGE_SIZE),
>> + INIT_IO(IO_VIRT,0x1c130000,PAGE_SIZE),
>> + INIT_IO(IO_SCT0,0x1c020000,PAGE_SIZE),
>> + INIT_IO(IO_AAC0,0x1c040000,PAGE_SIZE),
>> + INIT_IO(IO_MMC0,0x1c050000,PAGE_SIZE),
>> + INIT_IO(IO_KMI0,0x1c060000,PAGE_SIZE),
>> + INIT_IO(IO_KMI1,0x1c070000,PAGE_SIZE),
>> + INIT_IO(IO_SER1,0x1c0a0000,PAGE_SIZE),
>> + INIT_IO(IO_SER2,0x1c0b0000,PAGE_SIZE),
>> + INIT_IO(IO_SER3,0x1c0c0000,PAGE_SIZE),
>> + INIT_IO(IO_WDT0,0x1c0f0000,PAGE_SIZE),
>> + INIT_IO(IO_TIM0,0x1c110000,PAGE_SIZE),
>> + INIT_IO(IO_TIM2,0x1c120000,PAGE_SIZE),
>> + INIT_IO(IO_RTC0,0x1c170000,PAGE_SIZE),
>> + INIT_IO(IO_TIM3,0x2a810000,(PAGE_SIZE*16) ),
>> + INIT_IO(IO_TIM4,0x2a830000,(PAGE_SIZE*16) ),
>> + };
>
> What is this?
This is the mmio map of fvp model as these regions are not described
in uefi firmware right now,
bug is already filed for it.
>
>> +int acpi_map_mmio(struct domain *d)
>> +{
>> + int i,res;
>> + u64 addr,size;
>> +
>> + for (i = 0; i < IO_MAX; i++)
>> + {
>> + addr = acpi_mmio_region[i][0];
>> + size = acpi_mmio_region[i][1];
>>
>> + res = iomem_permit_access(d, paddr_to_pfn(addr & PAGE_MASK),
>> + paddr_to_pfn(PAGE_ALIGN(addr + size - 1)));
>> + res = map_mmio_regions(d,
>> + paddr_to_pfn(addr & PAGE_MASK),
>> + DIV_ROUND_UP(size, PAGE_SIZE),
>> + paddr_to_pfn(addr & PAGE_MASK));
>> +
>> +
>> + }
>> +#if 0
>> + for( i=32 ; i < 255 ; i++ )
>> + {
>> + res = vgic_reserve_virq(d, i);
>> + res = route_irq_to_guest(d, i, NULL);
>> + if ( res )
>> + {
>> + printk(XENLOG_ERR "Unable to route IRQ %u to domain %u\n",
>> + i, d->domain_id);
>> + }
>> +
>> + }
>> +#endif
>> + return 0;
>> +}
>> +#else
>> static int acpi_map_mmio(struct domain *d)
>> {
>> int i,res;
>> @@ -1273,7 +1353,7 @@ static int acpi_map_mmio(struct domain *d)
>>
>> return 0;
>> }
>> -
>> +#endif
>
> This is pretty terrible. You are ifdef'ing out the entire function that
> you introduced earlier.
i will refactor it to make it more clear, its essentially same
function but is reading mmio regions locally instead of uefi tables.
>
>> static int map_acpi_regions(struct domain *d)
>> {
>> int res;
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index 97061ce..e74555d 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -254,6 +254,8 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
>> }
>> }
>>
>> +#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
>> +
>> void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>> {
>> struct domain *d = v->domain;
>> @@ -266,6 +268,20 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>>
>> while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
>> irq = i + (32 * n);
>> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
>> + if( ( n!=0 ) && is_hardware_domain(d) ){
>> + struct vgic_irq_rank *vr = vgic_get_rank(v, n);
>> + uint32_t tr;
>> + tr = vr->icfg[i >> 4] ;
>> +
>> + if( ( tr & VGIC_ICFG_MASK(i) ) )
>> + acpi_set_irq(irq, DT_IRQ_TYPE_EDGE_BOTH);
>> + else
>> + acpi_set_irq(irq, DT_IRQ_TYPE_LEVEL_MASK);
>> +
>> + route_irq_to_guest(d,irq,NULL);
>> + }
>> +#endif
>
> Is this the code that currently assigns all the irqs to dom0?
yes
>
>> v_target = d->arch.vgic.handler->get_target_vcpu(v, irq);
>> p = irq_to_pending(v_target, irq);
>> set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
>> index 73da9d9..2d78ba0 100644
>> --- a/xen/drivers/acpi/osl.c
>> +++ b/xen/drivers/acpi/osl.c
>> @@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list args)
>>
>> acpi_physical_address __init acpi_os_get_root_pointer(void)
>> {
>> - if (efi_enabled) {
>> + if (efi_enabled) {
>> if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
>> return efi.acpi20;
>> else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
>> @@ -198,8 +198,11 @@ acpi_os_write_memory(acpi_physical_address phys_addr, u32 value, u32 width)
>>
>> return AE_OK;
>> }
>> -
>> +#ifdef CONFIG_X86
>> #define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
>> +#else
>> +#define is_xmalloc_memory(ptr) 1
>> +#endif
>
> Why?
this test is failing,leading to crash.
>
>> void *__init acpi_os_alloc_memory(size_t sz)
>> {
>> --
>> 1.9.1
>>
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies
2015-02-05 19:30 ` Parth Dixit
@ 2015-02-06 14:38 ` Stefano Stabellini
2015-02-06 14:49 ` Jan Beulich
0 siblings, 1 reply; 166+ messages in thread
From: Stefano Stabellini @ 2015-02-06 14:38 UTC (permalink / raw)
To: Parth Dixit
Cc: Ian Campbell, Stefano Stabellini, Julien Grall, tim, xen-devel,
Stefano Stabellini, Jan Beulich, Christoffer Dall
On Fri, 6 Feb 2015, Parth Dixit wrote:
> On 5 February 2015 at 23:18, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
> >> From: Parth Dixit <parth.dixit@linaro.org>
> >>
> >> Some bugs are identified in edk2 and some of the functionality is not
> >> yet merged. This patch contains workarounds for them
> >
> > A patch with a few workarounds left is OK, but you should explain
> > exactly what they are and why you weren't able to solve the relative
> > issues properly.
> >
> >
> >> Signed-off-by: Parth Dixit <parth.dixit@linaro.org>
> >> ---
> >> xen/arch/arm/domain_build.c | 82 ++++++++++++++++++++++++++++++++++++++++++++-
> >> xen/arch/arm/vgic.c | 16 +++++++++
> >> xen/drivers/acpi/osl.c | 7 ++--
> >> 3 files changed, 102 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> >> index a504064..a425ef4 100644
> >> --- a/xen/arch/arm/domain_build.c
> >> +++ b/xen/arch/arm/domain_build.c
> >> @@ -1234,7 +1234,87 @@ static int make_chosen_node(const struct domain *d, const struct kernel_info *ki
> >>
> >> return res;
> >> }
> >> +#define ACPI_UEFI_MEM_STUB
> >> +
> >> +#ifdef ACPI_UEFI_MEM_STUB
> >> +enum{
> >> + IO_NET0,
> >> + IO_SREG,
> >> + IO_VIRT,
> >> + IO_SCT0,
> >> + IO_AAC0,
> >> + IO_MMC0,
> >> + IO_KMI0,
> >> + IO_KMI1,
> >> + IO_SER1,
> >> + IO_SER2,
> >> + IO_SER3,
> >> + IO_WDT0,
> >> + IO_TIM0,
> >> + IO_TIM2,
> >> + IO_RTC0,
> >> + IO_TIM3,
> >> + IO_TIM4,
> >> + IO_MAX
> >> +};
> >> +#define INIT_IO( dev,addr,size ) [dev] = {addr,size}
> >> +
> >> +static const u64 acpi_mmio_region[][IO_MAX]=
> >> + {
> >> + INIT_IO(IO_NET0,0x1a000000,(PAGE_SIZE*16) ),
> >> + INIT_IO(IO_SREG,0x1c010000,PAGE_SIZE),
> >> + INIT_IO(IO_VIRT,0x1c130000,PAGE_SIZE),
> >> + INIT_IO(IO_SCT0,0x1c020000,PAGE_SIZE),
> >> + INIT_IO(IO_AAC0,0x1c040000,PAGE_SIZE),
> >> + INIT_IO(IO_MMC0,0x1c050000,PAGE_SIZE),
> >> + INIT_IO(IO_KMI0,0x1c060000,PAGE_SIZE),
> >> + INIT_IO(IO_KMI1,0x1c070000,PAGE_SIZE),
> >> + INIT_IO(IO_SER1,0x1c0a0000,PAGE_SIZE),
> >> + INIT_IO(IO_SER2,0x1c0b0000,PAGE_SIZE),
> >> + INIT_IO(IO_SER3,0x1c0c0000,PAGE_SIZE),
> >> + INIT_IO(IO_WDT0,0x1c0f0000,PAGE_SIZE),
> >> + INIT_IO(IO_TIM0,0x1c110000,PAGE_SIZE),
> >> + INIT_IO(IO_TIM2,0x1c120000,PAGE_SIZE),
> >> + INIT_IO(IO_RTC0,0x1c170000,PAGE_SIZE),
> >> + INIT_IO(IO_TIM3,0x2a810000,(PAGE_SIZE*16) ),
> >> + INIT_IO(IO_TIM4,0x2a830000,(PAGE_SIZE*16) ),
> >> + };
> >
> > What is this?
> This is the mmio map of fvp model as these regions are not described
> in uefi firmware right now,
> bug is already filed for it.
OK
> >> +int acpi_map_mmio(struct domain *d)
> >> +{
> >> + int i,res;
> >> + u64 addr,size;
> >> +
> >> + for (i = 0; i < IO_MAX; i++)
> >> + {
> >> + addr = acpi_mmio_region[i][0];
> >> + size = acpi_mmio_region[i][1];
> >>
> >> + res = iomem_permit_access(d, paddr_to_pfn(addr & PAGE_MASK),
> >> + paddr_to_pfn(PAGE_ALIGN(addr + size - 1)));
> >> + res = map_mmio_regions(d,
> >> + paddr_to_pfn(addr & PAGE_MASK),
> >> + DIV_ROUND_UP(size, PAGE_SIZE),
> >> + paddr_to_pfn(addr & PAGE_MASK));
> >> +
> >> +
> >> + }
> >> +#if 0
> >> + for( i=32 ; i < 255 ; i++ )
> >> + {
> >> + res = vgic_reserve_virq(d, i);
> >> + res = route_irq_to_guest(d, i, NULL);
> >> + if ( res )
> >> + {
> >> + printk(XENLOG_ERR "Unable to route IRQ %u to domain %u\n",
> >> + i, d->domain_id);
> >> + }
> >> +
> >> + }
> >> +#endif
> >> + return 0;
> >> +}
> >> +#else
> >> static int acpi_map_mmio(struct domain *d)
> >> {
> >> int i,res;
> >> @@ -1273,7 +1353,7 @@ static int acpi_map_mmio(struct domain *d)
> >>
> >> return 0;
> >> }
> >> -
> >> +#endif
> >
> > This is pretty terrible. You are ifdef'ing out the entire function that
> > you introduced earlier.
> i will refactor it to make it more clear, its essentially same
> function but is reading mmio regions locally instead of uefi tables.
thanks
> >> static int map_acpi_regions(struct domain *d)
> >> {
> >> int res;
> >> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> >> index 97061ce..e74555d 100644
> >> --- a/xen/arch/arm/vgic.c
> >> +++ b/xen/arch/arm/vgic.c
> >> @@ -254,6 +254,8 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
> >> }
> >> }
> >>
> >> +#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
> >> +
> >> void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
> >> {
> >> struct domain *d = v->domain;
> >> @@ -266,6 +268,20 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
> >>
> >> while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
> >> irq = i + (32 * n);
> >> +#if defined(CONFIG_ARM_64) && defined(CONFIG_ACPI)
> >> + if( ( n!=0 ) && is_hardware_domain(d) ){
> >> + struct vgic_irq_rank *vr = vgic_get_rank(v, n);
> >> + uint32_t tr;
> >> + tr = vr->icfg[i >> 4] ;
> >> +
> >> + if( ( tr & VGIC_ICFG_MASK(i) ) )
> >> + acpi_set_irq(irq, DT_IRQ_TYPE_EDGE_BOTH);
> >> + else
> >> + acpi_set_irq(irq, DT_IRQ_TYPE_LEVEL_MASK);
> >> +
> >> + route_irq_to_guest(d,irq,NULL);
> >> + }
> >> +#endif
> >
> > Is this the code that currently assigns all the irqs to dom0?
> yes
It is not terrible, but it might be best if you just add a call there to
a new function, you can call it acpi_enable_dom0_irq.
> >
> >> v_target = d->arch.vgic.handler->get_target_vcpu(v, irq);
> >> p = irq_to_pending(v_target, irq);
> >> set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
> >> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
> >> index 73da9d9..2d78ba0 100644
> >> --- a/xen/drivers/acpi/osl.c
> >> +++ b/xen/drivers/acpi/osl.c
> >> @@ -66,7 +66,7 @@ void __init acpi_os_vprintf(const char *fmt, va_list args)
> >>
> >> acpi_physical_address __init acpi_os_get_root_pointer(void)
> >> {
> >> - if (efi_enabled) {
> >> + if (efi_enabled) {
> >> if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
> >> return efi.acpi20;
> >> else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
> >> @@ -198,8 +198,11 @@ acpi_os_write_memory(acpi_physical_address phys_addr, u32 value, u32 width)
> >>
> >> return AE_OK;
> >> }
> >> -
> >> +#ifdef CONFIG_X86
> >> #define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
> >> +#else
> >> +#define is_xmalloc_memory(ptr) 1
> >> +#endif
> >
> > Why?
> this test is failing,leading to crash.
Actually I don't understand this check even on x86.
Jan, why are we assuming that xmalloc cannot return align pointers on
x86?
^ permalink raw reply [flat|nested] 166+ messages in thread* Re: [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies
2015-02-06 14:38 ` Stefano Stabellini
@ 2015-02-06 14:49 ` Jan Beulich
0 siblings, 0 replies; 166+ messages in thread
From: Jan Beulich @ 2015-02-06 14:49 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Ian Campbell, JulienGrall, tim, xen-devel, parth.dixit,
Christoffer Dall
>>> On 06.02.15 at 15:38, <stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 6 Feb 2015, Parth Dixit wrote:
>> On 5 February 2015 at 23:18, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> wrote:
>> > On Wed, 4 Feb 2015, parth.dixit@linaro.org wrote:
>> >> +#ifdef CONFIG_X86
>> >> #define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
>> >> +#else
>> >> +#define is_xmalloc_memory(ptr) 1
>> >> +#endif
>> >
>> > Why?
>> this test is failing,leading to crash.
>
> Actually I don't understand this check even on x86.
>
> Jan, why are we assuming that xmalloc cannot return align pointers on
> x86?
Because all allocations coming through here are sub-page-size,
and such allocations are never providing page-aligned block of
memory. (I think it goes without saying that making this a
constant 1 on ARM is a no-go - if you have a need for larger
allocations, the macro still needs to distinguish both cases in
order to not break acpi_os_free_memory().)
Jan
^ permalink raw reply [flat|nested] 166+ messages in thread
* [PATCH RFC 35/35] xen: arm64: Add ACPI support
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (33 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies parth.dixit
@ 2015-02-04 14:02 ` parth.dixit
2015-02-04 16:38 ` [PATCH RFC 00/35] Add ACPI support for arm64 on Xen Julien Grall
35 siblings, 0 replies; 166+ messages in thread
From: parth.dixit @ 2015-02-04 14:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, Naresh Bhat, julien.grall, tim, stefano.stabellini,
jbeulich, christoffer.dall
From: Naresh Bhat <naresh.bhat@linaro.org>
Add ACPI support on arm64 xen hypervisor.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
config/arm64.mk | 1 +
xen/include/asm-arm/config.h | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/config/arm64.mk b/config/arm64.mk
index 6eafda2..91c1de4 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -8,6 +8,7 @@ CFLAGS += #-marm -march= -mcpu= etc
HAS_PL011 := y
HAS_NS16550 := y
+HAS_ACPI := y
# Use only if calling $(LD) directly.
LDFLAGS_DIRECT += -EL
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 264e2c1..184f5db 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -33,6 +33,11 @@
#define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */
+#if defined(CONFIG_ARM_64)
+#define CONFIG_ACPI 1
+#define CONFIG_ACPI_BOOT 1
+#endif
+
#define CONFIG_SMP 1
#define CONFIG_VIDEO 1
--
1.9.1
^ permalink raw reply related [flat|nested] 166+ messages in thread* Re: [PATCH RFC 00/35] Add ACPI support for arm64 on Xen
2015-02-04 14:01 [PATCH RFC 00/35] Add ACPI support for arm64 on Xen parth.dixit
` (34 preceding siblings ...)
2015-02-04 14:02 ` [PATCH RFC 35/35] xen: arm64: Add ACPI support parth.dixit
@ 2015-02-04 16:38 ` Julien Grall
35 siblings, 0 replies; 166+ messages in thread
From: Julien Grall @ 2015-02-04 16:38 UTC (permalink / raw)
To: parth.dixit, xen-devel
Cc: christoffer.dall, tim, stefano.stabellini, ian.campbell, jbeulich
Hi Parth,
On 04/02/2015 14:01, parth.dixit@linaro.org wrote:
> From: Parth Dixit <parth.dixit@linaro.org>
> This patch series adds ACPI support for arm64.
Thank you for sending the ACPI patch series. I will give a look at it
before the connect, so we could talk about it next week.
> Xen reads static tables described by ACPI standard (5.1) from uefi
> and configures timer, gic and uart. ACPI tables are modified to
> enable PSCI, HVC and xen specific information (grant table and
> event channel interrupts) and mapped into dom0 address space.
> A skeleton device tree is created to pass memory
> (which cannot be passed using ACPI) and rsdp pointer to DOM0.
> DOM0 parses dynamic ACPI tables and configure other peripherals.
>
> - patches 1-19 add ACPI support for xen/uefi interface
> - patches 20-35 add ACPI support for xen/dom0 interface
> Last patch "xen: arm64: Add ACPI support" enables the support for ACPI
> so that individual patches do not affect working xen code base.
>
> Instructions for reproducing the setup and working code base can be found
> in the following repositories
> wiki : https://wiki.linaro.org/LEG/Engineering/Xen_boot_on_FVP_ACPI_UEFI
> linux : https://git.linaro.org/people/parth.dixit/xen-acpi-support/leg-kernel.git
> xen : https://git.linaro.org/people/parth.dixit/xen-acpi-support/xen.git
> uefi : https://git.linaro.org/people/parth.dixit/xen-acpi-support/linaro-edk2.git
>
> Few workarounds have been made to get it working, these are as follows
> 1. Xen assumes that mmio regions are defined in firmware. It reads
> this information from uefi tables and map's it to dom0 address space.
FWIW, this is part of the UEFI spec. So it's safe to use it ;).
> Right now FVP firmware on which this series has been tested
> does not contains all the mmio regions defined in ACPI supplied by
> firmware, to overcome this hard coding of mmio regions is done.
What's the status of this bug? IIRC, a bug was filled last December.
> 2. Linux is checking if mapped pages belong to ram and when this check fails(incorrectly)
> it maps RAM using ioremap, to overcome this at present this check is
> disabled in linux.
Some people were working on dropping/reworking this check. What's the
status?
> 3. Device specific interrupt information is defined in DSDT tables in ACPI.
> Parsing this table is out of scope for xen so it uses dom0 to parse DSDT table
> and enables the interrupt dynamically when they are enabled by dom0.
It's a design choice, not a workaround ;).
> 4. Grant table region and event channel interrupts are hard coded right now.
>
> 5. RSDP ponter is exposed to dom0 by using "rsdp" node, this node is not yet defined
> in linux and its name may get changed to "linux,acpi-rsdp" or something else.
Ditto.
BTW, when do you plan to send the Linux series? Did they decided about
the boot protocol?
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 166+ messages in thread