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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.


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