>>> On 29.06.10 at 05:19, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Mon, 28 Jun 2010 10:21:09 +0100
> "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> For your issue, I rather wonder why dma_reserve reaches this high
>> a value only with the particular dom0_mem= you're stating. Did
>> you check where those reservations come from, and how they
>> differfrom when using smaller or larger dom0_mem= values?
>
> Yeah, I checked two values which boot fine:
> dom0_mem = 500M
> reserve_bootmem_generic(phys = 0, len = e91000)
> if (phys+len <= MAX_DMA_PFN*PAGE_SIZE)
> dma_reserve += len / PAGE_SIZE;
>
> dom0_mem = 930M
> reserve_bootmem_generic(phys = 0, len = 1040000)
>
> with dom0_mem = 830M, failing to boot:
> reserve_bootmem_generic(phys = 0, len = fdb000)
So it's the kernel space reservation that's hitting you (and it may
well be that this also triggered us to #ifdef out that code - it's
just been too long ago to recall). Clearly the size of the initrd
shouldn't get accounted to dma_reserve, nor should the p2m
table's initial space. Accounting the kernel image (or at least the
permanent portions thereof) would seem correct otoh.
> So, now that I've stumbled on this, I'm confused why the PAGE_OFFSET+
> VAs, ie, gpfns 0 - 16M, are not mapped to MFNs below 16M? Would this not
> be needed for ISA DMA?
There's not support for ISA DMA in Xen (CONFIG_ISA depends on
!X86_XEN and all DMA channels get absorbed close to the end of
setup_arch()).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home