Hi Stefano,
On 06/02/2015 01:36, Stefano Stabellini wrote:
On Wed, 4 Feb 2015, parth.di...@linaro.org wrote:
From: Parth Dixit <parth.di...@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.di...@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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel