Re: [MirageOS-devel] Mini-OS on ARM status

[Thomas Leonard <talex5@xxxxxxxxx>]

On 6 May 2014 10:19, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> [ccing Dave as fyi, or should we move this to the mirage list?]

Moved.

> On 6 May 2014, at 10:08, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>
>> On 6 May 2014 09:41, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>> The mirage/xen-arm-builder scripts work pretty well now.  I'm
>>> just bringing up a Cubietruck later today, so will have both ready.
>>
>> Cool - that's easier than following a page full of instructions!
>
> Although the instructions are very valuable to figure out what all the
> moving pieces are!  It's incredible this stuff boots at all...
>
>>> ARM minios works great -- I'm just testing putting the OCaml xenstored
>>> into dom0 instead of the default C one.  How goes the Mirage
>>> hacking?   I'm thinking of putting together a simple Mirage/ARM/Xen
>>> based presentation for the UCN meeting on Tuesday (but can do this
>>> in userspace if the MiniOS hits snags)
>>
>> I'm just looking at it now. I couldn't find which revision of Mini-OS
>> corresponded to the initial import into Mirage, but it probably
>> doesn't matter. My current plan is to replace the "kernel" directory
>> with the current Mini-OS and then hack on it until it works.
>>
>
> That's pretty much the right approach.  Once we have a working fork,
> we can look into rebasing the entire lot on top of an upstream MiniOS.
>
> I'd like to mirror a MiniOS repository that's independent of the main
> Xen git tree to make this easier, but there's no rush on that.
>
>> What's the plan for handling the stack? Mini-OS currently allocates a
>> small fixed stack and uses that for everything. Probably OCaml will
>> want something bigger and with a guard page below it. Does Mirage
>> expect the stack to grow automatically on demand, or is it fixed? This
>> might require getting virtual memory working properly (currently, it's
>> just 1:1 with the "physical" memory Xen provides).
>
> We pretty much use a static stack in x86_64 as well, if I remember right,
> and size it big enough that we don't blow past it casually.  Doing that
> initially on ARM to get things going would be fine too.  I like the idea
> of not requiring virtual memory to be used unless absolutely necessary,
> since it avoids the unpredictability of demand paging.
>
> We may need it for grant tables though...?

The FDT suggests an address for the grant table, and I currently just use
XENMAPSPACE_grant_table so that Xen makes it appear there. I'm
assuming that Xen's suggested address won't overlap any of the other
addresses it passes us (all these addresses are hard-coded in Xen in
arch-arm.h).

ARM has two stages to each address translation: VM virtual address to
VM physical address (this mapping is managed by the VM), and then VM
physical to actual physical address (controlled by Xen).

The guest's MMU is enabled (otherwise hypercalls don't work properly);
it's just configured with a 1:1 mapping currently.


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel