>>> On 23.09.16 at 13:35, wrote:
> One early allocator for both platforms would be nice. And I have a feeling
> that this is the Jan's goal. However, I am not going to insist because you
> know ARM platforms better than I. So, I think that Jan should say what is
> his
On Fri, Sep 23, 2016 at 12:42:10PM +0100, Julien Grall wrote:
>
>
> On 23/09/16 12:35, Daniel Kiper wrote:
> >On Fri, Sep 23, 2016 at 12:07:14PM +0100, Julien Grall wrote:
> >>On 23/09/16 11:50, Daniel Kiper wrote:
> >>>Hi Julien,
> >>
> >>Hi Daniel,
> >>
> >>>
> >>>On Thu, Sep 22, 2016 at
On 23/09/16 12:35, Daniel Kiper wrote:
On Fri, Sep 23, 2016 at 12:07:14PM +0100, Julien Grall wrote:
On 23/09/16 11:50, Daniel Kiper wrote:
Hi Julien,
Hi Daniel,
On Thu, Sep 22, 2016 at 06:07:26PM +0100, Julien Grall wrote:
[...]
#ifndef CONFIG_ARM
/* Whole x86 ebmalloc stuff. */
...
On Fri, Sep 23, 2016 at 12:07:14PM +0100, Julien Grall wrote:
> On 23/09/16 11:50, Daniel Kiper wrote:
> >Hi Julien,
>
> Hi Daniel,
>
> >
> >On Thu, Sep 22, 2016 at 06:07:26PM +0100, Julien Grall wrote:
> >
> >[...]
> >
> >>>#ifndef CONFIG_ARM
> >>>/* Whole x86 ebmalloc stuff. */
> >>>...
>
On 23/09/16 11:50, Daniel Kiper wrote:
Hi Julien,
Hi Daniel,
On Thu, Sep 22, 2016 at 06:07:26PM +0100, Julien Grall wrote:
[...]
#ifndef CONFIG_ARM
/* Whole x86 ebmalloc stuff. */
...
#else
void __init free_ebmalloc_unused_mem(void)
{
}
#endif
and then call free_ebmalloc_unused_mem()
Hi Julien,
On Thu, Sep 22, 2016 at 06:07:26PM +0100, Julien Grall wrote:
[...]
> >#ifndef CONFIG_ARM
> >/* Whole x86 ebmalloc stuff. */
> >...
> >#else
> >void __init free_ebmalloc_unused_mem(void)
> >{
> >}
> >#endif
> >
> >and then call free_ebmalloc_unused_mem() from e.g.
>
Hi Daniel,
On 22/09/16 13:07, Daniel Kiper wrote:
On Thu, Sep 22, 2016 at 05:25:46AM -0600, Jan Beulich wrote:
On 22.09.16 at 12:52, wrote:
On Wed, Sep 21, 2016 at 03:42:09AM -0600, Jan Beulich wrote:
On 20.09.16 at 20:45, wrote:
On Tue,
>>> On 22.09.16 at 14:07, wrote:
> On Thu, Sep 22, 2016 at 05:25:46AM -0600, Jan Beulich wrote:
>> >>> On 22.09.16 at 12:52, wrote:
>> > On Wed, Sep 21, 2016 at 03:42:09AM -0600, Jan Beulich wrote:
>> >> >>> On 20.09.16 at 20:45,
On Thu, Sep 22, 2016 at 05:25:46AM -0600, Jan Beulich wrote:
> >>> On 22.09.16 at 12:52, wrote:
> > On Wed, Sep 21, 2016 at 03:42:09AM -0600, Jan Beulich wrote:
> >> >>> On 20.09.16 at 20:45, wrote:
> >> > On Tue, Sep 20, 2016 at 07:46:56AM
>>> On 22.09.16 at 12:52, wrote:
> On Wed, Sep 21, 2016 at 03:42:09AM -0600, Jan Beulich wrote:
>> >>> On 20.09.16 at 20:45, wrote:
>> > On Tue, Sep 20, 2016 at 07:46:56AM -0600, Jan Beulich wrote:
>> >> >>> On 20.09.16 at 12:52,
On Wed, Sep 21, 2016 at 03:42:09AM -0600, Jan Beulich wrote:
> >>> On 20.09.16 at 20:45, wrote:
> > On Tue, Sep 20, 2016 at 07:46:56AM -0600, Jan Beulich wrote:
> >> >>> On 20.09.16 at 12:52, wrote:
[...]
> >> > Do you suggest that I should
>>> On 20.09.16 at 20:45, wrote:
> On Tue, Sep 20, 2016 at 07:46:56AM -0600, Jan Beulich wrote:
>> >>> On 20.09.16 at 12:52, wrote:
>> > On Tue, Sep 20, 2016 at 03:57:19AM -0600, Jan Beulich wrote:
>> >> >>> On 20.09.16 at 11:45,
On Tue, Sep 20, 2016 at 07:46:56AM -0600, Jan Beulich wrote:
> >>> On 20.09.16 at 12:52, wrote:
> > On Tue, Sep 20, 2016 at 03:57:19AM -0600, Jan Beulich wrote:
> >> >>> On 20.09.16 at 11:45, wrote:
> >> > On Mon, Sep 19, 2016 at 09:17:50AM
>>> On 20.09.16 at 12:52, wrote:
> On Tue, Sep 20, 2016 at 03:57:19AM -0600, Jan Beulich wrote:
>> >>> On 20.09.16 at 11:45, wrote:
>> > On Mon, Sep 19, 2016 at 09:17:50AM -0600, Jan Beulich wrote:
>> >> >>> On 19.09.16 at 17:04,
On Tue, Sep 20, 2016 at 03:57:19AM -0600, Jan Beulich wrote:
> >>> On 20.09.16 at 11:45, wrote:
> > On Mon, Sep 19, 2016 at 09:17:50AM -0600, Jan Beulich wrote:
> >> >>> On 19.09.16 at 17:04, wrote:
> >> > On Mon, Sep 19, 2016 at 06:12:35AM
>>> On 20.09.16 at 11:45, wrote:
> On Mon, Sep 19, 2016 at 09:17:50AM -0600, Jan Beulich wrote:
>> >>> On 19.09.16 at 17:04, wrote:
>> > On Mon, Sep 19, 2016 at 06:12:35AM -0600, Jan Beulich wrote:
>> >> >>> On 12.09.16 at 22:18,
On Mon, Sep 19, 2016 at 09:17:50AM -0600, Jan Beulich wrote:
> >>> On 19.09.16 at 17:04, wrote:
> > On Mon, Sep 19, 2016 at 06:12:35AM -0600, Jan Beulich wrote:
> >> >>> On 12.09.16 at 22:18, wrote:
> >> > --- a/xen/arch/x86/setup.c
> >> > +++
On Mon, Sep 19, 2016 at 06:12:35AM -0600, Jan Beulich wrote:
> >>> On 12.09.16 at 22:18, wrote:
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -520,6 +520,8 @@ static void noinline init_done(void)
> >
> > system_state = SYS_STATE_active;
> >
> >
>>> On 19.09.16 at 17:04, wrote:
> On Mon, Sep 19, 2016 at 06:12:35AM -0600, Jan Beulich wrote:
>> >>> On 12.09.16 at 22:18, wrote:
>> > --- a/xen/arch/x86/setup.c
>> > +++ b/xen/arch/x86/setup.c
>> > @@ -520,6 +520,8 @@ static void noinline
>>> On 12.09.16 at 22:18, wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -520,6 +520,8 @@ static void noinline init_done(void)
>
> system_state = SYS_STATE_active;
>
> +free_ebmalloc_unused_mem();
Now that the allocator properly lives
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory
21 matches
Mail list logo