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: Wed, 09 Mar 2011 11:07:49 +0000 Message-ID: References: <4D776A320200007800035752@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4D776A320200007800035752@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 , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 09/03/2011 10:53, "Jan Beulich" wrote: > This patch set makes it so that not only the offending BUG() gets > eliminated, but also properly propagates the error to the guest, > so that the latter can take action (which will itself require quite > some changes to prevent crashing the guest in that situation, > particularly where utilizing Xen's writeable page table support). Presumably this is from shattering superpage mappings when per-page cache attributes change in response to a guest mapping a page with, for example, non-WB attributes? 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. An alternative might be to replace the x86_64 1:1 mapping with a mapping cache. Could be transparent, demand faulting in parts of the 1:1 mapping. But that seems a pain, possibly difficult for demand faults from IRQ context, when the alternative is only a 0.2% space cost. -- Keir