From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 0/5] x86: properly propagate errors to hypercall callee Date: Fri, 11 Mar 2011 09:45:07 +0000 Message-ID: References: <4D79F89A0200007800035C4D@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4D79F89A0200007800035C4D@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: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 11/03/2011 09:25, "Jan Beulich" wrote: >>>> On 09.03.11 at 12:07, Keir Fraser wrote: >> It seems unfortunate to propagate this to guests. Perhaps we should be >> making a memory pool for Xen's 1:1 mappings, big enough to allow a 4kB >> mapping of every page of RAM in the system, and allocate/free pagetables to >> that pool? The overhead of this would be no more than 0.2% of system memory, >> which seems reasonable to avoid an error case that is surely hard for a >> guest to react to or fix. > > Before starting to look into eventual Linux side changes - do you > then have plans to go that pool route (which would make guest > side recovery attempts pointless)? Not really. I was thinking about having a Linux-style mempool for making allocations more likely to succeed, but it's all a bit ugly really. It'll be interesting to see what you can do Linux-side, and whether it can pass muster for the Linux maintainers. You might at least be able to make the io remappings from device drivers failable (and maybe they are already). -- Keir > Jan >