Re: [PATCH] Enable K8 GART as an IOMMU

[Uli Meis <um@amd64.org>]

On Wed 14.02.07 10:04, Keir Fraser wrote:
> On 13/2/07 23:19, "Langsdorf, Mark" <mark.langsdorf@amd.com> wrote:
> 
> >>> /* Protected by balloon_lock. */
> >>> -#define MAX_CONTIG_ORDER 9 /* 2MB */
> >>> +#define MAX_CONTIG_ORDER 16 /* 256MB */
> >>> static unsigned long discontig_frames[1<<MAX_CONTIG_ORDER];
> >>> static multicall_entry_t cr_mcl[1<<MAX_CONTIG_ORDER];
> >> 
> >> This seems dangerous to me.
> > 
> > We need at least 64MB of contiguous memory for the aperture.
> 
> Not that I know anything much about the K8 GART, but I assume the aperture
> is an address range that the GART takes control of and dynamically aliases
> other RAM pages into? Is it necessary to burn 64MB of RAM (which is
> presumably inaccessible when the GART is turned on)? Will the BIOS not
> already have conveniently piointed the aperture into a RAM hole (e.g., just
> below 4GB)?

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.

Concerning the availability of 64MB contiguous RAM: The hypervisor keeps
if dom0_mem is unspecified 1/16th of memory free, which is for >4GB
systems (where one needs a GART) at least 256MB. Therefore, the
allocation should always succeed unless someone's tweaking that
parameter.

Uli