[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] dom0 boot failure: dma_reserve in reserve_bootmem_generic()



>>> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.