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