>>> On 15.06.10 at 14:35, Cris Daniluk <cris.daniluk@xxxxxxxxx> wrote:
> (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x03] address[0xfec80000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 3, version 32, address 0xfec80000, GSI 24-47
As suspected, there is an IO-APIC at that address, which Dom0 must
not access.
Booting with ACPI debugging enabled won't get you the needed
information; you'd rather need to use the acpidump utility to obtain
blobs containing the various ACPI tables, out of which the DSDT
(and maybes SSDTs) are what likely contains the problematic uses.
But even if we verify that the references come from some ACPI
method(s), likely the only way to address this is to fix the kernel
side error handling.
Keir, assuming these are reads only, would it make sense to permit
Dom0 to map the IO-APIC space read-only? Perhaps even
transparently converting writeable mappings to read-only ones
(since drivers/acpi/osl.c tries to establish writeable mappings
irrespective of the actual needs)? The obvious danger in doing
so is that going forward there may appear fields in that page
reads of which aren't side effect free...
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home