[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC 32/35] arm : acpi map xen environment table to dom0



Hi Stefano,

On 06/02/2015 01:36, Stefano Stabellini wrote:
On Wed, 4 Feb 2015, parth.dixit@xxxxxxxxxx wrote:
From: Parth Dixit <parth.dixit@xxxxxxxxxx>

xen environment table contains the grant table address,size and event
channel interrupt information required by dom0.

Signed-off-by: Parth Dixit <parth.dixit@xxxxxxxxxx>
---
  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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.