From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Xen 4.0 crashes with pvops kernel Date: Thu, 24 Jun 2010 10:29:34 +0100 Message-ID: <4C23257E.4070308@goop.org> 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=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: 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" , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 06/15/2010 02:57 PM, Jan Beulich wrote: > 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(). > So that ioremap() itself will return an error if Xen prevents a mapping? > 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? > If the pte has _PAGE_IO set (which all ioremap ptes should), then it will call xen_set_iomap_pte. This can't fail (not return code), so if the hypercall fails then it will leave it unmapped. It should at least print a warn-on in that case. J