[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


 


Rackspace

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