WARNING - OLD ARCHIVES

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

xen-devel

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/11.2.5.060620
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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