[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 1/3] xen/x86: split boot trampoline into permanent and temporary part



>>> On 23.03.17 at 17:44, <jgross@xxxxxxxx> wrote:
> On 23/03/17 16:04, Jan Beulich wrote:
>>>>> On 23.03.17 at 07:25, <jgross@xxxxxxxx> wrote:
>>> --- a/xen/arch/x86/xen.lds.S
>>> +++ b/xen/arch/x86/xen.lds.S
>>> @@ -335,3 +335,5 @@ ASSERT(IS_ALIGNED(__bss_end,        8), "__bss_end 
>>> misaligned")
>>>  
>>>  ASSERT((trampoline_end - trampoline_start) < TRAMPOLINE_SPACE - 
>>> MBI_SPACE_MIN,
>>>      "not enough room for trampoline and mbi data")
>>> +ASSERT((trampoline_boot_start - wakeup_stack_start) >= WAKEUP_STACK_MIN,
>>> +    "wakeup stack too small")
>> 
>> ... use wakeup_stack here too?
> 
> It would work, yes. With my pending patch for releasing the memory of
> the boot-only trampoline code this would look a little bit strange:
> I'd have to free the memory named "wakeup_stack" and the label
> "trampoline_boot_start" would be unused.

Well, the implication from my reply was that trampoline_boot_start
likely can be dropped. Freeing from wakeup_stack onwards seems
quite reasonable, since the stack is the last thing you want to keep.

> In case you'd prefer it I can just place trampoline_boot_start at the
> same location as wakeup_stack_start and free the boot trampoline
> memory by using the next page boundary.

That's an option too. What I'd like to avoid is a mix of things like
in the ASSERT() above - the expression should be in wakeup stack
terms only.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.