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

Re: [Xen-devel] [RFC] xen/arm: Find automatically the gnttab region for DOM0



On Fri, 2015-05-22 at 00:38 +0100, Julien Grall wrote:
> Note that on ARM64, the grant table region may be after 4GB (Xen is
> relocated to the highest address) using DOM0 32 bit with short page table
> may not work. Although, I don't think this is a big deal as device may not
> work and/or the RAM is too high due to the 1:1 mapping.

I agree.

> Currently, the grant table region is hardcoded per-platform. When a new
> board is coming up, we have to check the spec in order to find a space
> in the memory layout free. Depending on the platform it may be tedious.
> 
> A good candidate for the gnttab region is the one used by Xen binary as
> some part will never be mapped to the DOM0 address, MMIO are mapped 1:1
> and the RAM will be either:
>     - direct mapped: 1:1 mapping is used => no problem
>     - non direct mapped: Xen always relocates himself as high as possible
>     (limited to 4GB on ARM32) and the RAM bank are filled from the first
>     one. It's very unlikely that the gnttab region will overlap with the
>     RAM. Although for safety a check may be necessary when we will reenable
>     the option.
> 
> Futhermore, there is plenty of space to contain a big gnttab, the default

"Furthermore"

> @@ -1365,6 +1364,36 @@ static void evtchn_fixup(struct domain *d, struct 
> kernel_info *kinfo)
>          panic("Cannot fix up \"interrupts\" property of the hypervisor 
> node");
>  }
>  
> +static void __init find_gnttab_region(struct domain *d,
> +                                      struct kernel_info *kinfo)
> +{
> +    /*
> +     * The region used by Xen on the memory will never be mapped in DOM0
> +     * memory layout. Therefore it can be used for the grant table.
> +     *
> +     * Only use the text section as it's always present and will contain
> +     * enough space for a large grant table
> +     */

Does the fact that XEN_PADDR_ALIGN == 2MB allow us to go larger? I
suspect not because we don't round up the size of the pseudo-bootmodule,
and in any case it'll have init sections in it.

So I agree that the text section is a reasonable choice.

> +    kinfo->gnttab_start = __pa(_stext);
> +    kinfo->gnttab_size = (_etext - _stext) & PAGE_MASK;
> +
> +    /* Make sure the grant table will fit in the region */
> +    if ( (kinfo->gnttab_size >> PAGE_SHIFT) < max_grant_frames )
> +        panic("Cannot find a space for the grant table region\n");
> +
> +#ifdef CONFIG_ARM_32
> +    /*
> +     * The gnttab region must be under 4GB in order to work with DOM0
> +     * using short page table.
> +     * In pratice it's always the case, but be safe

"practice"

I'd include "because Xen is always located below 4GB" in the final
sentence, to explain why in practice this is the case.

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