All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@citrix.com>
To: Iurii Konovalenko <iurii.konovalenko@globallogic.com>,
	Julien Grall <julien.grall@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Julien Grall <julien.grall@linaro.org>,
	tim@xen.org, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH v1 1/2] arm: Add ability to relocate Xen in over 4GB space
Date: Fri, 10 Apr 2015 15:25:40 +0100	[thread overview]
Message-ID: <5527DD64.5040206@citrix.com> (raw)
In-Reply-To: <CABc08zJ0L_jPLfwgDqn6BbmmykqgEF8m2OecWbiSamSH_=LRxA@mail.gmail.com>

On 10/04/15 14:58, Iurii Konovalenko wrote:
> Hi, Julien!

Hi Iurii,

> On Wed, Apr 8, 2015 at 7:05 PM, Julien Grall <julien.grall@citrix.com> wrote:
> 
>> The virtualization extension requires LPAE. Any reason to make this
>> optional?
> I agree with you - there is no real reason to make it optional. I will
> rework patch
> to include functionality without any flags by default.

Before doing a such change, I'd like the point of view of Stefano or Ian
on this patch.

>>> +#ifdef ARM32_RELOCATE_OVER_4GB
>>> +        ldr   r1, =_start
>>> +        sub r4, r1
>>> +        add r4, #BOOT_RELOC_VIRT_START
>>> +#endif
>>
>> This chunk need some comment in order to explain what it's doing.
>>
>> AFAIU the resulting value in r4, will be exactly the same as  "ldr r4,
>> =init_ttbr".
> Not exactly. Virtual address of _start is 0x00200000, but
> #BOOT_RELOC_VIRT_START is 0x00800000.
> This part of code is needed to get value, that was "stashed by CPU 0" in
> relocated copy of Xen when secondary CPUs run in non-relocated.

And the reloc Xen is mapped by setup_page_tables in mm.c, right?

If so, this definitely need a comment explaining why and how it works.
Because you are relying on multiple things in the code.
	- 1:1 mapping is not overlapped (see my comment on the previous mail)
	- reloc Xen will never overlap the boot Xen (for instance we could
decide that Xen doesn't need to be relocated).
	- After relocation, Xen is still modifying the boot page table (clean
them) but hopefully it's only the relocated version

This is making the code in setup_page_tables quite difficult to
understand now.

>>> +    xen_relocation_offset = __pa(init_secondary) - xen_relocation_offset;
>>
>> The Xen may be relocated below the boot copy. So the final result may be
>> negative.
> This offset is used to get physical address of non-relocated variables
> and write there values.
> If it is negative, then calculating non-relocated address gives bigger
> number (substraction of  negative value).
> In addition, it's hard to imagine when it can be negative if we take
> highest region of highest memory bank.

Simple, the board has all the memory banks below 4G and Xen has been
loaded by the bootloader at a very high address.

Regards,

-- 
Julien Grall

  reply	other threads:[~2015-04-10 14:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-08 12:36 [PATCH v1 0/2] relocate Xen in over 4GB space for arm32 Iurii Konovalenko
2015-04-08 12:36 ` [PATCH v1 1/2] arm: Add ability to relocate Xen in over 4GB space Iurii Konovalenko
2015-04-08 16:05   ` Julien Grall
2015-04-08 17:24     ` Andrii Anisov
2015-04-08 17:25       ` Andrii Anisov
2015-05-08 16:02       ` Ian Campbell
2015-04-10 13:58     ` Iurii Konovalenko
2015-04-10 14:25       ` Julien Grall [this message]
2015-04-14 11:00         ` Ian Campbell
2015-04-10 14:38     ` Andrii Anisov
2015-04-10 14:49       ` Julien Grall
2015-04-16 12:59         ` Ian Campbell
2015-04-15 16:29     ` Ian Campbell
2015-04-15 16:41   ` Ian Campbell
2015-04-08 12:36 ` [PATCH v1 2/2] arm: skip verifying memory continuity Iurii Konovalenko
2015-04-08 16:20   ` Julien Grall

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=5527DD64.5040206@citrix.com \
    --to=julien.grall@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=iurii.konovalenko@globallogic.com \
    --cc=julien.grall@linaro.org \
    --cc=stefano.stabellini@eu.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 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.