[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
> +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); ? _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |