[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v1 4/8] x86/init: add linker table support
On Thu, Jan 21, 2016 at 11:50 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >> The PV init code would kick in early and could parse the >> boot_params.hdr.hardware_subarch_data pointer as it sees fit. >> > > Right... we already do that. > > I don't even think you need to initialize any tables. The init above is for the sorting. Its not needed unless your subsystem uses it, its the same sort as with the IOMMU stuff only with stronger semantics. In theory one would *not* need to do this so early, it could wait, provided you at least are confident the linker order suffices for all routines called early. To be clear, the struct proposed defines a set of callbacks for calling feature's callbacks at different levels of the x86 init path. As this patch series is concerned it had one for x86_64_start_reservations(). This could easily be extended to also include one to be called for instance at setup_arch(). If we were able to solve the ability to make use of subarch so early as of we could then have a callback for x86_64_start_kernel(), then one at x86_64_start_reservations() and perhaps one at setup_arch() later -- Kasan is an example that could fit this example in the future. What I mean is that we could avoid the sort or wait for the run time sort later until x86_64_start_reservations() or even setup_arch() provided the deafult linker order suffices for the series of previous callbacks. Its up to us but I'm taken care to be pedantic about semantics here. > At least on i386, > we have to do this in assembly code. Neat! How is that order kept? > However, it is just a simple table walk. :) Luis _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |