[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |