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