All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Julien Grall <julien.grall@arm.com>
Cc: Juergen Gross <JGross@suse.com>,
	sstabellini@kernel.org, andrew.cooper3@citrix.com,
	Daniel Kiper <daniel.kiper@oracle.com>,
	cardoe@cardoe.com, pgnet.dev@gmail.com, ning.sun@intel.com,
	david.vrabel@citrix.com, xen-devel@lists.xenproject.org,
	qiaowei.ren@intel.com, gang.wei@intel.com, fu.wei@linaro.org
Subject: Re: [PATCH v9 06/13] efi: create new early memory allocator
Date: Wed, 12 Oct 2016 05:45:27 -0600	[thread overview]
Message-ID: <57FE3E770200007800116A9C@prv-mh.provo.novell.com> (raw)
In-Reply-To: <99c6b4e2-e9fb-d545-c134-435ae685016c@arm.com>

>>> On 11.10.16 at 15:39, <julien.grall@arm.com> wrote:
> Hello Jan,
> 
> On 06/10/16 13:21, Jan Beulich wrote:
>>>>> On 05.10.16 at 20:30, <julien.grall@arm.com> wrote:
>>> On 30/09/2016 02:46, Jan Beulich wrote:
>>>>>>> On 29.09.16 at 23:42, <daniel.kiper@oracle.com> wrote:
>>>>> +#else
>>>>> +static void __init free_ebmalloc_unused_mem(void)
>>>>> +{
>>>>> +}
>>>>> +#endif
>>>>
>>>> Did you build test this for ARM? The function ought to be unused,
>>>> as ...
>>>>
>>>>> @@ -1251,6 +1301,8 @@ void __init efi_init_memory(void)
>>>>>      } *extra, *extra_head = NULL;
>>>>>  #endif
>>>>>
>>>>> +    free_ebmalloc_unused_mem();
>>>>
>>>> ... the whole function here doesn't get built on ARM.
>>>>
>>>> Julien - we're still awaiting your input on general aspects here.
>>>
>>> efi_init_memory would need to be called during Xen boot on ARM. I am not
>>> sure where as I we don't yet have runtime support on ARM.
>>>
>>> Other than that, the patch looks good to me.
>>
>> But that wasn't the question. My goal is to have as little code
>> inside #ifndef CONFIG_ARM as possible, and hence I'd like to have
>> as much of this new code as possible outside of such conditionals.
>> So the question really is whether that alternative approach would
>> be fine with you, or what problems you might see.
> 
> I am not sure to get it. The current approach looks good to me, however, 
> the implementation should not be exposed to ARM until all the TODOs 
> mentioned by Daniel are fixed.

Which is precisely the opposite of what I'm aiming at. Once again:
Don't you think it is desirable to keep the #ifndef CONFIG_ARM
instances to cover as little code as possible? Not all of the named
TODOs really need to be addressed in order to compile most of
what comprises this new allocator; in fact none of them really
needs addressing:
- if the size estimation turns out to low once ARM starts actually
  using this, let's just bump it (perhaps by making it a per-arch
  constant),
- if the section chosen needs to be different (which it really
  shouldn't be), let's simply adjust it,
- as we've already figured there's no need for the stub
  free_ebmalloc_unused_mem() right now anyway.

And then (as another alternative) we have the option of ARM
simply defining EBMALLOC_SIZE to zero for the time being. That
would eliminate the need to actually call free_ebmalloc_unused_mem()
and turn the other two items into non-issues.

> I would be happy to review any patches addressing the TODOs.

This, I'm sorry, gets me to raise another question: When is this
finally going to happen? Shared EFI code was introduced for 4.5,
and we're now looking to release 4.8 still with runtime support
unimplemented on ARM. How much longer is this going to take?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2016-10-12 11:45 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-29 21:42 [PATCH v9 00/13] x86: multiboot2 protocol support Daniel Kiper
2016-09-29 21:42 ` [PATCH v9 01/13] x86: add " Daniel Kiper
2016-09-29 21:42 ` [PATCH v9 02/13] efi: create efi_enabled() Daniel Kiper
2016-09-29 21:42 ` [PATCH v9 03/13] x86: allow EFI reboot method neither on EFI platforms Daniel Kiper
2016-09-29 21:42 ` [PATCH v9 04/13] x86: properly calculate xen ELF end of image address Daniel Kiper
2016-09-30  9:43   ` Jan Beulich
2016-09-29 21:42 ` [PATCH v9 05/13] efi: build xen.gz with EFI code Daniel Kiper
2016-09-29 21:42 ` [PATCH v9 06/13] efi: create new early memory allocator Daniel Kiper
2016-09-30  9:46   ` Jan Beulich
2016-09-30 10:49     ` Daniel Kiper
2016-10-05  7:02     ` Daniel Kiper
2016-10-05 15:45       ` Julien Grall
2016-10-05 18:30     ` Julien Grall
2016-10-06 12:21       ` Jan Beulich
2016-10-11 13:39         ` Julien Grall
2016-10-12 11:45           ` Jan Beulich [this message]
2016-10-12 12:51             ` Julien Grall
2016-10-12 12:59               ` Jan Beulich
2016-10-24  9:03                 ` Daniel Kiper
2016-10-24  9:57                   ` Jan Beulich
2016-11-03 13:48                     ` Daniel Kiper
2016-11-10 10:34                       ` Daniel Kiper
2016-10-31 13:32                 ` Julien Grall
2016-09-29 21:42 ` [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
2016-11-23 18:52   ` Andrew Cooper
2016-11-24 11:08     ` Jan Beulich
2016-11-24 21:44       ` Daniel Kiper
2016-11-25  7:50         ` Jan Beulich
2016-11-30 13:45           ` Daniel Kiper
2016-11-30 13:59             ` Jan Beulich
2016-11-30 17:21               ` Daniel Kiper
2016-11-24 21:31     ` Daniel Kiper
2016-09-29 21:42 ` [PATCH v9 08/13] x86/boot: implement early command line parser in C Daniel Kiper
2016-09-29 21:42 ` [PATCH v9 09/13] x86: change default load address from 1 MiB to 2 MiB Daniel Kiper
2016-09-30 10:02   ` Jan Beulich
2016-09-29 21:42 ` [PATCH v9 10/13] x86/setup: use XEN_IMG_OFFSET instead of Daniel Kiper
2016-09-29 21:42 ` [PATCH v9 11/13] x86: make Xen early boot code relocatable Daniel Kiper
2016-09-29 21:42 ` [PATCH v9 12/13] x86/boot: rename sym_phys() to sym_offs() Daniel Kiper
2016-09-29 21:42 ` [PATCH v9 13/13] x86: add multiboot2 protocol support for relocatable images Daniel Kiper
2016-09-30 10:03   ` Jan Beulich

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=57FE3E770200007800116A9C@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=JGross@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=cardoe@cardoe.com \
    --cc=daniel.kiper@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=fu.wei@linaro.org \
    --cc=gang.wei@intel.com \
    --cc=julien.grall@arm.com \
    --cc=ning.sun@intel.com \
    --cc=pgnet.dev@gmail.com \
    --cc=qiaowei.ren@intel.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.