Re: [Xen-devel] Initial Mini-OS port to ARM64

[Chen Baozi <baozich@xxxxxxxxx>]

On Feb 18, 2014, at 23:54, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 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.

> 
> 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.
> 


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