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


Re: [Xen-devel] [PATCH] Make AMD GART work as a mini IOMMU [4/4]

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Mark Langsdorf <mark.langsdorf@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Make AMD GART work as a mini IOMMU [4/4]
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Tue, 06 Mar 2007 10:54:58 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 06 Mar 2007 02:54:13 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45ED40FE.76E4.0078.0@xxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acdf3eGOICMhEcvREdueUQAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH] Make AMD GART work as a mini IOMMU [4/4]
User-agent: Microsoft-Entourage/
On 6/3/07 09:22, "Jan Beulich" <jbeulich@xxxxxxxxxx> 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];
> Keir had asked you to not statically bump MAX_CONTIG_ORDER here as a
> minimal acceptance criteria.

Indeed. In fact I think the right answer here is probably to prove a new
steal-memory platform operation which will allocate a chunk of RAM, unmap it
in the hypervisor, and mark it as belonging to the I/O domain. The
clear_kernel_mapping() call is then not needed if the aperture was allocated
by the BIOS (since it will be outside any published RAM area, so Xen will
have carefully not mapped that range) and with a new platform op for the
allocation will not be needed in the fallback case either. Nor would
xen_create_contiguous_region() need to be modified.

Whatever, with 3.0.5 just a few weeks away I don't think a complex patchset
this far from completion has a chance of making it. It's way too scary.

 -- Keir

Xen-devel mailing list

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