Re: [Xen-devel] [PATCH v2 0/4] xen: arm: various improvements to boot time page table handling

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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

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