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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-05-13 at 14:12 +0100, 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 noticed that in arch_domain_create() for arm there are codes
> allocating xen heap pages for domain->shared_info:
> 
> arch_domain_create:
>       if ((d->shared_info = alloc_xenheap_pages(0, 0)) == NULL)       
> 
> But it seems it is used nowhere and even not mapped by libxc:
> 
> int arch_setup_bootlate(struct xc_dom_image *dom)
> {
>       /* XXX
>        *   map shared info
>          *   map grant tables
>          *   setup shared info
>          */
>         return 0;
> }

This comment is out of date, in fact on ARM the guest itself takes care
of mapping these things by using XENMEM_add_to_physmap with
XENMAPSPACE_shared_info et al.

> So my question is what is the role of shared_info page in arm? 

It is mostly the same as on x86 with a couple of exceptions which spring
to mind. Firstly XEN_LEGACY_MAX_VCPUS == 1 on ARM so guests are required
to use VCPUOP_register_vcpu_info for secondary CPUs instead of relying
on some number of vcpu_info's being present in the shared info. Secondly
we don't actually implement the wall-clock stuff there (yet).

The bit we currently use is the evtchn_* stuff.

> And is there any relations between shared_info and start_info?

Not really no, one is start of day and one is runtime.

Ian.


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