WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] [PATCH] VP model doesn't pass the whole ACPI table

On Wed, 2006-06-07 at 16:40 +0900, Kouya SHIMURA wrote:
> Hi Alex,
> 
> Please take a look at attached log messages of PRIMEQUEST.
> (I slightly changed the output format (MB->KB) in print_md@xxxxxxxx)
> 
> The following line looks bizarre.
> (XEN) domain mem: type= 6, attr=0x8000000000000009, 
> range=[0x000000007fcbe000-0x000000007fcbe000) (0KB)
> 
> type=6 means EFI_RUNTIME_SERVICES_DATA.  ACPI tables start at
> 0x7fcbe000 and it is correct. But its size is 0!
> 
> Though PRIMEQUEST might violate the EFI spec, I wish that dom0 can
> read the same physical memory as the linux do.

Hi Kouya,

   Yes, I do too.  Does the PRIMEQUEST have a memmap command from the
EFI shell that reports the original MDT as reported by firmware?  I
notice this range reports both WB and UC attributes.  I wonder if the
zero size is a result of the efi trim_top/trim_bottom calls zero-ing out
that range to prevent attribute aliasing.  On my system the ACPI reclaim
memory is only reported with the UC attribute and therefore does not get
trimmed.  If this is the case, the solution might be to have the
trimming functions remove the WB attribute instead of reducing the range
to zero.  I'd certainly prefer to add that kind of special case than to
walk the ACPI tables by hand.  Thanks,

        Alex
-- 
Alex Williamson                             HP Open Source & Linux Org.


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