[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0/5] x86: properly propagate errors to hypercall callee


  • To: Jan Beulich <JBeulich@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Wed, 09 Mar 2011 11:07:49 +0000
  • Cc:
  • Delivery-date: Wed, 09 Mar 2011 03:09:59 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=d+1XhIRhlCSnKHQUxkboNjhJthHSGL2BIk/WdBgk1RD6v6MH9/YHdKU0aqKgr+sweR c8OHrgd6q6dHBZ/cvKp1zAb6+gaTazLEO/bPvmEyjwwpjCzGf/JUxAYYidmuU/lKrZRP cvavi0soQuDgSPLteHEx9ndXf3Kgpy5yW3jJ4=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcveSjne7KPd6hKm6UKAdOT4kN64xQ==
  • Thread-topic: [Xen-devel] [PATCH 0/5] x86: properly propagate errors to hypercall callee

On 09/03/2011 10:53, "Jan Beulich" <JBeulich@xxxxxxxxxx> 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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.