On Thu, Dec 07, 2017 at 04:39:37PM +0100, Daniel Kiper wrote: > On Thu, Dec 07, 2017 at 04:08:31AM -0700, Jan Beulich wrote: > > >>> On 04.12.17 at 11:24, <daniel.ki...@oracle.com> wrote: > > > --- a/xen/arch/x86/setup.c > > > +++ b/xen/arch/x86/setup.c > > > @@ -653,7 +653,7 @@ void __init noreturn __start_xen(unsigned long mbi_p) > > > module_t *mod = (module_t *)__va(mbi->mods_addr); > > > unsigned long nr_pages, raw_max_page, modules_headroom, *module_map; > > > int i, j, e820_warn = 0, bytes = 0; > > > - bool acpi_boot_table_init_done = false; > > > + bool acpi_boot_table_init_done = false, xen_relocated = false; > > > > I don't see a need for the xen_ prefix here - with that dropped > > (which I guess could be done while committing) > > Reviewed-by: Jan Beulich <jbeul...@suse.com> > > I am OK with that change. Go ahead...
I have seen that you have applied this. Great! I have just realized that this patch also fixed another issue which we discovered a few days ago. Machines with less than 4 GiB rebooted mysteriously if Xen was loaded with Multiboot2 and relocated by the bootloader. This happened because relocator chosen to relocate e.g. dom0 kernel over the Xen image. The problem does not appear if Xen is loaded with Multiboot protocol. This happens because end of RAM region (e) occupied by Xen is updated by Xen relocation code. So, one shot and two bugs killed at once! Nice! Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
