RE: [PATCH]HVM E820 Table cleanup

RE: [PATCH]HVM E820 Table cleanup

[Li, Xin B]

>> We found E820 table miss report the ACPI NVS/Data information which
>> trigger the Windows HCT test complain, attached please review for the
>> cleanup patch.
>> 
>> Signed-off-by: Xin Li <xin.b.li@intel.com>
>> Signed-off-by: Winston Wang <winston.l.wang@intel.com>
>
>Apart from adding a page-size ACPI region in low memory, this patch
>*removes* thirteen pages from the top of memory. Was that 
>region just bogus?
>

Yes, it's bogus :-(

>The hvmloader code which copies the ACPI tables only checks 
>that the tables
>will fit into 0xEA000-0xEFFFF. Shouldn't e820 declare a region 
>of that size,
>therefore (i.e., 0x50000, not 0x10000)?
>

According to ACPI spec, OS may use e820 ACPI_DATA region as RAM after OS
boots up (but acturally Linux doesn't use it).
But for memory ACPI tables reside, OS can not use like that.
-Xin

Re: [PATCH]HVM E820 Table cleanup

[Gerd Hoffmann]

  Hi,

> According to ACPI spec, OS may use e820 ACPI_DATA region as RAM after OS
> boots up (but acturally Linux doesn't use it).
> But for memory ACPI tables reside, OS can not use like that.

On a related topic: how about the e820 tables itself?  Right now they
are at 0x00090000 (E820_MAP_PAGE), that is within a region listed as
normal RAM, which looks wrong ...

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: [PATCH]HVM E820 Table cleanup

[Keir Fraser]

On 24/10/06 10:50, "Gerd Hoffmann" <kraxel@suse.de> wrote:

>> According to ACPI spec, OS may use e820 ACPI_DATA region as RAM after OS
>> boots up (but acturally Linux doesn't use it).
>> But for memory ACPI tables reside, OS can not use like that.
> 
> On a related topic: how about the e820 tables itself?  Right now they
> are at 0x00090000 (E820_MAP_PAGE), that is within a region listed as
> normal RAM, which looks wrong ...

They get copied to 0xe0000 by rombios before the guest OS ever runs. The
early start-of-day RAM map in the low 1MB (as seen by the builder and by
hvmloader) does not really correspond to the contents of the e820 table.
It's arguable that it would be less confusing for rombios (or even
hvmloader) to generate the e820 table.

 -- Keir

[PATCH]HVM E820 Table cleanup

[Wang, Winston L]

[-- Attachment #1: Type: text/plain, Size: 259 bytes --]

We found E820 table miss report the ACPI NVS/Data information which 
trigger the Windows HCT test complain, attached please review for the
cleanup patch.

Signed-off-by: Xin Li <xin.b.li@intel.com>
Signed-off-by: Winston Wang <winston.l.wang@intel.com>

[-- Attachment #2: hvm_e820_acpi.patch --]
[-- Type: application/octet-stream, Size: 2622 bytes --]

diff -r f052ccc0cc26 tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c	Mon Sep 25 14:11:22 2006 +0100
+++ b/tools/libxc/xc_hvm_build.c	Wed Sep 27 10:39:48 2006 -0700
@@ -17,7 +17,6 @@
 #include <xen/hvm/e820.h>
 
 #define HVM_LOADER_ENTR_ADDR  0x00100000
-
 static int
 parseelfimage(
     char *elfbase, unsigned long elfsize, struct domain_setup_info *dsi);
@@ -82,15 +81,16 @@
     e820entry[nr_map].type = E820_IO;
     nr_map++;
 
+    e820entry[nr_map].addr = 0xEA000;
+    e820entry[nr_map].size = 0x01000;
+    e820entry[nr_map].type = E820_ACPI;
+    nr_map++;
+
     e820entry[nr_map].addr = 0xF0000;
     e820entry[nr_map].size = 0x10000;
     e820entry[nr_map].type = E820_RESERVED;
     nr_map++;
 
-/* ACPI data: 10 pages. */
-#define ACPI_DATA_PAGES     10
-/* ACPI NVS: 3 pages.   */
-#define ACPI_NVS_PAGES      3
 /* buffered io page.    */
 #define BUFFERED_IO_PAGES   1
 /* xenstore page.       */
@@ -102,36 +102,13 @@
     /* Most of the ram goes here */
     e820entry[nr_map].addr = 0x100000;
     e820entry[nr_map].size = mem_size - 0x100000 - PAGE_SIZE *
-                                                (ACPI_DATA_PAGES +
-                                                 ACPI_NVS_PAGES +
-                                                 BUFFERED_IO_PAGES +
+                                                (BUFFERED_IO_PAGES +
                                                  XENSTORE_PAGES +
                                                  SHARED_IO_PAGES);
     e820entry[nr_map].type = E820_RAM;
     nr_map++;
 
     /* Statically allocated special pages */
-
-    /* For ACPI data */
-    e820entry[nr_map].addr = mem_size - PAGE_SIZE *
-                                        (ACPI_DATA_PAGES +
-                                         ACPI_NVS_PAGES +
-                                         BUFFERED_IO_PAGES +
-                                         XENSTORE_PAGES +
-                                         SHARED_IO_PAGES);
-    e820entry[nr_map].size = PAGE_SIZE * ACPI_DATA_PAGES;
-    e820entry[nr_map].type = E820_ACPI;
-    nr_map++;
-
-    /* For ACPI NVS */
-    e820entry[nr_map].addr = mem_size - PAGE_SIZE *
-                                        (ACPI_NVS_PAGES +
-                                         BUFFERED_IO_PAGES +
-                                         XENSTORE_PAGES +
-                                         SHARED_IO_PAGES);
-    e820entry[nr_map].size = PAGE_SIZE * ACPI_NVS_PAGES;
-    e820entry[nr_map].type = E820_NVS;
-    nr_map++;
 
     /* For buffered IO requests */
     e820entry[nr_map].addr = mem_size - PAGE_SIZE *

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH]HVM E820 Table cleanup

[Keir Fraser]

On 14/10/06 1:01 am, "Wang, Winston L" <winston.l.wang@intel.com> wrote:

> We found E820 table miss report the ACPI NVS/Data information which
> trigger the Windows HCT test complain, attached please review for the
> cleanup patch.
> 
> Signed-off-by: Xin Li <xin.b.li@intel.com>
> Signed-off-by: Winston Wang <winston.l.wang@intel.com>

Apart from adding a page-size ACPI region in low memory, this patch
*removes* thirteen pages from the top of memory. Was that region just bogus?

The hvmloader code which copies the ACPI tables only checks that the tables
will fit into 0xEA000-0xEFFFF. Shouldn't e820 declare a region of that size,
therefore (i.e., 0x50000, not 0x10000)?

 -- Keir