From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] Enable K8 GART as an IOMMU Date: Wed, 14 Feb 2007 14:51:32 +0000 Message-ID: References: <20070214143305.GB6490@amd64.org> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070214143305.GB6490@amd64.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Uli Meis Cc: xen-devel@lists.xensource.com, "Langsdorf, Mark" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 14/2/07 14:33, "Uli Meis" wrote: > Usually, yes, the BIOS should allocate the aperture. However, on all > systems I've tested on the BIOS allocated only 32MB (probably because > they had no AGP). Sometimes it would even keep the memory location that > was set on the last boot---potentially pointing to usable RAM. > > The patch will only allocate the aperture from RAM if the BIOS reserved > less than 64MB. In that case, it will also make the call to > xen_create_contiguous_region. The memory is lost. There's also a boot > mesage telling people that. Might it typically be possible to find some free space in the hole just below 4GB? I don't believe most BIOSes make effort to keep the RAM hole small. Looking back to the particular approach you have taken, expanding the static argument arrays for this one particular user is not really desirable. It would be better to do a dynamic GFP_ATOMIC allocation in the case that order > MAX_CONTIG_ORDER. We want to avoid that in the general case because GFP_ATOMIC allocations can fail, but this will be happening at start of day when there should be no memory pressure. -- Keir