[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Initial Mini-OS port to ARM64
On Feb 23, 2014, at 22:41, Chen Baozi <baozich@xxxxxxxxx> wrote: > > 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. 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |