Re: [Xen-devel] [PATCH WIP 2/6] xen/arm: Introduce xen_guest_init

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2012-07-12 at 13:50 -0400, Stefano Stabellini wrote:
> On Thu, 12 Jul 2012, David Vrabel wrote:
> > On 12/07/12 12:49, Roger Pau Monne wrote:
> > > David Vrabel wrote:
> > >> On 09/07/12 15:45, Konrad Rzeszutek Wilk wrote:
> > >>> On Fri, Jun 22, 2012 at 05:14:41PM +0100, Stefano Stabellini wrote:
> > >>>> We used to rely on a core_initcall to initialize Xen on ARM, however
> > >>>> core_initcalls are actually called after early consoles are 
> > >>>> initialized.
> > >>>> That means that hvc_xen.c is going to be initialized before Xen.
> > >>>>
> > >>>> Given the lack of a better alternative, just call a new Xen
> > >>>> initialization function (xen_guest_init) from xen_cons_init.
> > >>>>
> > >>>> xen_guest_init has to be arch independant, so write both an ARM and an
> > >>>> x86 implementation. The x86 implementation is currently empty because 
> > >>>> we
> > >>>> can be sure that xen_hvm_guest_init is called early enough.
> > >>>>
> > >>>> Probably we can get rid of this as soon as we have better DT support.
> > >>> What is DT?
> > >>
> > >> Device Tree.  It's a binary describing the hardware and some system
> > >> configuration that is passed to the kernel by the boot loader or (in
> > >> this case) the hypervisor.  Vaguely analogous to ACPI except it's not
> > >> crazy ;).
> > >>
> > >> We really should get the device tree bindings sorted out before
> > >> accepting any kernel side patches.  I think we can do this even if Xen's
> > >> device tree support is incomplete.
> > > 
> > > Will this be passed from the hypervisor to the linux kernel using a
> > > specific mechanism (different than the native one)?
> > 
> > The same mechanism.  The kernel is booted with the physical address of
> > the device tree blob in a register (r2 I think) .  Xen sorts this out
> > for dom0 and the toolstack is responsible for this for domUs.
> > 
> > I would expect the device tree to include the physical address of the
> > shared page with something like this.
> > 
> > hypervisor {
> >    xen {
> >        shared-info = <0x00 0x12345678 0 4096>;
> >    };
> > };
> > 
> > Arch code in ARM would check for the hypervisor node (very) early on and
> > call a hypervisor specific init function based on the name of the child
> > node (xen in this case).
>  
> There is no need to specify the shared-info page address in the DT as we
> already have a mechanism to map it dynamically (XENMAPSPACE_shared_info).
> 
> However we could use DT to pass the address of the grant table pages
> instead of introducing HVM_PARAM_GRANT_START_PFN (see
> http://marc.info/?l=linux-kernel&m=134140077708602&w=2).

We need to be sure there is something there which signals "running under
Xen" in the general sense too so we can detect it early on. Perhaps
something explicitly for that purpose or perhaps one of these required
items could serve as a key. 

Ian



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