[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XenARM] Question about booting parameter of Mini-OS for ARM



On May 7, 2013, at 4:39 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

> On Mon, 2013-05-06 at 11:40 +0100, Stefano Stabellini wrote:
>> On Mon, 6 May 2013, Chen Baozi wrote:
>>> On Mar 25, 2013, at 6:00 PM, Stefano Stabellini 
>>> <Stefano.Stabellini@xxxxxxxxxxxxx> wrote:
>>> 
>>>> On Sun, 24 Mar 2013, Chen Baozi wrote:
>>>>> Hi all,
>>>>> 
>>>>> I'm reading Mini-OS's codes and to estimate the amount of work porting it 
>>>>> to
>>>>> ARM (Ian's GSoC idea this year).
>>>>> 
>>>>> While Xen is booting Mini-OS on x86 platform, it passes the start_info_t 
>>>>> to
>>>>> the guest through ESI register. And Mini-OS would use this structure as 
>>>>> the 
>>>>> argument of start_kernel. However, I didn't see codes handle the
>>>>> start_info_t on ARM side. Instead, I see a more standard protocal when
>>>>> booting ARM's dom0, which follows linux kernel bootstrap rules:
>>>>> 
>>>>>   r0 = 0, r1 = machine nr, r2 = atags or dtb pointer
>>>>> 
>>>>> Does it mean that Xen for ARM does not use the start_info_t to pass
>>>>> information when booting PV guest? 
>>>>> Or did I miss something important?
>>>> 
>>>> That's right, we don't use start_info_t on ARM, in fact ARM guests are
>>>> not exactly like x86 PV guests.
>>>> The information present in the start_info page are either available via
>>>> device tree or no used on ARM.
>>> 
>>> I'm thinking of parsing the dtb and fill the start_info structure
>> according to it before jump to the start_kernel. In that case, it
>> won't break some original mini-os interface.
> 
> If you go this path then trying to do it in arch_init would be
> preferable. Nothing in start_kernel before arch_init seems like it
> should need start info.
> 
> This is effectively what we do for Linux guests too -- populate a stunt
> start info early on.
> 
>> You can try that, or you can refactor the code dividing it into x86
>> specific and common stuff.
> 
> There is bound to be a bunch of this sort of refactoring required, just
> because mini-os in practice has only really supported x86 until now and
> even with the best intentions arch specific stuff tends to leak out
> unless you are actively using something on multiple arches.
Yes. Right now I'm testing "make" to complete the "infrastructure" headers and 
interfaces that arm64 needs. It turns out that it lacks some basic type 
definition such as "uint64_t", which is introduced from headers files of xen 
hypervisor. I checked x86's implementation. Those types are defined at 
include/public/arch-x86/xen-x86_32.h. If we follows x86's convention, we should 
define them in xen hypervisor's tree. I don't think it is a good idea. Any 
ideas?


> 
> Ian.
> 
> 


_______________________________________________
Xen-arm mailing list
Xen-arm@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.