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
| ||
|
Date: Thu, 12 Jul 2012 18:50:16 +0100 From: Stefano Stabellini <stefano.stabellini@...citrix.com> To: David Vrabel <david.vrabel@...rix.com> CC: Roger Pau Monne <roger.pau@...rix.com>, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>, Ian Campbell <Ian.Campbell@...rix.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>, Stefano Stabellini <Stefano.Stabellini@...citrix.com> Subject: Re: [Xen-devel] [PATCH WIP 2/6] xen/arm: Introduce xen_guest_init 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). -- 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/
Powered by blists - more mailing lists