linux-kernel - Re: [Xen-devel] [PATCH WIP 2/6] xen/arm: Introduce xen_guest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Jul 2012 12:00:57 -0600
From:	Ian Campbell <ian.campbell@...rix.com>
To:	Stefano Stabellini <Stefano.Stabellini@...citrix.com>
CC:	David Vrabel <david.vrabel@...rix.com>,
	Roger Pau Monne <roger.pau@...rix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"Tim (Xen.org)" <tim@....org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH WIP 2/6] xen/arm: Introduce xen_guest_init

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/