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.
Anyway, could you apply 10250.patch? It solves a obvious bug.
I attached it again.
FYI.
As for linux, the system which has broken EFI memory map seems to be
rescued by acpi_os_map_memory function in drivers/acpi/osl.c.
Thanks,
Kouya
Alex Williamson writes:
> On Tue, 2006-06-06 at 21:09 +0900, Kouya SHIMURA wrote:
> > Hi Alex,
> >
> > I looked into the code about reference of ACPI table.
> > Single instance seems to be OK but I can't guarantee it.
> > So I wrote ACPI tables walking code.
> > The code isn't a big deal. How about this?
> >
> > Attached patch is work around and not fully tested yet.
> > (It works on Tiger and PRIMEQUEST)
>
> Hi Kouya,
>
> Let's back up one step. Why doesn't the PRIMEQUEST report these
> tables as type EFI_ACPI_RECLAIM_MEMORY? Section 2.3.3 of the EFI spec
> (v1.10) indicates that ACPI tables loaded at boot time must be declared
> as this type in the MDT. If it did, then dom_fw_dom0_passthrough()
> would do this for us much more cleanly. In fact, the
> ASSIGN_DOMAIN_MACH_PAGE calls this patch removes should already be
> redundant because of the passthrough setup.
>
> Could you post the relevant section of the MDT for this system and
> describe the mapping that we're not setting up? Thanks,
>
> Alex
>
> --
> Alex Williamson HP Open Source & Linux Org.
>
PRIMEQUEST.dmesg
Description: Binary data
10250.patch
Description: Binary data
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home