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:57:45 +0100 Message-ID: <4C17A2F9020000780000688F@vpn.id2.novell.com> References: <4C17932F0200007800006821@vpn.id2.novell.com> <4C179A47020000780000683A@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: <4C179A47020000780000683A@vpn.id2.novell.com> 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: Cris Daniluk , Jeremy Fitzhardinge Cc: "xen-devel@lists.xensource.com" , Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> On 15.06.10 at 15:20, "Jan Beulich" wrote: >>>> 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? >=20 > 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. >=20 > 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). Actually, that's a difference to non-pv-ops that I strongly believe should be fixed: While in the traditional kernel __direct_remap_pfn_range() is used to establish I/O memory mappings (and hence there is a way to propagate errors), the pv-ops kernel appears to use ioremap_page_range() - just like native - which can only return -ENOMEM (upon page table allocation failure), due to the lack of a return value from set_pte_at(). But then again I must be missing something here, since xen_set_pte_at() falls back to xen_set_pte() if the hypercall it tries first fails, and that one would fault when establishing the mapping, not when trying to first use it. Jeremy? Jan