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

Re: [Xen-devel] [PATCH V4 03/15] create arch functions to get and process EFI memory map.



On Fri, Sep 12, 2014 at 3:35 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>> On 12.09.14 at 12:23, <Ian.Campbell@xxxxxxxxxx> wrote:
> On Fri, 2014-09-12 at 10:56 +0100, Jan Beulich wrote:
>> >>> On 12.09.14 at 11:45, <Ian.Campbell@xxxxxxxxxx> wrote:
>> > On Fri, 2014-09-12 at 08:07 +0100, Jan Beulich wrote:
>> >> >>> On 11.09.14 at 19:40, <roy.franz@xxxxxxxxxx> wrote:
>> >> > On Thu, Sep 11, 2014 at 7:11 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> >> >>>>> On 10.09.14 at 02:51, <roy.franz@xxxxxxxxxx> wrote:
>> >> >>> @@ -1171,67 +1169,12 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
>
>> > *SystemTable)
>> >> >>>Â Â Â Â Â }
>> >> >>>Â Â Â }
>> >> >>>
>> >> >>> -Â Â efi_bs->GetMemoryMap(&efi_memmap_size, NULL, &map_key,
>> >> >>> -Â Â Â Â Â Â Â Â Â Â Â Â Â&efi_mdesc_size, &mdesc_ver);
>> >> >>> -Â Â mbi.mem_upper -= efi_memmap_size;
>> >> >>> -Â Â mbi.mem_upper &= -__alignof__(EFI_MEMORY_DESCRIPTOR);
>> >> >>> -Â Â if ( mbi.mem_upper < xen_phys_start )
>> >> >>> -Â Â Â Â blexit(L"Out of static memory");
>> >> >>> -Â Â efi_memmap = (void *)(long)mbi.mem_upper;
>> >> >>> -Â Â status = efi_bs->GetMemoryMap(&efi_memmap_size, efi_memmap, &map_key,
>> >> >>> -Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â &efi_mdesc_size, &mdesc_ver);
>> >> >>> -Â Â if ( EFI_ERROR(status) )
>> >> >>> -Â Â Â Â PrintErrMesg(L"Cannot obtain memory map", status);
>> >> >>> +Â Â efi_arch_get_memory_map(&mmap_size, &mmap, &mmap_key,
>> >> >>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â &mmap_desc_size, &mmap_desc_ver);
>> >> >>
>> >> >> The only arch-specific bit here is where to put the map.
>> >> > Yes, but the ARM method of allocating the space can make the map
>> >> > bigger.
>> >
>> > So something which ARM does can make the result of efi_bs->GetMemoryMap
>> > longer? Or are we talking about the bootinfo.mem array?
>>
>> Not having looked at the code, I suppose the issue is with the
>> sequence of
>> - get memory map size
>> - alloc memory for the map
>> - get memory map
>> where the middle step may alter the memory map size. But with any
>> kind of sane allocator it ought to be reasonable to expect it to not
>> grow by more than two entries (if the allocator chooses to take the
>> middle of an existing free block), which could be accounted for up
>> front.
>
> I see, thanks.
>
> Does x86 avoid this by using a static buffer or something? Or by the
> "account for it up front" trick which you mention?

It uses a kind of static buffer.

Jan

Increasing the buffer size should work. ÂI will make it a page size larger, as that is the allocation granularity of the
EFI allocator, and should be generous enough to avoid any problems, while not being excessively large.

Roy

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