From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Xen 4.0 crashes with pvops kernel Date: Thu, 24 Jun 2010 12:30:21 +0100 Message-ID: <4C235DED0200007800008058@vpn.id2.novell.com> References: <4C17932F0200007800006821@vpn.id2.novell.com> <4C179A47020000780000683A@vpn.id2.novell.com> <4C17A2F9020000780000688F@vpn.id2.novell.com> <4C23257E.4070308@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4C23257E.4070308@goop.org> 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: Jeremy Fitzhardinge Cc: Cris Daniluk , "xen-devel@lists.xensource.com" , Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> On 24.06.10 at 11:29, Jeremy Fitzhardinge wrote: > 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(). >> =20 >=20 > So that ioremap() itself will return an error if Xen prevents a mapping? Exactly. >> 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? >> =20 >=20 > 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 Ah, right, I apparently looked at the upstream (i.e. DomU-only) implementation rather than your tree. > the hypercall fails then it will leave it unmapped. It should at least > print a warn-on in that case. Yes, that's the minimal requirement I would say. Jan