WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Critical bug: VT-d fault causes disk corruption or Dom0

To: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, "Li, Xin" <xin.li@xxxxxxxxx>, "Li, Haicheng" <haicheng.li@xxxxxxxxx>, "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Critical bug: VT-d fault causes disk corruption or Dom0 kernel panic.
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Sat, 24 Jan 2009 09:15:46 +0000
Cc: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Delivery-date: Sat, 24 Jan 2009 01:16:02 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <57C9024A16AD2D4C97DC78E552063EA35EED2BFD@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acl8Q3YVs3niaMuxT1CPWgfSc0ZGCwAITqg5AAKyJXAAAOMrHgAfiHegABEJqTgAEqyPIAACkS3lAAAS7KQACh68wAAUUrk8
Thread-topic: [Xen-devel] Critical bug: VT-d fault causes disk corruption or Dom0 kernel panic.
User-agent: Microsoft-Entourage/12.15.0.081119
On 23/01/2009 23:40, "Kay, Allen M" <allen.m.kay@xxxxxxxxx> wrote:

> I talked to Joe Cihula about this.  He is suggesting map only the RAM memory
> in E820 table.  This is more secure than map everything below max_page.  We
> can do this for x86_64 and x86_32.  For IA-64, we still map everything below
> max_page as there is no tboot issue.
> 
> What do you think of is approach?

That's an orthogonal issue to avoiding Xen's RAM, but it at least ought to
be easy to do. As long as it doesn't skip any private BIOS buffers for any
devices which are still fully or partially under BIOS control (e.g., via
SMM). But any such buffers above max_page would already be skipped.

I can check in a patch for this as well as a patch to fix xen_in_range().
I'll do both.

 -- Keir



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

<Prev in Thread] Current Thread [Next in Thread>