[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 10/10] xen: arm: Use a direct mapping of RAM on arm64
On Tue, 2013-06-25 at 16:39 +0100, Julien Grall wrote: > > +#else /* CONFIG_ARM_64 */ > > +static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size) > > +{ > > + paddr_t ram_start = ~0; > > + paddr_t ram_end = 0; > > + int bank; > > + unsigned long xenheap_pages = 0; > > + unsigned long dtb_pages; > > + > > + /* > > + * TODO: only using the first RAM bank for now. The heaps and the > > + * frame table assume RAM is physically contiguous. > > + */ > > > I think this comment can be removed. Yes, thanks. > > + setup_frametable_mappings(ram_start, ram_end); > > > What happen if the RAM is not contiguous? Do we have hole in the frametable? Currently, yes. My intention was to live with this for now and to eventually implement something like x86's pfn compression scheme (the pdx_t type which you'll see in various places. > BTW, I was looking to the mfn_valid function and I think the function > can possibly consider device memory region as valid MFN. Is it the right > behaviour? I think so, an mfn is just a machine frame number and it is valid whether the thing at the address is RAM or something else. I think the ARM behaviour is consistent with the x86 implementation (called __mfn_valid), which just checks against max_page plus some changes related to the pdx compression scheme. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |