[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 Wed, Jan 20, 2016 at 1:00 PM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote: >> +static bool x86_init_fn_supports_subarch(struct x86_init_fn *fn) >> +{ >> + if (!fn->supp_hardware_subarch) { >> + pr_err("Init sequence fails to declares any supported >> subarchs: %pF\n", fn->early_init); >> + WARN_ON(1); >> + } >> + if (BIT(boot_params.hdr.hardware_subarch) & fn->supp_hardware_subarch) >> + return true; >> + return false; >> +} > > So the logic for this working is that boot_params.hdr.hardware_subarch > > And the macros define two: BIT(X86_SUBARCH_PC) or BIT(X86_SUBARCH_XEN). > > But hardware_subarch by default is set to zero. Which means if GRUB2, > PXELinux, Xen multiboot1 > don't set it - then the X86_SUBARCH_PC is choosen right? > > 1 << 0 & 1 << X86_SUBARCH_PC (which is zero). > > For this to nicely work with Xen it ought to do this: > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index 993b7a7..6cf9afd 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -1676,6 +1676,7 @@ asmlinkage __visible void __init xen_start_kernel(void) > boot_params.hdr.ramdisk_image = initrd_start; > boot_params.hdr.ramdisk_size = xen_start_info->mod_len; > boot_params.hdr.cmd_line_ptr = __pa(xen_start_info->cmd_line); > + boot_params.hdr.hardware_subarch = X86_SUBARCH_XEN; > > if (!xen_initial_domain()) { > add_preferred_console("xenboot", 0, NULL); > > > ? That's correct for PV and PVH, likewise when qemu is required for HVM qemu could set it. I have the qemu change done but that should only cover HVM. A common place to set this as well could be the hypervisor, but currently the hypervisor doesn't set any boot_params, instead a generic struct is passed and the kernel code (for any OS) is expected to interpret this and then set the required values for the OS in the init path. Long term though if we wanted to merge init further one way could be to have the hypervisor just set the zero page cleanly for the different modes. If we needed more data other than the hardware_subarch we also have the hardware_subarch_data, that's a u64 , and how that is used would be up to the subarch. In Xen's case it could do what it wants with it. That would still mean perhaps defining as part of a Xen boot protocol a place where xen specific code can count on finding more Xen data passed by the hypervisor, the xen_start_info. That is, if we wanted to merge init paths this is something to consider. One thing I considered on the question of who should set the zero page for Xen with the prospect of merging inits, or at least this subarch for both short term and long term are the obvious implications in terms of hypervisor / kernel / qemu combination requirements if the subarch is needed. Having it set in the kernel is an obvious immediate choice for PV / PVH but it means we can't merge init paths completely (down to asm inits), we'd still be able to merge some C init paths though, the first entry would still be different. Having the zero page set on the hypervisor would go long ways but it would mean a hypervisor change required. These prospects are worth discussing, specially in light of Boris's hvmlite work. Luis _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |