Re: [Xen-devel] [PATCH ARM v6 00/14] mini-os: initial ARM support

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-07-18 at 09:17 +0100, Thomas Leonard wrote:
> On 17 July 2014 16:55, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Wed, 2014-07-16 at 22:29 +0100, Julien Grall wrote:
> >
> >> > There are two assumptions the code makes that may need changing in the 
> >> > future, but
> >> > which hopefully don't need to hold up this initial support:
> >> >
> >> > - The assumption that the kernel will be loaded at start of RAM + 0x8000.
> >> >
> >> > - The assumption that Xen will mark the GIC address range as device 
> >> > memory.
> >> >    This should probably be fixed when the C code gains the ability to 
> >> > control
> >> >    the translation tables, map 4K pages, etc.
> >>
> >> I'm fine with the assumptions for an initial support. Did you write-down
> >> somewhere those restrictions? So if an issue happen in the future, we
> >> will be able to find quickly the issue.
> >
> > Yeah. we can live with them for now, I think. It should be documented
> > though.
> 
> I've noted the offset requirement in the linker script and the GIC
> memory type assumption in a comment in gic.c.
> 
> > What sort of time line are you foreseeing for fixing them, in terms of
> > before or after 4.5?
> 
> If the GIC will always occupy a distinct set of 1MB sections then
> flagging those is easy enough.

I don't think that is guaranteed, but I've not dug deeply into the GIC
spec, I don't think it says anything about the relative placement of the
various sub functions though.

>  Otherwise, we'd have to add support for
> the second-level page tables, which would complicate things a little.
> 
> Making the boot code work from arbitrary offsets looks very difficult.

Xen itself manages it (not quite arbitrary, it assumes 4K alignment), so
does Linux (completely arbitrary I think), it's not that hard, you just
need to switch to a virtual mapping before you hit C or any non-PIE
code. Once you have a virtual mapping you don't actually care about the
load address any more.

> I guess we'd need to compile libfdt as PIC, set up a temporary C stack
> after the kernel (we can assume there's some RAM following it I
> think), parse the FDT to find the base address, copy the kernel
> forwards or backwards word by word (first copying the copying code to
> a safe location somewhere).
> 
> It all seems very inefficient.

The mechanism which you propose certainly is, yes. But I don't think any
of what you describe is necessary.

>  From my point of view, it would seem
> better to have some way to specify the desired load offset.

Sadly the zImage header is what it is and doesn't include this.

Ian.

> > We should probably consider sticking a "tech preview" or similar label
> > on mini-os/ARM in 4.5 if these issues remain (the load address one in
> > particular).
> 
> 



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