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 22:25:47 +0100 Message-ID: <4C23CD5B.5010409@goop.org> References: <4C17932F0200007800006821@vpn.id2.novell.com> <4C179A47020000780000683A@vpn.id2.novell.com> <4C17A2F9020000780000688F@vpn.id2.novell.com> <4C23257E.4070308@goop.org> <4C235DED0200007800008058@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: <4C235DED0200007800008058@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/24/2010 12:30 PM, Jan Beulich wrote: >> 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. > Yes, that has no way to ioremap real hardware. >> 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. > Currently its implemented as a batched multicall, so the site itself can't check to see if the hypercall worked. I should check that it can actually be called in a batched context. J