xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: keir <keir@xen.org>, tim <tim@xen.org>,
	xen-devel <xen-devel@lists.xen.org>,
	Roy Franz <roy.franz@linaro.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Fu Wei <fu.wei@linaro.org>
Subject: Re: [PATCH V4 03/15] create arch functions to get and process EFI memory map.
Date: Fri, 12 Sep 2014 10:56:49 +0100	[thread overview]
Message-ID: <5412DF810200007800034688@mail.emea.novell.com> (raw)
In-Reply-To: <1410515144.567.25.camel@kazak.uk.xensource.com>

>>> On 12.09.14 at 11:45, <Ian.Campbell@citrix.com> wrote:
> On Fri, 2014-09-12 at 08:07 +0100, Jan Beulich wrote:
>> >>> On 11.09.14 at 19:40, <roy.franz@linaro.org> wrote:
>> > On Thu, Sep 11, 2014 at 7:11 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>>> On 10.09.14 at 02:51, <roy.franz@linaro.org> 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.

Jan

  reply	other threads:[~2014-09-12  9:56 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-10  0:51 [PATCH V4 00/15] arm64 EFI stub Roy Franz
2014-09-10  0:51 ` [PATCH V4 01/15] move x86 EFI boot code to common/efi Roy Franz
2014-09-11 13:50   ` Jan Beulich
2014-09-11 17:16     ` Roy Franz
2014-09-12  6:55       ` Jan Beulich
2014-09-10  0:51 ` [PATCH V4 02/15] Move x86 specific funtions/variables to arch header Roy Franz
2014-09-11 14:03   ` Jan Beulich
2014-09-11 17:33     ` Roy Franz
2014-09-12  7:04       ` Jan Beulich
2014-09-12  9:43         ` Ian Campbell
2014-09-12  9:53           ` Jan Beulich
2014-09-12  9:58             ` Ian Campbell
2014-09-12 16:52         ` Roy Franz
2014-09-10  0:51 ` [PATCH V4 03/15] create arch functions to get and process EFI memory map Roy Franz
2014-09-11 14:11   ` Jan Beulich
2014-09-11 17:40     ` Roy Franz
2014-09-12  7:07       ` Jan Beulich
2014-09-12  9:45         ` Ian Campbell
2014-09-12  9:56           ` Jan Beulich [this message]
2014-09-12 10:23             ` Ian Campbell
2014-09-12 10:35               ` Jan Beulich
2014-09-12 17:01                 ` Roy Franz
2014-09-10  0:51 ` [PATCH V4 04/15] Add architecture functions for pre/post ExitBootServices Roy Franz
2014-09-11 14:13   ` Jan Beulich
2014-09-11 17:44     ` Roy Franz
2014-09-12  7:08       ` Jan Beulich
2014-09-12  9:46         ` Ian Campbell
2014-09-12  9:58           ` Jan Beulich
2014-09-12 16:57             ` Roy Franz
2014-09-15  8:47               ` Jan Beulich
2014-09-10  0:51 ` [PATCH V4 05/15] Add efi_arch_cfg_file() to handle arch specific cfg file fields Roy Franz
2014-09-11 14:16   ` Jan Beulich
2014-09-11 18:11     ` Roy Franz
2014-09-12  7:10       ` Jan Beulich
2014-09-10  0:51 ` [PATCH V4 06/15] Add efi_arch_handle_cmdline() for processing commandline Roy Franz
2014-09-11 14:22   ` Jan Beulich
2014-09-11 18:24     ` Roy Franz
2014-09-10  0:51 ` [PATCH V4 07/15] Move x86 specific video and disk probing code Roy Franz
2014-09-11 14:26   ` Jan Beulich
2014-09-11 18:30     ` Roy Franz
2014-09-12  7:12       ` Jan Beulich
2014-09-10  0:51 ` [PATCH V4 08/15] Add efi_arch_memory() for arch specific memory setup Roy Franz
2014-09-11 14:27   ` Jan Beulich
2014-09-10  0:51 ` [PATCH V4 09/15] Add arch specific module handling to read_file() Roy Franz
2014-09-11 14:40   ` Jan Beulich
2014-09-10  0:52 ` [PATCH V4 10/15] Add SMBIOS and runtime services setup arch functions Roy Franz
2014-09-11 14:44   ` Jan Beulich
2014-09-11 22:03     ` Roy Franz
2014-09-11 23:41       ` Stefano Stabellini
2014-09-12  7:14       ` Jan Beulich
2014-09-12 16:24         ` Roy Franz
2014-09-10  0:52 ` [PATCH V4 11/15] Add several misc. arch functions for EFI boot code Roy Franz
2014-09-11 14:45   ` Jan Beulich
2014-09-10  0:52 ` [PATCH V4 12/15] Add efi_arch_use_config_file() function to control use of config file Roy Franz
2014-09-11 14:49   ` Jan Beulich
2014-09-11 23:54     ` Stefano Stabellini
2014-09-12  7:15       ` Jan Beulich
2014-09-12 16:30         ` Roy Franz
2014-09-10  0:52 ` [PATCH V4 13/15] add arm64 cache flushing code from linux v3.16 Roy Franz
2014-09-10  0:52 ` [PATCH V4 14/15] Update libfdt to v1.4.0 Roy Franz
2014-09-10  0:52 ` [PATCH V4 15/15] Add ARM EFI boot support Roy Franz
2014-09-11 14:53   ` Jan Beulich
2014-09-11 22:26     ` Roy Franz
2014-09-12  7:17       ` Jan Beulich
2014-09-12  0:49   ` Stefano Stabellini
2014-09-12  3:21     ` Roy Franz
2014-09-12 17:41       ` Stefano Stabellini
2014-09-12 17:50         ` Roy Franz
2014-09-12 17:55           ` Stefano Stabellini
2014-09-22 11:13             ` Ian Campbell
2014-09-23 12:39               ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5412DF810200007800034688@mail.emea.novell.com \
    --to=jbeulich@suse.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=fu.wei@linaro.org \
    --cc=keir@xen.org \
    --cc=roy.franz@linaro.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).