Add ACPI support for arm64 on Xen

From: Shannon Zhao <[email protected]>

This reverts commit 810a50db69703f715d199d6b3a5f08193155d48b.

Signed-off-by Shannon Zhao <[email protected]>

Conflicts:

	xen/arch/arm/vgic-v2.c
---
 xen/arch/arm/vgic-v2.c       | 10 +++++-----
 xen/include/asm-arm/domain.h |  1 +
 2 files changed, 6 insertions(+), 5 deletions(-)

xen/arch/arm/vgic-v2.c +5 -5

index f7d784b..ba7ddac 100644
@@ -531,7 +531,7 @@ static int vgic_v2_vcpu_init(struct vcpu *v)
 static int vgic_v2_domain_init(struct domain *d)
 {
     int i, ret;
-    paddr_t cbase, csize;
+    paddr_t csize;
     paddr_t vbase;
 
     /*

@@ -541,6 +541,7 @@ static int vgic_v2_domain_init(struct domain *d)
     if ( is_hardware_domain(d) )
     {
         d->arch.vgic.dbase = vgic_v2_hw.dbase;
+        d->arch.vgic.cbase = vgic_v2_hw.cbase;
         /*
          * For the hardware domain, we always map the whole HW CPU
          * interface region in order to match the device tree (the "reg"

@@ -548,13 +549,13 @@ static int vgic_v2_domain_init(struct domain *d)
          * Note that we assume the size of the CPU interface is always
          * aligned to PAGE_SIZE.
          */
-        cbase = vgic_v2_hw.cbase;
         csize = vgic_v2_hw.csize;
         vbase = vgic_v2_hw.vbase;
     }
     else
     {
         d->arch.vgic.dbase = GUEST_GICD_BASE;
+        d->arch.vgic.cbase = GUEST_GICC_BASE;
         /*
          * The CPU interface exposed to the guest is always 8kB. We may
          * need to add an offset to the virtual CPU interface base

@@ -562,7 +563,6 @@ static int vgic_v2_domain_init(struct domain *d)
          * region.
          */
         BUILD_BUG_ON(GUEST_GICC_SIZE != SZ_8K);
-        cbase = GUEST_GICC_BASE;
         csize = GUEST_GICC_SIZE;
         vbase = vgic_v2_hw.vbase + vgic_v2_hw.aliased_offset;
     }

@@ -571,8 +571,8 @@ static int vgic_v2_domain_init(struct domain *d)
      * Map the gic virtual cpu interface in the gic cpu interface
      * region of the guest.
      */
-    ret = map_mmio_regions(d, paddr_to_pfn(cbase), csize / PAGE_SIZE,
-                           paddr_to_pfn(vbase));
+    ret = map_mmio_regions(d, paddr_to_pfn(d->arch.vgic.cbase),
+                           csize / PAGE_SIZE, paddr_to_pfn(vbase));
     if ( ret )
         return ret;
 

xen/include/asm-arm/domain.h +1 -0

index e7e40da..1e61f30 100644
@@ -102,6 +102,7 @@ struct arch_domain
         struct pending_irq *pending_irqs;
         /* Base address for guest GIC */
         paddr_t dbase; /* Distributor base address */
+        paddr_t cbase; /* CPU base address */
 #ifdef HAS_GICV3
         /* GIC V3 addressing */
         /* List of contiguous occupied by the redistributors */

Hi Shannon,

Why do you want to revert this patch?

Hi Julien,

Quoted 4 lines · Julien Grall

Hi Shannon,

Why do you want to revert this patch?

Because d->arch.vgic.cbase will be used by creating Dom0 MADT table later. See [PATCH v3 43/62].
+ gicc.base_address = d->arch.vgic.cbase;

My previous way is get this from ACPI table but someone suggest get it from struct domain and I think this way is better too since it uses the value after being parsed.

And sorry that I didn't notice this patch before when you send it out to list.

Quoted 11 lines · Shannon Zhao

Quoted 11 lines

Hi Julien,

Quoted 4 lines · Julien Grall

Quoted 4 lines

Hi Shannon,

Why do you want to revert this patch?

Because d->arch.vgic.cbase will be used by creating Dom0 MADT table later. See [PATCH v3 43/62].
+ gicc.base_address = d->arch.vgic.cbase;

Quoted 3 lines

Quoted 3 lines

My previous way is get this from ACPI table but someone suggest get it from struct domain and I think this way is better too since it uses the value after being parsed.

It's pointless to store the value in arch_domain for something that it's only use during building...

We have struct kernel_info which store any information related to the DOM0 during the building.

Quoted 12 lines · Julien Grall

Quoted 11 lines · Shannon Zhao

Quoted 11 lines

Hi Julien,

Quoted 4 lines · Julien Grall

Quoted 4 lines

Hi Shannon,

Why do you want to revert this patch?

Because d->arch.vgic.cbase will be used by creating Dom0 MADT table later. See [PATCH v3 43/62].
+ gicc.base_address = d->arch.vgic.cbase;

Quoted 9 lines

Quoted 3 lines

Quoted 3 lines

My previous way is get this from ACPI table but someone suggest get it from struct domain and I think this way is better too since it uses the value after being parsed.

It's pointless to store the value in arch_domain for something that it's only use during building...

We have struct kernel_info which store any information related to the DOM0 during the building.

Yeah, that would be better if it could use kernel_info. But the problem is that kernel_info is firstly used in construct_dom0(), while it needs to store the cbase in domain_create() which is called before construct_dom0(). And if we pass kernel_info as parameter to domain_create(), this would introduce more changes to common codes.

Do you have any better idea to handle this?

Hi Shannon,

Quoted 23 lines · Shannon Zhao

Quoted 12 lines · Julien Grall

Quoted 11 lines · Shannon Zhao

Quoted 11 lines

Hi Julien,

Quoted 4 lines · Julien Grall

Quoted 4 lines

Hi Shannon,

Why do you want to revert this patch?

Because d->arch.vgic.cbase will be used by creating Dom0 MADT table later. See [PATCH v3 43/62].
+ gicc.base_address = d->arch.vgic.cbase;

Quoted 9 lines

Quoted 3 lines

Quoted 3 lines

My previous way is get this from ACPI table but someone suggest get it from struct domain and I think this way is better too since it uses the value after being parsed.

It's pointless to store the value in arch_domain for something that it's only use during building...

We have struct kernel_info which store any information related to the DOM0 during the building.

Quoted 7 lines

Yeah, that would be better if it could use kernel_info. But the problem is that kernel_info is firstly used in construct_dom0(), while it needs to store the cbase in domain_create() which is called before construct_dom0(). And if we pass kernel_info as parameter to domain_create(), this would introduce more changes to common codes.

Do you have any better idea to handle this?

Yes, introducing callback to create the ACPI table in the GIC driver. See what we did for make_hwdom_dt_node.

We are trying to make the domain_build domain as agnostic as possible from the GIC version. However in patch #43, you implement specific version in the domain builder.

It will also not scale very well when we will introduce GICv2m and ITS.

The version of the GIC (ACPI_MADT_GIC_*) could be introduced in the vgic_ops.

The re-distributor could be moved in gic-v3.c and the generic interrupt controller in gic-v2.c.

Note it's a mandatory to emulate the same version as the hardware for the virtual GIC.

Quoted 3 lines

Note it's a mandatory to emulate the same version as the hardware for the virtual GIC.

So it doesn't support vGICv2 on GICv3 hardware for Xen?

Quoted 4 lines · Shannon Zhao

Quoted 3 lines

Note it's a mandatory to emulate the same version as the hardware for the virtual GIC.

So it doesn't support vGICv2 on GICv3 hardware for Xen?

Sorry I forgot to say it was for DOM0. We support GICv2 on GICv3 only for guest.

Quoted 4 lines · Shannon Zhao

Quoted 3 lines

Note it's a mandatory to emulate the same version as the hardware for the virtual GIC.

So it doesn't support vGICv2 on GICv3 hardware for Xen?

Sorry I forgot to say it was for DOM0. We support GICv2 on GICv3 only for guest.

Quoted 3 lines

Note it's a mandatory to emulate the same version as the hardware for the virtual GIC.

So it doesn't support vGICv2 on GICv3 hardware for Xen?

Hi Shannon,

Quoted 23 lines · Shannon Zhao

Quoted 12 lines · Julien Grall

Quoted 11 lines · Shannon Zhao

Quoted 11 lines

Hi Julien,

Quoted 4 lines · Julien Grall

Quoted 4 lines

Hi Shannon,

Why do you want to revert this patch?

Because d->arch.vgic.cbase will be used by creating Dom0 MADT table later. See [PATCH v3 43/62].
+ gicc.base_address = d->arch.vgic.cbase;

Quoted 9 lines

Quoted 3 lines

Quoted 3 lines

My previous way is get this from ACPI table but someone suggest get it from struct domain and I think this way is better too since it uses the value after being parsed.

It's pointless to store the value in arch_domain for something that it's only use during building...

We have struct kernel_info which store any information related to the DOM0 during the building.

Quoted 7 lines

Yeah, that would be better if it could use kernel_info. But the problem is that kernel_info is firstly used in construct_dom0(), while it needs to store the cbase in domain_create() which is called before construct_dom0(). And if we pass kernel_info as parameter to domain_create(), this would introduce more changes to common codes.

Do you have any better idea to handle this?

Yes, introducing callback to create the ACPI table in the GIC driver. See what we did for make_hwdom_dt_node.

We are trying to make the domain_build domain as agnostic as possible from the GIC version. However in patch #43, you implement specific version in the domain builder.

It will also not scale very well when we will introduce GICv2m and ITS.

The version of the GIC (ACPI_MADT_GIC_*) could be introduced in the vgic_ops.

The re-distributor could be moved in gic-v3.c and the generic interrupt controller in gic-v2.c.

Note it's a mandatory to emulate the same version as the hardware for the virtual GIC.

Quoted 12 lines · Julien Grall

Quoted 11 lines · Shannon Zhao

Quoted 11 lines

Hi Julien,

Quoted 4 lines · Julien Grall

Quoted 4 lines

Hi Shannon,

Why do you want to revert this patch?

Because d->arch.vgic.cbase will be used by creating Dom0 MADT table later. See [PATCH v3 43/62].
+ gicc.base_address = d->arch.vgic.cbase;

Quoted 9 lines

Quoted 3 lines

Quoted 3 lines

My previous way is get this from ACPI table but someone suggest get it from struct domain and I think this way is better too since it uses the value after being parsed.

It's pointless to store the value in arch_domain for something that it's only use during building...

We have struct kernel_info which store any information related to the DOM0 during the building.

Yeah, that would be better if it could use kernel_info. But the problem is that kernel_info is firstly used in construct_dom0(), while it needs to store the cbase in domain_create() which is called before construct_dom0(). And if we pass kernel_info as parameter to domain_create(), this would introduce more changes to common codes.

Do you have any better idea to handle this?

Quoted 11 lines · Shannon Zhao

Quoted 11 lines

Hi Julien,

Quoted 4 lines · Julien Grall

Quoted 4 lines

Hi Shannon,

Why do you want to revert this patch?

Because d->arch.vgic.cbase will be used by creating Dom0 MADT table later. See [PATCH v3 43/62].
+ gicc.base_address = d->arch.vgic.cbase;

Quoted 3 lines

Quoted 3 lines

My previous way is get this from ACPI table but someone suggest get it from struct domain and I think this way is better too since it uses the value after being parsed.

It's pointless to store the value in arch_domain for something that it's only use during building...

We have struct kernel_info which store any information related to the DOM0 during the building.

Hi Julien,

Quoted 4 lines · Julien Grall

Hi Shannon,

Why do you want to revert this patch?

Because d->arch.vgic.cbase will be used by creating Dom0 MADT table later. See [PATCH v3 43/62].
+ gicc.base_address = d->arch.vgic.cbase;

My previous way is get this from ACPI table but someone suggest get it from struct domain and I think this way is better too since it uses the value after being parsed.

And sorry that I didn't notice this patch before when you send it out to list.

Hi Shannon,

Why do you want to revert this patch?

xen/include/asm-arm/arm64/io.h static inline u64 __raw_readq(const volatile void __iomem *addr) · line 125

Quoted 13 lines · On Tuesday 17 November 2015 17:40:03 shannon.zhao at linaro.org wrote:

xen/include/asm-arm/arm64/io.h +13 -0

+/*
+ * Emulate x86 io ports for arm.
+ */
+#define __armio(addr) ( (void __iomem *)addr )
+
+#define inb(c) ( readb( __armio(c) ) )
+#define inw(c) ( readw( __armio(c) ) )
+#define inl(c) ( readl( __armio(c) ) )
+
+#define outb(v, c) ( writeb(v, __armio(c) ) )
+#define outw(v, c) ( writew(v, __armio(c) ) )
+#define outl(v, c) ( writel(v, __armio(c) ) )
+

This is almost certainly wrong. There might be I/O port accesses, but they won't be in the same place as normal pointers.

Hi Arnd,

Quoted 18 lines · Arnd Bergmann

xen/include/asm-arm/arm64/io.h static inline u64 __raw_readq(const volatile void __iomem *addr) · line 125

Quoted 13 lines · On Tuesday 17 November 2015 17:40:03 shannon.zhao at linaro.org wrote:

xen/include/asm-arm/arm64/io.h +13 -0

+/*
+ * Emulate x86 io ports for arm.
+ */
+#define __armio(addr) ( (void __iomem *)addr )
+
+#define inb(c) ( readb( __armio(c) ) )
+#define inw(c) ( readw( __armio(c) ) )
+#define inl(c) ( readl( __armio(c) ) )
+
+#define outb(v, c) ( writeb(v, __armio(c) ) )
+#define outw(v, c) ( writew(v, __armio(c) ) )
+#define outl(v, c) ( writel(v, __armio(c) ) )
+

This is almost certainly wrong. There might be I/O port accesses, but they won't be in the same place as normal pointers.

Sorry, maybe I didn't get what you mean. Here it just wants emulate the in(b,w,l) and out(b,w,l) which exist on x86 while not on ARM. So it could introduce less change to the common ACPI codes, for example acpi_os_write_port().

I see there is the same thing in Linux arch/arm/include/asm/io.h

Hi Arnd,

Quoted 18 lines · Arnd Bergmann

xen/include/asm-arm/arm64/io.h static inline u64 __raw_readq(const volatile void __iomem *addr) · line 125

Quoted 13 lines · On Tuesday 17 November 2015 17:40:03 [email protected] wrote:

xen/include/asm-arm/arm64/io.h +13 -0

+/*
+ * Emulate x86 io ports for arm.
+ */
+#define __armio(addr) ( (void __iomem *)addr )
+
+#define inb(c) ( readb( __armio(c) ) )
+#define inw(c) ( readw( __armio(c) ) )
+#define inl(c) ( readl( __armio(c) ) )
+
+#define outb(v, c) ( writeb(v, __armio(c) ) )
+#define outw(v, c) ( writew(v, __armio(c) ) )
+#define outl(v, c) ( writel(v, __armio(c) ) )
+

This is almost certainly wrong. There might be I/O port accesses, but they won't be in the same place as normal pointers.

Sorry, maybe I didn't get what you mean. Here it just wants emulate the in(b,w,l) and out(b,w,l) which exist on x86 while not on ARM. So it could introduce less change to the common ACPI codes, for example acpi_os_write_port().

I see there is the same thing in Linux arch/arm/include/asm/io.h

xen/include/asm-arm/arm64/io.h static inline u64 __raw_readq(const volatile void __iomem *addr) · line 125

Quoted 13 lines · On Tuesday 17 November 2015 17:40:03 [email protected] wrote:

xen/include/asm-arm/arm64/io.h +13 -0

+/*
+ * Emulate x86 io ports for arm.
+ */
+#define __armio(addr) ( (void __iomem *)addr )
+
+#define inb(c) ( readb( __armio(c) ) )
+#define inw(c) ( readw( __armio(c) ) )
+#define inl(c) ( readl( __armio(c) ) )
+
+#define outb(v, c) ( writeb(v, __armio(c) ) )
+#define outw(v, c) ( writew(v, __armio(c) ) )
+#define outl(v, c) ( writel(v, __armio(c) ) )
+

This is almost certainly wrong. There might be I/O port accesses, but they won't be in the same place as normal pointers.

From: Shannon Zhao <[email protected]>

With the addition of ARM64 that does not have a traditional BIOS to scan, add a #ifdef option for x86 to do the traditional BIOS scanning for tables.

Signed-off-by Shannon Zhao <[email protected]>

---
 xen/drivers/acpi/osl.c | 2 ++
 1 file changed, 2 insertions(+)

xen/drivers/acpi/osl.c +0 -0

index ce15470..db74a90 100644

Quoted 1 line

Quoted 1 line · On 23.11.15 at 12:24, <[email protected]> wrote:

Quoted 16 lines · shannon.zhao at linaro.org

From: Shannon Zhao <[email protected]>

With the addition of ARM64 that does not have a traditional BIOS to scan, add a #ifdef option for x86 to do the traditional BIOS scanning for tables.

Signed-off-by Shannon Zhao <[email protected]>

---
 xen/drivers/acpi/osl.c | 2 ++
 1 file changed, 2 insertions(+)

xen/drivers/acpi/osl.c +0 -0

index ce15470..db74a90 100644

xen/drivers/acpi/osl.c acpi_physical_address __init acpi_os_get_root_pointer(void) · line 85

Quoted 8 lines

xen/drivers/acpi/osl.c +2 -0

@@ -78,7 +78,9 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
 	} else {
 		acpi_physical_address pa = 0;
 
+		#ifdef CONFIG_X86
 		acpi_find_root_pointer(&pa);
+		#endif
 		return pa;
 	}

I think it might be best to error out earlier if acpi and !efi_enabled on arm and arm64. If we do that we'll never enter this "else".

If acpi_find_root_pointer doesn't build on arm, we should move it to an x86 specific location, such as xen/arch/x86/efi.

Quoted 30 lines

Quoted 1 line

Quoted 1 line · On 23.11.15 at 12:24, <[email protected]> wrote:

Quoted 16 lines · shannon.zhao at linaro.org

From: Shannon Zhao <[email protected]>

With the addition of ARM64 that does not have a traditional BIOS to scan, add a #ifdef option for x86 to do the traditional BIOS scanning for tables.

Signed-off-by Shannon Zhao <[email protected]>

---
 xen/drivers/acpi/osl.c | 2 ++
 1 file changed, 2 insertions(+)

xen/drivers/acpi/osl.c +0 -0

index ce15470..db74a90 100644

xen/drivers/acpi/osl.c acpi_physical_address __init acpi_os_get_root_pointer(void) · line 85

Quoted 8 lines

xen/drivers/acpi/osl.c +2 -0

@@ -78,7 +78,9 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
 	} else {
 		acpi_physical_address pa = 0;
 
+		#ifdef CONFIG_X86
 		acpi_find_root_pointer(&pa);
+		#endif
 		return pa;
 	}

I think it might be best to error out earlier if acpi and !efi_enabled on arm and arm64. If we do that we'll never enter this "else".

Quoted 2 lines

If acpi_find_root_pointer doesn't build on arm, we should move it to an x86 specific location, such as xen/arch/x86/efi.

No, definitely not (or if anything, then xen/arch/x86/acpi/). Instead the function itself should be stubbed out to do nothing on ARM. (And of course also the #ifdef placement is rather odd).

Quoted 1 line

Quoted 1 line · On 24.11.15 at 04:39, <[email protected]> wrote:

Quoted 20 lines · Jan Beulich

Quoted 19 lines

Quoted 1 line

Quoted 1 line · On 23.11.15 at 12:24, <[email protected]> wrote:

xen/drivers/acpi/osl.c acpi_physical_address __init acpi_os_get_root_pointer(void) · line 85

Quoted 11 lines · shannon.zhao at linaro.org

xen/drivers/acpi/osl.c +2 -0

@@ -78,7 +78,9 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
 	} else {
 		acpi_physical_address pa = 0;
 
+		#ifdef CONFIG_X86
 		acpi_find_root_pointer(&pa);
+		#endif
 		return pa;
 	}

I think it might be best to error out earlier if acpi and !efi_enabled on arm and arm64. If we do that we'll never enter this "else".

If acpi_find_root_pointer doesn't build on arm, we should move it to an x86 specific location, such as xen/arch/x86/efi.

Quoted 4 lines

No, definitely not (or if anything, then xen/arch/x86/acpi/). Instead the function itself should be stubbed out to do nothing on ARM. (And of course also the #ifdef placement is rather odd).

How about adding a new CONFIG_ACPI_LEGACY_TABLES_LOOKUP like Linux kernel for x86?

Quoted 1 line

Quoted 1 line · On 24.11.15 at 04:39, <[email protected]> wrote:

Quoted 20 lines · Jan Beulich

Quoted 19 lines

Quoted 1 line

Quoted 1 line · On 23.11.15 at 12:24, <[email protected]> wrote:

xen/drivers/acpi/osl.c acpi_physical_address __init acpi_os_get_root_pointer(void) · line 85

Quoted 11 lines · On Tue, 17 Nov 2015, [email protected] wrote:

xen/drivers/acpi/osl.c +2 -0

@@ -78,7 +78,9 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
 	} else {
 		acpi_physical_address pa = 0;
 
+		#ifdef CONFIG_X86
 		acpi_find_root_pointer(&pa);
+		#endif
 		return pa;
 	}

I think it might be best to error out earlier if acpi and !efi_enabled on arm and arm64. If we do that we'll never enter this "else".

If acpi_find_root_pointer doesn't build on arm, we should move it to an x86 specific location, such as xen/arch/x86/efi.

Quoted 4 lines

No, definitely not (or if anything, then xen/arch/x86/acpi/). Instead the function itself should be stubbed out to do nothing on ARM. (And of course also the #ifdef placement is rather odd).

How about adding a new CONFIG_ACPI_LEGACY_TABLES_LOOKUP like Linux kernel for x86?

Quoted 30 lines

Quoted 1 line

Quoted 1 line · On 23.11.15 at 12:24, <[email protected]> wrote:

Quoted 16 lines · On Tue, 17 Nov 2015, [email protected] wrote:

From: Shannon Zhao <[email protected]>

With the addition of ARM64 that does not have a traditional BIOS to scan, add a #ifdef option for x86 to do the traditional BIOS scanning for tables.

Signed-off-by Shannon Zhao <[email protected]>

---
 xen/drivers/acpi/osl.c | 2 ++
 1 file changed, 2 insertions(+)

xen/drivers/acpi/osl.c +0 -0

index ce15470..db74a90 100644

xen/drivers/acpi/osl.c acpi_physical_address __init acpi_os_get_root_pointer(void) · line 85

Quoted 8 lines

xen/drivers/acpi/osl.c +2 -0

@@ -78,7 +78,9 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
 	} else {
 		acpi_physical_address pa = 0;
 
+		#ifdef CONFIG_X86
 		acpi_find_root_pointer(&pa);
+		#endif
 		return pa;
 	}

I think it might be best to error out earlier if acpi and !efi_enabled on arm and arm64. If we do that we'll never enter this "else".

Quoted 2 lines

If acpi_find_root_pointer doesn't build on arm, we should move it to an x86 specific location, such as xen/arch/x86/efi.

No, definitely not (or if anything, then xen/arch/x86/acpi/). Instead the function itself should be stubbed out to do nothing on ARM. (And of course also the #ifdef placement is rather odd).

Quoted 1 line

Quoted 1 line · On 23.11.15 at 12:24, <[email protected]> wrote:

Quoted 16 lines · On Tue, 17 Nov 2015, [email protected] wrote:

From: Shannon Zhao <[email protected]>

With the addition of ARM64 that does not have a traditional BIOS to scan, add a #ifdef option for x86 to do the traditional BIOS scanning for tables.

Signed-off-by Shannon Zhao <[email protected]>

---
 xen/drivers/acpi/osl.c | 2 ++
 1 file changed, 2 insertions(+)

xen/drivers/acpi/osl.c +0 -0

index ce15470..db74a90 100644

xen/drivers/acpi/osl.c acpi_physical_address __init acpi_os_get_root_pointer(void) · line 85

Quoted 8 lines

xen/drivers/acpi/osl.c +2 -0

@@ -78,7 +78,9 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
 	} else {
 		acpi_physical_address pa = 0;
 
+		#ifdef CONFIG_X86
 		acpi_find_root_pointer(&pa);
+		#endif
 		return pa;
 	}

I think it might be best to error out earlier if acpi and !efi_enabled on arm and arm64. If we do that we'll never enter this "else".

If acpi_find_root_pointer doesn't build on arm, we should move it to an x86 specific location, such as xen/arch/x86/efi.

From: Shannon Zhao <[email protected]>
Current acpi_os_map_memory is specific to x86. Refactor it to be architecturally independent.

Signed-off-by Shannon Zhao <[email protected]>

 xen/arch/x86/acpi/lib.c | 16 ++++++++++++++++
 xen/drivers/acpi/osl.c  | 12 +-----------
 xen/include/xen/acpi.h  |  2 ++
 3 files changed, 19 insertions(+), 11 deletions(-)

xen/arch/x86/acpi/lib.c +16 -0

index cc15ea3..1e2e124 100644
@@ -33,6 +33,22 @@ u8 __read_mostly acpi_disable_value;
 u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
     {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
 
+void __iomem *
+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
+{
+	if (system_state >= SYS_STATE_active) {
+		mfn_t mfn = _mfn(PFN_DOWN(phys));
+		unsigned int offs = phys & (PAGE_SIZE - 1);
+
+		/* The low first Mb is always mapped. */
+		if ( !((phys + size - 1) >> 20) )
+			return __va(phys);
+		return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
+			      PAGE_HYPERVISOR_NOCACHE) + offs;
+	}
+	return __acpi_map_table(phys, size);
+}
+
 /*
  * Important Safety Note:  The fixed ACPI page numbers are *subtracted*
  * from the fixed base.  That's why we start at FIX_ACPI_END and

xen/drivers/acpi/osl.c +1 -11

index db74a90..54fb0f0 100644
@@ -88,17 +88,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
 void __iomem *
 acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
 {
-	if (system_state >= SYS_STATE_active) {
-		mfn_t mfn = _mfn(PFN_DOWN(phys));
-		unsigned int offs = phys & (PAGE_SIZE - 1);
-
-		/* The low first Mb is always mapped. */
-		if ( !((phys + size - 1) >> 20) )
-			return __va(phys);
-		return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
-			      PAGE_HYPERVISOR_NOCACHE) + offs;
-	}
-	return __acpi_map_table(phys, size);
+	return arch_acpi_os_map_memory(phys, size);
 }
 
 void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)

xen/include/xen/acpi.h +2 -0

index 0f1077d..48d7810 100644
@@ -54,6 +54,8 @@ 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);
 
+void __iomem *
+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size);
 unsigned int acpi_get_processor_id (unsigned int cpu);
 char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
 int acpi_boot_init (void);

Signature · 7 lines

2.1.0


_______________________________________________
Xen-devel mailing list
Xen-devel at lists.xen.org
http://lists.xen.org/xen-devel

Quoted 1 line

Quoted 1 line · On 23.11.15 at 12:29, <[email protected]> wrote:

Quoted 3 lines · shannon.zhao at linaro.org

From: Shannon Zhao <[email protected]>
Current acpi_os_map_memory is specific to x86. Refactor it to be architecturally independent.

I would say "Move it to an x86-specific location".

Quoted 1 line

Quoted 1 line · On 23.11.15 at 12:29, <[email protected]> wrote:

Quoted 3 lines · On Tue, 17 Nov 2015, [email protected] wrote:

From: Shannon Zhao <[email protected]>
Current acpi_os_map_memory is specific to x86. Refactor it to be architecturally independent.

I would say "Move it to an x86-specific location".

From: Shannon Zhao <[email protected]>
Current acpi_os_map_memory is specific to x86. Refactor it to be architecturally independent.

Signed-off-by Shannon Zhao <[email protected]>

 xen/arch/x86/acpi/lib.c | 16 ++++++++++++++++
 xen/drivers/acpi/osl.c  | 12 +-----------
 xen/include/xen/acpi.h  |  2 ++
 3 files changed, 19 insertions(+), 11 deletions(-)

xen/arch/x86/acpi/lib.c +16 -0

index cc15ea3..1e2e124 100644
@@ -33,6 +33,22 @@ u8 __read_mostly acpi_disable_value;
 u32 __read_mostly x86_acpiid_to_apicid[MAX_MADT_ENTRIES] =
     {[0 ... MAX_MADT_ENTRIES - 1] = BAD_APICID };
 
+void __iomem *
+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
+{
+	if (system_state >= SYS_STATE_active) {
+		mfn_t mfn = _mfn(PFN_DOWN(phys));
+		unsigned int offs = phys & (PAGE_SIZE - 1);
+
+		/* The low first Mb is always mapped. */
+		if ( !((phys + size - 1) >> 20) )
+			return __va(phys);
+		return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
+			      PAGE_HYPERVISOR_NOCACHE) + offs;
+	}
+	return __acpi_map_table(phys, size);
+}
+
 /*
  * Important Safety Note:  The fixed ACPI page numbers are *subtracted*
  * from the fixed base.  That's why we start at FIX_ACPI_END and

xen/drivers/acpi/osl.c +1 -11

index db74a90..54fb0f0 100644
@@ -88,17 +88,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
 void __iomem *
 acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
 {
-	if (system_state >= SYS_STATE_active) {
-		mfn_t mfn = _mfn(PFN_DOWN(phys));
-		unsigned int offs = phys & (PAGE_SIZE - 1);
-
-		/* The low first Mb is always mapped. */
-		if ( !((phys + size - 1) >> 20) )
-			return __va(phys);
-		return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
-			      PAGE_HYPERVISOR_NOCACHE) + offs;
-	}
-	return __acpi_map_table(phys, size);
+	return arch_acpi_os_map_memory(phys, size);
 }
 
 void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)

xen/include/xen/acpi.h +2 -0

index 0f1077d..48d7810 100644
@@ -54,6 +54,8 @@ 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);
 
+void __iomem *
+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size);
 unsigned int acpi_get_processor_id (unsigned int cpu);
 char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
 int acpi_boot_init (void);

Signature · 7 lines

2.1.0


_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

From: Shannon Zhao <[email protected]>

Current acpi_os_map_memory is specific to x86. Refactor it to be architecturally independent.

From: Shannon Zhao <[email protected]>

Current acpi_os_map_memory is specific to x86. Refactor it to be architecturally independent.

From: Shannon Zhao <[email protected]>

Signed-off-by Shannon Zhao <[email protected]>

---
 xen/arch/arm/Makefile      |  1 +
 xen/arch/arm/acpi/Makefile |  1 +
 xen/arch/arm/acpi/lib.c    | 33 +++++++++++++++++++++++++++++++++
 3 files changed, 35 insertions(+)
 create mode 100644 xen/arch/arm/acpi/Makefile
 create mode 100644 xen/arch/arm/acpi/lib.c

xen/arch/arm/Makefile +1 -0

index 1ef39f7..1851ae8 100644
@@ -2,6 +2,7 @@ subdir-$(arm32) += arm32
 subdir-$(arm64) += arm64
 subdir-y += platforms
 subdir-$(arm64) += efi
+subdir-$(HAS_ACPI) += acpi
 
 obj-$(EARLY_PRINTK) += early_printk.o
 obj-y += cpu.o

xen/arch/arm/acpi/Makefile new file +1 -0

new file mode 100644
index 0000000..b5be22d
@@ -0,0 +1 @@
+obj-y += lib.o

xen/arch/arm/acpi/lib.c new file +33 -0

new file mode 100644
index 0000000..b68623b
@@ -0,0 +1,33 @@
+/*
+ *  lib.c - Architecture-Specific Low-Level ACPI Support
+ *
+ *  Copyright (C) 2015, Shannon Zhao <[email protected]>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  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
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <xen/acpi.h>
+#include <xen/mm.h>
+#include <asm/mm.h>
+
+void __iomem *
+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
+{
+    return __va(phys);
+}

Signature · 1 line

2.1.0

Quoted 1 line · shannon.zhao at linaro.org

From: Shannon Zhao <[email protected]>

could you please add a couple of lines to the commit message mentioning why __va(phys) is an acceptable implementation of arch_acpi_os_map_memory?

Hi,

Quoted 2 lines · Stefano Stabellini

Quoted 2 lines · shannon.zhao at linaro.org

Quoted 1 line

Quoted 1 line

From: Shannon Zhao <[email protected]>

Quoted 2 lines

Quoted 2 lines

could you please add a couple of lines to the commit message mentioning why __va(phys) is an acceptable implementation of arch_acpi_os_map_memory?

FWIW, I already asked this question multiple time on the previous series without clear answer.

__va should only be used when the memory is direct-mapped to Xen (i.e accessible directly). On ARM64, this is only the case for the RAM. Can someone confirm the ACPI will always reside to the RAM?

Quoted 1 line

Quoted 1 line · On 07.12.15 at 09:58, <[email protected]> wrote:

Quoted 11 lines · Julien Grall

Quoted 4 lines · Stefano Stabellini

Quoted 4 lines · shannon.zhao at linaro.org

Quoted 1 line

Quoted 1 line

From: Shannon Zhao <[email protected]>

could you please add a couple of lines to the commit message mentioning why __va(phys) is an acceptable implementation of arch_acpi_os_map_memory?

FWIW, I already asked this question multiple time on the previous series without clear answer.

__va should only be used when the memory is direct-mapped to Xen (i.e accessible directly). On ARM64, this is only the case for the RAM. Can someone confirm the ACPI will always reside to the RAM?

I checked this with the UEFI SPEC. It says in 2.3.6 AArch64 Platforms:
"If ACPI is supported :
? ACPI Tables loaded at boot time can be contained in memory of type EfiACPIReclaimMemory (recommended) or EfiACPIMemoryNVS."

So I think it means the ACPI tables will always reside in RAM.

Quoted 17 lines

Quoted 1 line

Quoted 1 line · On 07.12.15 at 09:58, <[email protected]> wrote:

Quoted 15 lines · Julien Grall

Quoted 6 lines · Stefano Stabellini

Quoted 6 lines · shannon.zhao at linaro.org

Quoted 1 line

Quoted 1 line

From: Shannon Zhao <[email protected]>

could you please add a couple of lines to the commit message mentioning
why __va(phys) is an acceptable implementation of arch_acpi_os_map_memory?

FWIW, I already asked this question multiple time on the previous series
without clear answer.

__va should only be used when the memory is direct-mapped to Xen (i.e accessible directly). On ARM64, this is only the case for the RAM. Can
someone confirm the ACPI will always reside to the RAM?

Quoted 6 lines

I checked this with the UEFI SPEC. It says in 2.3.6 AArch64 Platforms:
"If ACPI is supported :
? ACPI Tables loaded at boot time can be contained in memory of type EfiACPIReclaimMemory (recommended) or EfiACPIMemoryNVS."

So I think it means the ACPI tables will always reside in RAM.

I think NVS doesn't necessarily mean RAM.

Quoted 17 lines · Jan Beulich

Quoted 17 lines

Quoted 1 line

Quoted 1 line · On 07.12.15 at 09:58, <[email protected]> wrote:

Quoted 15 lines · Julien Grall

Quoted 6 lines · Stefano Stabellini

Quoted 6 lines · shannon.zhao at linaro.org

Quoted 1 line

Quoted 1 line

From: Shannon Zhao <[email protected]>

could you please add a couple of lines to the commit message mentioning
why __va(phys) is an acceptable implementation of arch_acpi_os_map_memory?

FWIW, I already asked this question multiple time on the previous series
without clear answer.

__va should only be used when the memory is direct-mapped to Xen (i.e accessible directly). On ARM64, this is only the case for the RAM. Can
someone confirm the ACPI will always reside to the RAM?

Quoted 8 lines

Quoted 6 lines

I checked this with the UEFI SPEC. It says in 2.3.6 AArch64 Platforms:
"If ACPI is supported :
? ACPI Tables loaded at boot time can be contained in memory of type EfiACPIReclaimMemory (recommended) or EfiACPIMemoryNVS."

So I think it means the ACPI tables will always reside in RAM.

I think NVS doesn't necessarily mean RAM.

That's what I thought/expected too (sounds like it could be flash, CMOS, ROM etc), but looking at the ACPI 6.0 spec ("16.3.2 BIOS Initialization of Memory") it says:

Memory identified by the BIOS as being reserved by the BIOS for its use.
OSPM is required to tag this memory as cacheable, and to save and
restore its image before entering an S4 state.

IOW, if I'm reading that correctly, it actually is "memory", and it is only "NV" by virtue of requiring the OSPM to save/restore it over suspend (so not at all "NV" in the usual sense).

Quoted 35 lines · Ian Campbell

Quoted 17 lines · Jan Beulich

Quoted 17 lines

Quoted 1 line

Quoted 1 line · On 07.12.15 at 09:58, <[email protected]> wrote:

Quoted 15 lines · Julien Grall

Quoted 6 lines · Stefano Stabellini

Quoted 6 lines · On Tue, 17 Nov 2015, [email protected] wrote:

Quoted 1 line

Quoted 1 line

From: Shannon Zhao <[email protected]>

could you please add a couple of lines to the commit message mentioning
why __va(phys) is an acceptable implementation of arch_acpi_os_map_memory?

FWIW, I already asked this question multiple time on the previous series
without clear answer.

__va should only be used when the memory is direct-mapped to Xen (i.e accessible directly). On ARM64, this is only the case for the RAM. Can
someone confirm the ACPI will always reside to the RAM?

Quoted 8 lines

Quoted 6 lines

I checked this with the UEFI SPEC. It says in 2.3.6 AArch64 Platforms:
"If ACPI is supported :
● ACPI Tables loaded at boot time can be contained in memory of type EfiACPIReclaimMemory (recommended) or EfiACPIMemoryNVS."

So I think it means the ACPI tables will always reside in RAM.

I think NVS doesn't necessarily mean RAM.

That's what I thought/expected too (sounds like it could be flash, CMOS, ROM etc), but looking at the ACPI 6.0 spec ("16.3.2 BIOS Initialization of Memory") it says:

Memory identified by the BIOS as being reserved by the BIOS for its use.
OSPM is required to tag this memory as cacheable, and to save and
restore its image before entering an S4 state.

Quoted 3 lines

IOW, if I'm reading that correctly, it actually is "memory", and it is only "NV" by virtue of requiring the OSPM to save/restore it over suspend (so not at all "NV" in the usual sense).

I think it would be safer to use vmap. It won't impact much Xen as the mapping are mostly used during Xen boot and DOM0 creation.

Quoted 17 lines · Jan Beulich

Quoted 17 lines

Quoted 1 line

Quoted 1 line · On 07.12.15 at 09:58, <[email protected]> wrote:

Quoted 15 lines · Julien Grall

Quoted 6 lines · Stefano Stabellini

Quoted 6 lines · On Tue, 17 Nov 2015, [email protected] wrote:

Quoted 1 line

Quoted 1 line

From: Shannon Zhao <[email protected]>

could you please add a couple of lines to the commit message mentioning
why __va(phys) is an acceptable implementation of arch_acpi_os_map_memory?

FWIW, I already asked this question multiple time on the previous series
without clear answer.

__va should only be used when the memory is direct-mapped to Xen (i.e accessible directly). On ARM64, this is only the case for the RAM. Can
someone confirm the ACPI will always reside to the RAM?

Quoted 8 lines

Quoted 6 lines

I checked this with the UEFI SPEC. It says in 2.3.6 AArch64 Platforms:
"If ACPI is supported :
● ACPI Tables loaded at boot time can be contained in memory of type EfiACPIReclaimMemory (recommended) or EfiACPIMemoryNVS."

So I think it means the ACPI tables will always reside in RAM.

I think NVS doesn't necessarily mean RAM.

That's what I thought/expected too (sounds like it could be flash, CMOS, ROM etc), but looking at the ACPI 6.0 spec ("16.3.2 BIOS Initialization of Memory") it says:

Memory identified by the BIOS as being reserved by the BIOS for its use.
OSPM is required to tag this memory as cacheable, and to save and
restore its image before entering an S4 state.

IOW, if I'm reading that correctly, it actually is "memory", and it is only "NV" by virtue of requiring the OSPM to save/restore it over suspend (so not at all "NV" in the usual sense).

Quoted 17 lines

Quoted 1 line

Quoted 1 line · On 07.12.15 at 09:58, <[email protected]> wrote:

Quoted 15 lines · Julien Grall

Quoted 6 lines · Stefano Stabellini

Quoted 6 lines · On Tue, 17 Nov 2015, [email protected] wrote:

Quoted 1 line

Quoted 1 line

From: Shannon Zhao <[email protected]>

could you please add a couple of lines to the commit message mentioning
why __va(phys) is an acceptable implementation of arch_acpi_os_map_memory?

FWIW, I already asked this question multiple time on the previous series
without clear answer.

__va should only be used when the memory is direct-mapped to Xen (i.e accessible directly). On ARM64, this is only the case for the RAM. Can
someone confirm the ACPI will always reside to the RAM?

Quoted 6 lines

I checked this with the UEFI SPEC. It says in 2.3.6 AArch64 Platforms:
"If ACPI is supported :
● ACPI Tables loaded at boot time can be contained in memory of type EfiACPIReclaimMemory (recommended) or EfiACPIMemoryNVS."

So I think it means the ACPI tables will always reside in RAM.

I think NVS doesn't necessarily mean RAM.

Quoted 1 line

Quoted 1 line · On 07.12.15 at 09:58, <[email protected]> wrote:

Quoted 11 lines · Julien Grall

Quoted 4 lines · Stefano Stabellini

Quoted 4 lines · On Tue, 17 Nov 2015, [email protected] wrote:

Quoted 1 line

Quoted 1 line

From: Shannon Zhao <[email protected]>

could you please add a couple of lines to the commit message mentioning why __va(phys) is an acceptable implementation of arch_acpi_os_map_memory?

FWIW, I already asked this question multiple time on the previous series without clear answer.

__va should only be used when the memory is direct-mapped to Xen (i.e accessible directly). On ARM64, this is only the case for the RAM. Can someone confirm the ACPI will always reside to the RAM?

I checked this with the UEFI SPEC. It says in 2.3.6 AArch64 Platforms:
"If ACPI is supported :
● ACPI Tables loaded at boot time can be contained in memory of type EfiACPIReclaimMemory (recommended) or EfiACPIMemoryNVS."

So I think it means the ACPI tables will always reside in RAM.

Quoted 1 line · On Tue, 17 Nov 2015, [email protected] wrote:

From: Shannon Zhao <[email protected]>

could you please add a couple of lines to the commit message mentioning why __va(phys) is an acceptable implementation of arch_acpi_os_map_memory?

From: Shannon Zhao <[email protected]>

Signed-off-by Shannon Zhao <[email protected]>

---
 xen/arch/arm/Makefile      |  1 +
 xen/arch/arm/acpi/Makefile |  1 +
 xen/arch/arm/acpi/lib.c    | 33 +++++++++++++++++++++++++++++++++
 3 files changed, 35 insertions(+)
 create mode 100644 xen/arch/arm/acpi/Makefile
 create mode 100644 xen/arch/arm/acpi/lib.c

xen/arch/arm/Makefile +1 -0

index 1ef39f7..1851ae8 100644
@@ -2,6 +2,7 @@ subdir-$(arm32) += arm32
 subdir-$(arm64) += arm64
 subdir-y += platforms
 subdir-$(arm64) += efi
+subdir-$(HAS_ACPI) += acpi
 
 obj-$(EARLY_PRINTK) += early_printk.o
 obj-y += cpu.o

xen/arch/arm/acpi/Makefile new file +1 -0

new file mode 100644
index 0000000..b5be22d
@@ -0,0 +1 @@
+obj-y += lib.o

xen/arch/arm/acpi/lib.c new file +33 -0

new file mode 100644
index 0000000..b68623b
@@ -0,0 +1,33 @@
+/*
+ *  lib.c - Architecture-Specific Low-Level ACPI Support
+ *
+ *  Copyright (C) 2015, Shannon Zhao <[email protected]>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  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
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <xen/acpi.h>
+#include <xen/mm.h>
+#include <asm/mm.h>
+
+void __iomem *
+arch_acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
+{
+    return __va(phys);
+}

Signature · 1 line

2.1.0

From: Shannon Zhao <[email protected]>

Add architecture specific definitions and calls required for acpi in new header file.

Signed-off-by Parth Dixit <[email protected]>

Signed-off-by Shannon Zhao <[email protected]>

 xen/arch/arm/setup.c       |  3 +++
 xen/include/asm-arm/acpi.h | 38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 41 insertions(+)
 create mode 100644 xen/include/asm-arm/acpi.h

xen/arch/arm/setup.c +3 -0

index e95759d..3b29904 100644
@@ -45,11 +45,14 @@
 #include <asm/procinfo.h>
 #include <asm/setup.h>
 #include <xsm/xsm.h>
+#include <asm/acpi.h>
 
 struct bootinfo __initdata bootinfo;
 
 struct cpuinfo_arm __read_mostly boot_cpu_data;
 
+bool_t __read_mostly acpi_disabled;
+
 #ifdef CONFIG_ARM_32
 static unsigned long opt_xenheap_megabytes __initdata;
 integer_param("xenheap_megabytes", opt_xenheap_megabytes);

xen/include/asm-arm/acpi.h new file +38 -0

new file mode 100644
index 0000000..e41e03b
@@ -0,0 +1,38 @@
+/*
+ *  Copyright (C) 2015, Shannon Zhao <[email protected]>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  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_ARM_ACPI_H
+#define _ASM_ARM_ACPI_H
+
+#include <xen/init.h>
+
+#define COMPILER_DEPENDENT_INT64   long long
+#define COMPILER_DEPENDENT_UINT64  unsigned long long
+
+extern bool_t acpi_disabled;
+/* Basic configuration for ACPI */
+static inline void disable_acpi(void)
+{
+    acpi_disabled = 1;
+}
+
+#endif /*_ASM_ARM_ACPI_H*/

Signature · 1 line

2.1.0

From: Shannon Zhao <[email protected]>

Add architecture specific definitions and calls required for acpi in new header file.

Signed-off-by Parth Dixit <[email protected]>

Signed-off-by Shannon Zhao <[email protected]>

 xen/arch/arm/setup.c       |  3 +++
 xen/include/asm-arm/acpi.h | 38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 41 insertions(+)
 create mode 100644 xen/include/asm-arm/acpi.h

xen/arch/arm/setup.c +3 -0

index e95759d..3b29904 100644
@@ -45,11 +45,14 @@
 #include <asm/procinfo.h>
 #include <asm/setup.h>
 #include <xsm/xsm.h>
+#include <asm/acpi.h>
 
 struct bootinfo __initdata bootinfo;
 
 struct cpuinfo_arm __read_mostly boot_cpu_data;
 
+bool_t __read_mostly acpi_disabled;
+
 #ifdef CONFIG_ARM_32
 static unsigned long opt_xenheap_megabytes __initdata;
 integer_param("xenheap_megabytes", opt_xenheap_megabytes);

xen/include/asm-arm/acpi.h new file +38 -0

new file mode 100644
index 0000000..e41e03b
@@ -0,0 +1,38 @@
+/*
+ *  Copyright (C) 2015, Shannon Zhao <[email protected]>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  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_ARM_ACPI_H
+#define _ASM_ARM_ACPI_H
+
+#include <xen/init.h>
+
+#define COMPILER_DEPENDENT_INT64   long long
+#define COMPILER_DEPENDENT_UINT64  unsigned long long
+
+extern bool_t acpi_disabled;
+/* Basic configuration for ACPI */
+static inline void disable_acpi(void)
+{
+    acpi_disabled = 1;
+}
+
+#endif /*_ASM_ARM_ACPI_H*/

Signature · 1 line

2.1.0

From: Parth Dixit <[email protected]>

acpi_boot_table_init() will be called in start_xen 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 <[email protected]>

Signed-off-by Parth Dixit <[email protected]>

Signed-off-by Shannon Zhao <[email protected]>

---
 xen/arch/arm/acpi/Makefile |  1 +
 xen/arch/arm/acpi/boot.c   | 62 ++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/setup.c       |  4 +++
 3 files changed, 67 insertions(+)
 create mode 100644 xen/arch/arm/acpi/boot.c

xen/arch/arm/acpi/Makefile +1 -0

index b5be22d..196c40a 100644
@@ -1 +1,2 @@
 obj-y += lib.o
+obj-y += boot.o

xen/arch/arm/acpi/boot.c new file +62 -0

new file mode 100644
index 0000000..ad51afc
@@ -0,0 +1,62 @@
+/*
+ *  ARM Specific Low-Level ACPI Boot Support
+ *
+ *  Copyright (C) 2001, 2002 Paul Diefenbaugh <[email protected]>
+ *  Copyright (C) 2001 Jun Nakajima <[email protected]>
+ *  Copyright (C) 2014, Naresh Bhat <[email protected]>
+ *  Copyright (C) 2015, Shannon Zhao <[email protected]>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  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
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <xen/init.h>
+#include <xen/acpi.h>
+
+#include <asm/acpi.h>
+
+/*
+ * 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
+ *
+ * return value: (currently ignored)
+ *	0: success
+ *	!0: failure
+ *
+ * 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;
+}

xen/arch/arm/setup.c +1 -0

index 3b29904..768312f 100644
@@ -36,6 +36,7 @@
 #include <xen/pfn.h>
 #include <xen/vmap.h>
 #include <xen/libfdt/libfdt.h>
+#include <xen/acpi.h>
 #include <asm/page.h>
 #include <asm/current.h>
 #include <asm/setup.h>

xen/arch/arm/setup.c +0 -0

     vm_init();
     dt_unflatten_host_device_tree();
 

Signature · 7 lines

2.1.0


_______________________________________________
Xen-devel mailing list
Xen-devel at lists.xen.org
http://lists.xen.org/xen-devel

From: Parth Dixit <[email protected]>

acpi_boot_table_init() will be called in start_xen 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 <[email protected]>

Signed-off-by Parth Dixit <[email protected]>

Signed-off-by Shannon Zhao <[email protected]>

---
 xen/arch/arm/acpi/Makefile |  1 +
 xen/arch/arm/acpi/boot.c   | 62 ++++++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/setup.c       |  4 +++
 3 files changed, 67 insertions(+)
 create mode 100644 xen/arch/arm/acpi/boot.c

xen/arch/arm/acpi/Makefile +1 -0

index b5be22d..196c40a 100644
@@ -1 +1,2 @@
 obj-y += lib.o
+obj-y += boot.o

xen/arch/arm/acpi/boot.c new file +62 -0

new file mode 100644
index 0000000..ad51afc
@@ -0,0 +1,62 @@
+/*
+ *  ARM Specific Low-Level ACPI Boot Support
+ *
+ *  Copyright (C) 2001, 2002 Paul Diefenbaugh <[email protected]>
+ *  Copyright (C) 2001 Jun Nakajima <[email protected]>
+ *  Copyright (C) 2014, Naresh Bhat <[email protected]>
+ *  Copyright (C) 2015, Shannon Zhao <[email protected]>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  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
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <xen/init.h>
+#include <xen/acpi.h>
+
+#include <asm/acpi.h>
+
+/*
+ * 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
+ *
+ * return value: (currently ignored)
+ *	0: success
+ *	!0: failure
+ *
+ * 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;
+}

xen/arch/arm/setup.c +1 -0

index 3b29904..768312f 100644
@@ -36,6 +36,7 @@
 #include <xen/pfn.h>
 #include <xen/vmap.h>
 #include <xen/libfdt/libfdt.h>
+#include <xen/acpi.h>
 #include <asm/page.h>
 #include <asm/current.h>
 #include <asm/setup.h>

xen/arch/arm/setup.c +0 -0

     vm_init();
     dt_unflatten_host_device_tree();
 

Signature · 7 lines

2.1.0


_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel

From: Shannon Zhao <[email protected]>

If ACPI is initialized after the boot allocator has ended(the system state is not early boot), assert happens in acpi_os_zalloc_memory and acpi_boot_table_init will fail. So it needs to move end_boot_allocator after acpi_boot_table_init.

Signed-off-by Parth Dixit <[email protected]>

Signed-off-by Shannon Zhao <[email protected]>

 xen/arch/arm/setup.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

xen/arch/arm/setup.c +2 -4

index 768312f..c15a09d 100644
@@ -613,8 +613,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)

@@ -682,8 +680,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
 

@@ -757,6 +753,8 @@ void __init start_xen(unsigned long boot_phys_offset,
     /* Parse the ACPI tables for possible boot-time configuration */
     acpi_boot_table_init();
 
+    end_boot_allocator();
+
     vm_init();
     dt_unflatten_host_device_tree();
 

Signature · 1 line

2.1.0

From: Shannon Zhao <[email protected]>

If ACPI is initialized after the boot allocator has ended(the system state is not early boot), assert happens in acpi_os_zalloc_memory and acpi_boot_table_init will fail. So it needs to move end_boot_allocator after acpi_boot_table_init.

Signed-off-by Parth Dixit <[email protected]>

Signed-off-by Shannon Zhao <[email protected]>

 xen/arch/arm/setup.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

xen/arch/arm/setup.c +2 -4

index 768312f..c15a09d 100644
@@ -613,8 +613,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)

@@ -682,8 +680,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
 

@@ -757,6 +753,8 @@ void __init start_xen(unsigned long boot_phys_offset,
     /* Parse the ACPI tables for possible boot-time configuration */
     acpi_boot_table_init();
 
+    end_boot_allocator();
+
     vm_init();
     dt_unflatten_host_device_tree();
 

Signature · 1 line

2.1.0

From: Shannon Zhao <[email protected]>

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 <[email protected]>

Signed-off-by Naresh Bhat <[email protected]>

Signed-off-by Shannon Zhao <[email protected]>

 xen/include/acpi/actbl.h | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

xen/include/acpi/actbl.h +9 -3

index 856945d..66e29c3 100644
@@ -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-Specific Boot Flags (see below for individual flags) (ACPI 5.1) */
+	u8 minor_revision;      /* FADT Minor Revision (ACPI 5.1) */
 	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) */
 
 #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) ACPI 5.1 */
+
+#define ACPI_FADT_PSCI_COMPLIANT    (1)        /* 00:  [V5+] PSCI 0.2+ is implemented */
+#define ACPI_FADT_PSCI_USE_HVC      (1<<1)     /* 01:  [V5+] 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 (minor_revision) + 1)
 #define ACPI_FADT_V3_SIZE       (u32) (ACPI_FADT_OFFSET (sleep_control))
 #define ACPI_FADT_V5_SIZE       (u32) (sizeof (struct acpi_table_fadt))
 

Signature · 1 line

2.1.0

From: Shannon Zhao <[email protected]>

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 <[email protected]>

Signed-off-by Naresh Bhat <[email protected]>

Signed-off-by Shannon Zhao <[email protected]>

 xen/include/acpi/actbl.h | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

xen/include/acpi/actbl.h +9 -3

index 856945d..66e29c3 100644
@@ -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-Specific Boot Flags (see below for individual flags) (ACPI 5.1) */
+	u8 minor_revision;      /* FADT Minor Revision (ACPI 5.1) */
 	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) */
 
 #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) ACPI 5.1 */
+
+#define ACPI_FADT_PSCI_COMPLIANT    (1)        /* 00:  [V5+] PSCI 0.2+ is implemented */
+#define ACPI_FADT_PSCI_USE_HVC      (1<<1)     /* 01:  [V5+] 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 (minor_revision) + 1)
 #define ACPI_FADT_V3_SIZE       (u32) (ACPI_FADT_OFFSET (sleep_control))
 #define ACPI_FADT_V5_SIZE       (u32) (sizeof (struct acpi_table_fadt))
 

Signature · 1 line

2.1.0

From: Bob Moore <[email protected]>

ACPICA commit 72b0b6741990f619f6aaa915302836b7cbb41ac4

One new 64-bit field at the end of the table. FADT version is now 6.

Link https://github.com/acpica/acpica/commit/72b0b674

Signed-off-by Bob Moore <[email protected]>

Signed-off-by Lv Zheng <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

[Linux commit aeb823bbacc2a3aaee29eda5875b58a049fa1f78]

Signed-off-by Shannon Zhao <[email protected]>

 xen/include/acpi/actbl.h | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

xen/include/acpi/actbl.h +10 -7

index 66e29c3..3079176 100644
@@ -258,6 +258,7 @@ struct acpi_table_fadt {
 	struct acpi_generic_address xgpe1_block;	/* 64-bit Extended General Purpose Event 1 Reg Blk address */
 	struct acpi_generic_address sleep_control;	/* 64-bit Sleep Control register */
 	struct acpi_generic_address sleep_status;	/* 64-bit Sleep Status register */
+	u64 hypervisor_id;      /* Hypervisor Vendor ID (ACPI 6.0) */
 };
 
 /* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) */

@@ -315,7 +316,7 @@ enum acpi_prefered_pm_profiles {
 	PM_TABLET = 8
 };
 
-/* Values for sleep_status and sleep_control registers (V5 FADT) */
+/* Values for sleep_status and sleep_control registers (V5+ FADT) */
 
 #define ACPI_X_WAKE_STATUS          0x80
 #define ACPI_X_SLEEP_TYPE_MASK      0x1C

@@ -344,15 +345,17 @@ enum acpi_prefered_pm_profiles {
  * FADT is the bottom line as to what the version really is.
  *
  * For reference, the values below are as follows:
- *     FADT V1  size: 0x074
- *     FADT V2  size: 0x084
- *     FADT V3  size: 0x0F4
- *     FADT V4  size: 0x0F4
- *     FADT V5  size: 0x10C
+ *     FADT V1 size: 0x074
+ *     FADT V2 size: 0x084
+ *     FADT V3 size: 0x0F4
+ *     FADT V4 size: 0x0F4
+ *     FADT V5 size: 0x10C
+ *     FADT V6 size: 0x114
  */
 #define ACPI_FADT_V1_SIZE       (u32) (ACPI_FADT_OFFSET (flags) + 4)
 #define ACPI_FADT_V2_SIZE       (u32) (ACPI_FADT_OFFSET (minor_revision) + 1)
 #define ACPI_FADT_V3_SIZE       (u32) (ACPI_FADT_OFFSET (sleep_control))
-#define ACPI_FADT_V5_SIZE       (u32) (sizeof (struct acpi_table_fadt))
+#define ACPI_FADT_V5_SIZE       (u32) (ACPI_FADT_OFFSET (hypervisor_id))
+#define ACPI_FADT_V6_SIZE       (u32) (sizeof (struct acpi_table_fadt))
 
 #endif				/* __ACTBL_H__ */

Signature · 1 line

2.1.0

From: Bob Moore <[email protected]>

ACPICA commit 72b0b6741990f619f6aaa915302836b7cbb41ac4

One new 64-bit field at the end of the table. FADT version is now 6.

Link https://github.com/acpica/acpica/commit/72b0b674

Signed-off-by Bob Moore <[email protected]>

Signed-off-by Lv Zheng <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

[Linux commit aeb823bbacc2a3aaee29eda5875b58a049fa1f78]

Signed-off-by Shannon Zhao <[email protected]>

 xen/include/acpi/actbl.h | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

xen/include/acpi/actbl.h +10 -7

index 66e29c3..3079176 100644
@@ -258,6 +258,7 @@ struct acpi_table_fadt {
 	struct acpi_generic_address xgpe1_block;	/* 64-bit Extended General Purpose Event 1 Reg Blk address */
 	struct acpi_generic_address sleep_control;	/* 64-bit Sleep Control register */
 	struct acpi_generic_address sleep_status;	/* 64-bit Sleep Status register */
+	u64 hypervisor_id;      /* Hypervisor Vendor ID (ACPI 6.0) */
 };
 
 /* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) */

@@ -315,7 +316,7 @@ enum acpi_prefered_pm_profiles {
 	PM_TABLET = 8
 };
 
-/* Values for sleep_status and sleep_control registers (V5 FADT) */
+/* Values for sleep_status and sleep_control registers (V5+ FADT) */
 
 #define ACPI_X_WAKE_STATUS          0x80
 #define ACPI_X_SLEEP_TYPE_MASK      0x1C

@@ -344,15 +345,17 @@ enum acpi_prefered_pm_profiles {
  * FADT is the bottom line as to what the version really is.
  *
  * For reference, the values below are as follows:
- *     FADT V1  size: 0x074
- *     FADT V2  size: 0x084
- *     FADT V3  size: 0x0F4
- *     FADT V4  size: 0x0F4
- *     FADT V5  size: 0x10C
+ *     FADT V1 size: 0x074
+ *     FADT V2 size: 0x084
+ *     FADT V3 size: 0x0F4
+ *     FADT V4 size: 0x0F4
+ *     FADT V5 size: 0x10C
+ *     FADT V6 size: 0x114
  */
 #define ACPI_FADT_V1_SIZE       (u32) (ACPI_FADT_OFFSET (flags) + 4)
 #define ACPI_FADT_V2_SIZE       (u32) (ACPI_FADT_OFFSET (minor_revision) + 1)
 #define ACPI_FADT_V3_SIZE       (u32) (ACPI_FADT_OFFSET (sleep_control))
-#define ACPI_FADT_V5_SIZE       (u32) (sizeof (struct acpi_table_fadt))
+#define ACPI_FADT_V5_SIZE       (u32) (ACPI_FADT_OFFSET (hypervisor_id))
+#define ACPI_FADT_V6_SIZE       (u32) (sizeof (struct acpi_table_fadt))
 
 #endif				/* __ACTBL_H__ */

Signature · 1 line

2.1.0

Quoted 1 line

Quoted 1 line · On 17.11.15 at 10:40, <[email protected]> wrote:

From: Bob Moore <[email protected]>

ACPICA commit 72b0b6741990f619f6aaa915302836b7cbb41ac4

One new 64-bit field at the end of the table. FADT version is now 6.

Link https://github.com/acpica/acpica/commit/72b0b674

Signed-off-by Bob Moore <[email protected]>

Signed-off-by Lv Zheng <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

[Linux commit aeb823bbacc2a3aaee29eda5875b58a049fa1f78]

Signed-off-by Shannon Zhao <[email protected]>

---
 xen/include/acpi/actbl.h | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

Quoted 14 lines

Quoted 1 line

Quoted 1 line · On 17.11.15 at 10:40, <[email protected]> wrote:

From: Bob Moore <[email protected]>

ACPICA commit 72b0b6741990f619f6aaa915302836b7cbb41ac4

One new 64-bit field at the end of the table. FADT version is now 6.

Link https://github.com/acpica/acpica/commit/72b0b674

Signed-off-by Bob Moore <[email protected]>

Signed-off-by Lv Zheng <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

[Linux commit aeb823bbacc2a3aaee29eda5875b58a049fa1f78]

Signed-off-by Shannon Zhao <[email protected]>

Quoted 3 lines

---
 xen/include/acpi/actbl.h | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

So while I applied this one after fixing it up, I'm not going to do any further fixups to later patches I also meant to apply. I realize the fixups may have been necessary because of me applying them in other than the submitted sequence, but then again such general imports from ACPICA/Linux should have been independent of earlier changes. I.e. either earlier patches in the series wrongly touch these headers, or there's a general problem with the series.

Quoted 14 lines

Quoted 1 line

Quoted 1 line · On 17.11.15 at 10:40, <[email protected]> wrote:

From: Bob Moore <[email protected]>

ACPICA commit 72b0b6741990f619f6aaa915302836b7cbb41ac4

One new 64-bit field at the end of the table. FADT version is now 6.

Link https://github.com/acpica/acpica/commit/72b0b674

Signed-off-by Bob Moore <[email protected]>

Signed-off-by Lv Zheng <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

[Linux commit aeb823bbacc2a3aaee29eda5875b58a049fa1f78]

Signed-off-by Shannon Zhao <[email protected]>

Quoted 3 lines

---
 xen/include/acpi/actbl.h | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

So while I applied this one after fixing it up, I'm not going to do any further fixups to later patches I also meant to apply. I realize the fixups may have been necessary because of me applying them in other than the submitted sequence, but then again such general imports from ACPICA/Linux should have been independent of earlier changes. I.e. either earlier patches in the series wrongly touch these headers, or there's a general problem with the series.

Quoted 1 line

Quoted 1 line · On 17.11.15 at 10:40, <[email protected]> wrote:

From: Bob Moore <[email protected]>

ACPICA commit 72b0b6741990f619f6aaa915302836b7cbb41ac4

One new 64-bit field at the end of the table. FADT version is now 6.

Link https://github.com/acpica/acpica/commit/72b0b674

Signed-off-by Bob Moore <[email protected]>

Signed-off-by Lv Zheng <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

[Linux commit aeb823bbacc2a3aaee29eda5875b58a049fa1f78]

Signed-off-by Shannon Zhao <[email protected]>

---
 xen/include/acpi/actbl.h | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

From: Shannon Zhao <[email protected]>

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, but for Xen it needs FADT hypervisor_id introduced by ACPI 6.0 to tell Dom0 that it runs on Xen hypervisor, so we will check the version and only parse FADT table with version >= 6.0.

If firmware provides ACPI tables with ACPI version less than 6.0, OS will be messed up with those information, so disable ACPI if we get an FADT table with version less that 6.0.

Signed-off-by Hanjun Guo <[email protected]>

Signed-off-by Naresh Bhat <[email protected]>

Signed-off-by Parth Dixit <[email protected]>

Signed-off-by Shannon Zhao <[email protected]>

---
 xen/arch/arm/acpi/boot.c   | 31 +++++++++++++++++++++++++++++++
 xen/arch/arm/acpi/lib.c    | 12 ++++++++++++
 xen/include/asm-arm/acpi.h |  9 +++++++++
 3 files changed, 52 insertions(+)

xen/arch/arm/acpi/boot.c +10 -0

index ad51afc..0fabe7d 100644
@@ -27,9 +27,33 @@
 
 #include <xen/init.h>
 #include <xen/acpi.h>
+#include <xen/errno.h>
+#include <acpi/actables.h>
+#include <xen/mm.h>
 
 #include <asm/acpi.h>
 
+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 revision, and there
+     * is a minor revision of FADT which was introduced by ACPI 6.0,