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 14:20:39 +0100 Message-ID: <4C179A47020000780000683A@vpn.id2.novell.com> References: <4C17932F0200007800006821@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:56, Keir Fraser wrote: > On 15/06/2010 13:50, "Jan Beulich" wrote: >=20 >> 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. >>=20 >> 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... >=20 > Well, how come it works with other Linux kernels -- presumably they have > some extra error handling in the ACPI subsystem? Shouldn't that just be > added to this kernel? I'm rather suspecting there's new code (compared to 2.6.18) that's lacking proper error handling, though I didn't look in detail so far. Hmm, looking a little more closely it seems they indeed try to write to that space - this we for sure can't allow. I'll see if I can follow the code path (unfortunately the stack trace is an imprecise one). Cris, seeing DSDT and SSDTs from that system would surely be helpful. Jan