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

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Ian,

On 17/06/15 11:26, Ian Campbell wrote:
> 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"

My usual mistake :/

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

The init section is located in the middle of the binary. We may be able
to get a larger region by including the other section (data, arch,...).
Although, I don't think it worth to do it now, the default size of the
grant is 128KB and the text section is 300KB.

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

Ok. I will resend a new version.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel