From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [VTD] 1:1 mapping for dom0 exhausts xenheap on x86/32 with 4G memory Date: Fri, 28 Sep 2007 07:41:55 +0100 Message-ID: References: <08DF4D958216244799FC84F3514D70F00ABA9C@pdsmsx415.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <08DF4D958216244799FC84F3514D70F00ABA9C@pdsmsx415.ccr.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: "Han, Weidong" , xen-devel@lists.xensource.com Cc: "Kay, Allen M" List-Id: xen-devel@lists.xenproject.org alloc_domheap_page() instead of alloc_xenheap_page(), and use map_domain_page() to get temporary mappings when you need them. This costs nothing on x86/64, where all memory is permanently mapped. Or it is *very* reasonable to only support vt-d on x86/64 hypervisor. That's the configuration we care about by far the most, since 32-bit guests run fine on a 64-bit hypervisor, and of course all vt-d systems will be 64-bit capable. -- Keir On 28/9/07 06:26, "Han, Weidong" wrote: > xenheap size is 9M on x86/32 xen, it's not enough to setup 1:1 page > tables for dom0. It causes dom0 cannot boot successfully. Setup 1:1 page > table in domheap still might be a problem since the thinking is to use > the same 1:1 page table for both dom0 and PV domains. Currently I think > of two options: 1) go back to original method, that's to say setup page > table dynamically for dom0; 2) increase xenheap size on x86/32. How do > you think about? Thanks. > > Weidong