From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Xen 4.0 crashes with pvops kernel Date: Tue, 15 Jun 2010 13:50:23 +0100 Message-ID: <4C17932F0200007800006821@vpn.id2.novell.com> References: <4C173FCE02000078000066F9@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Cris Daniluk Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> On 15.06.10 at 14:35, Cris Daniluk 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