From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 0/4] xen: arm: various improvements to
 boot time page table handling
Date: Fri, 18 Jul 2014 17:36:05 +0100
Message-ID: <53C94CF5.7@citrix.com>
References: <1405699899.6419.7.camel@kazak.uk.xensource.com>	<1405700190.6419.10.camel@kazak.uk.xensource.com>
	<1405701051.6419.17.camel@kazak.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1405701051.6419.17.camel@kazak.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>, Julien Grall <julien.grall@linaro.org>, Tim Deegan <tim@xen.org>
List-Id: xen-devel@lists.xenproject.org

On 18/07/14 17:30, Ian Campbell wrote:
> On Fri, 2014-07-18 at 17:16 +0100, Ian Campbell wrote:
>> On Fri, 2014-07-18 at 17:11 +0100, Ian Campbell wrote:
>>> Since v2 I've made it correctly handle being loaded at exactly 2M (so
>>> virt == phys on boot) and made a few cleanups.
>>>
>>> I've also tested with various offsets from the base of RAM:
>>>         0x00200000 (2M)
>>>         0x40000000 (1G)
>>>         0x40200000 (1G+2M)
>>>         0x80000000 (2G)
>>>         0x80400000 (2G+4M)
>>>         0x80401000 (2G+4M+2K)
>>>
>>> On Midway (RAM starts at 0) and XGene (RAM starts at 256G). I think this
>>> covers the interesting cases at each level except the zeroeth where I
>>> have no hardware to test anything other than mappings in slot 0. I also
>>> couldn't test virt==phys on 64 bit since I've no such systems with RAM
>>> at 0.
>> I just realised that I forgot to add the check that head.S fits in 4K.
>> I'll do that in a patch 5/4 shortly.
> On second thoughts... This requires some sort of compile or link time
> error/assertion in either gnu as or ld based on the offset of a symbol
> or size of a section etc. I can't find anything in either manual which
> would allow this to be constructed
>
> So I'm going to punt on this. Right now aem64/head.o is 1824 bytes and
> arm32/head.o is 1920 bytes, so neither are even half way to blowing this
> limit (which is an upper bound since the real limit is the offset of the
> symbol "paging", at 1116 and 1196 bytes respectively).
>
> If someone can come up with a suitable construct then we can revisit
> this.
>
> Ian.

If I understand your problem correctly, it is exactly the same as we do
for the kexec relocation page in x86.

See the bottom of xen/arch/x86/xen.lds.S

~Andrew