[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 1/3] x86/crashkernel: avoid Xen image when looking for module/crashkernel position



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.kiper@xxxxxxxxxx> 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 <jbeulich@xxxxxxxx>
>
> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.