From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Critical bug: VT-d fault causes disk corruption or Dom0 kernel panic. Date: Sat, 24 Jan 2009 09:15:46 +0000 Message-ID: References: <57C9024A16AD2D4C97DC78E552063EA35EED2BFD@orsmsx505.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <57C9024A16AD2D4C97DC78E552063EA35EED2BFD@orsmsx505.amr.corp.intel.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: "Kay, Allen M" , "Li, Xin" , "Li, Haicheng" , "'xen-devel@lists.xensource.com'" Cc: "Cihula, Joseph" List-Id: xen-devel@lists.xenproject.org On 23/01/2009 23:40, "Kay, Allen M" 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