Re: Initial Mini-OS port to ARM64

[Chen Baozi <baozich@gmail.com>]

On Feb 23, 2014, at 22:41, Chen Baozi <baozich@gmail.com> wrote:

> 
> On Feb 18, 2014, at 23:54, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
>> On Sun, 2014-02-16 at 23:51 +0800, Chen Baozi wrote:
>>> Hi all,
>>> 
>>> It is much later than I used to expect. I guess it might be help
>>> to publish my work, though it is still not finished (and might not
>>> be finished very soon...). 
>>> 
>>> I began to try to port mini-os to ARM64 since last summer. Since
>>> the 64-bit guest support is not quite well at that time, this
>>> work had been stopped for a long time until two months ago.
>>> 
>>> Though it is still at very early stage, it at least can be built,
>>> setup a early page table for booting, parse the DTB passed by the
>>> hypervisor, and be debugged by printk at present. So I put it
>>> on github in case someone might be interested in it. Here is the
>>> url: https://github.com/baozich/minios-arm64
>> 
>> Cool. Thank you very much for sharing.
>> 
>>> Right now, there are some troubles to make GIC work properly,
>>> as I didn’t consider mapping GIC’s interface in address space and
>>> follows x86’s memory layout which make the kernel virtual address
>>> starts at 0x0. I’ll fix it as soon as possible.
>> 
>> Actually, having virtual memory start at 0x0 seems quite reasonable to
>> me, what is the problem?
> 
> Hmmm, I don’t think it is a big problem. I just didn’t realise it is 
> necessary to map GIC’s interface after MMU on, which leads a exception
> when I try to program GIC by the physical address populated by DT. 
> I used to think about making mini-os kernel address start at 0x80000000
> and leave the address below 0x80000000 to be 1:1 mapping, which
> seems to be able to make things easier when initialising GIC.

Well, I think we need a fixmap region for mini-os on arm/arm64, which is not
included in original x86 version.

> 
>> 
>> Someone somewhere was thinking of making minios run without the MMU
>> enabled on ARM -- to save on the overhead IIRC. But it occurs to me here
>> that this would be problematic if we were to move the guest memory map
>> around -- which we are planning to do for 4.5. I think this means that
>> minios must use the MMU, at least by default.
>> 
>> I wouldn't necessarily object to the presence of an option to build an
>> MMU-less variant for specific use cases, so long as it was clear to
>> those enabling it that there VMs might only work on a single version of
>> Xen.
> 
> Actually, I’ve already enabled MMU in my current implementation. 
> 
> Cheers,
> 
> Baozi
> 
>> 
>>> Besides, there is still lots of work to be done. So any comments
>>> or patches are welcome.
>> 
>> Ian.