From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Xen 4.0 crashes with pvops kernel Date: Tue, 15 Jun 2010 11:15:34 -0400 Message-ID: <20100615151534.GB4901@phenom.dumpdata.com> References: <4C17932F0200007800006821@vpn.id2.novell.com> <4C179A47020000780000683A@vpn.id2.novell.com> <4C17A2F9020000780000688F@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4C17A2F9020000780000688F@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Cris Daniluk , "xen-devel@lists.xensource.com" , Jeremy Fitzhardinge , Keir Fraser List-Id: xen-devel@lists.xenproject.org > >>> Dom0 to map the IO-APIC space read-only? Perhaps even .. snip > 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? Take a look at xen_set_fixmap, which I think is used for most of those special addresses. It is mapped to a null-space for the IO APIC addresses.