This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/5] x86: properly propagate errors to hypercall callee
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Wed, 9 Mar 2011 10:10:42 -0500
Cc: Keir Fraser <keir.xen@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 09 Mar 2011 07:11:43 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D779AAE02000078000358FD@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D7770D802000078000357C9@xxxxxxxxxxxxxxxxxx> <C99D34AB.14638%keir.xen@xxxxxxxxx> <4D779AAE02000078000358FD@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
On Wed, Mar 09, 2011 at 02:20:14PM +0000, Jan Beulich wrote:
> >>> On 09.03.11 at 14:44, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> > I wonder what the scope of the problem really is. Mostly this cacheattr
> > stuff applies to memory allocated by a graphics driver I suppose, and
> > probably at boot time in dom0. I wonder how the bug was observed during dom0
> > boot given that Xen chooses a default dom0 memory allocation that leaves
> > enough memory free for a decent-sized dom0 SWIOTLB plus some extra slack on
> > top of that. Any idea how the Xen memory pool happened to be entirely empty
> > at the time radeon drm driver caused the superpage shattering to occur?
> This isn't a boot time problem, it's a run time one (and was reported
> to us as such). The driver does allocations (and cache attribute
> changes) based on user mode (X) demands.

What version of radeon Xorg driver is this with? And what radeon card
was this observed with?

> > I'm not against turning the host crash into a guest crash (which I think is
> > typically what is going to happen, although I suppose at least some Linux
> > driver-related mapping/remapping functions can handle failure) as this might
> > be an improvement when starting up non-dom0 driver domains for example. But
> I'm afraid that's not only a question of driver domains doing such.
> With the addition of !is_hvm_domain() to l1_disallow_mask(), any
> page in a HVM guest that its kernel chooses to make non-WB can
> trigger the BUG() currently.
> And, noting just now, there's then a potential collision between
> the kernel and tools/stubdom (qemu-dm) mapping the page - the
> latter, mapping a page WB, would undo what the guest itself may
> have requested earlier - imo the cache attr adjustment shouldn't
> be done if it's not the owner of the page that's doing the mapping
> (and quite probably the cache attr should be inherited by the non-
> owner, though that raises the problem of updating mappings that
> the non-owner may have established before the owner assigned
> the non-default attr).
> > I think we should consider punting a resource error up to the guest as a
> > very bad thing and still WARN_ON or otherwise log the situation to Xen's own
> > console.
> Hmm, possibly.
> Jan
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list