[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 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |