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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel