[U-Boot] [PATCH v8 24/30] efi: Adjust memory handling to support sandbox

Simon Glass sjg at chromium.org
Thu Jun 21 19:45:28 UTC 2018


Hi Alex,

On 21 June 2018 at 04:14, Alexander Graf <agraf at suse.de> wrote:
> On 06/21/2018 04:01 AM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 18 June 2018 at 09:03, Alexander Graf <agraf at suse.de> wrote:
>>>
>>> On 06/18/2018 04:08 PM, Simon Glass wrote:
>>>>
>>>> Sandbox does not support direct casts between addresses and pointers,
>>>> since it uses an emulated RAM buffer rather than directly using host
>>>> RAM.
>>>>
>>>> The current EFI code uses an integer type for addresses, but treats them
>>>> like pointers.
>>>>
>>>> Update the code to maintain a (reasonably) clear separation between the
>>>> two, so that sandbox can work.
>>>>
>>>> Unfortunately there remains an inconsistency between the arguments of
>>>> allocate_pages() and allocate_pool(). One takes an address and one takes
>>>> a pointer. Partly this seems to be defined by the boot services API
>>>> itself
>>>> but it would be fairly easy to update the functions in efi_memory.c to
>>>> be
>>>> consistent. However, this is a larger change and needs discussion.
>>>>
>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>>
>>>
>>> This also seems to be fallout of a misinterpretation of the API :)
>>
>> Well I suppose it's not important.
>>
>> But AllocatePages() returns an address, but AllocatePool() returns a
>> pointer. I'm not sure why?
>
>
> AllocatePages returns a pointer.

It is declared:

IN OUT EFI_PHYSICAL_ADDRESS *Memory

So it returns an address, a EFI_PHYSICAL_ADDRESS, which is a uint64_t,
which is an address, not a pointer. This is how it is used in U-Boot
too.

The fact that it is declared as EFI_PHYSICAL_ADDRESS * is simply so it
can return a value. That is how things work in C. You cannot return a
value in an arg unless you make that are a pointer.

Regards,
Simon


More information about the U-Boot mailing list