Re: [Xen-devel] dom0 pvops boot crash on very ordinary Dell R310

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Wed, 2010-10-27 at 18:43 +0100, Jeremy Fitzhardinge wrote:
> >>> -   e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS -
> >>> ISA_START_ADDRESS,
> >>> -                   E820_RESERVED);
> >>> +   if (!xen_initial_domain())
> >>> +           e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS -
> >>> ISA_START_ADDRESS,
> >>> +                           E820_RESERVED);
> >> What's the problem with making it unconditionally reserved even if
> the
> >> host E820 doesn't?
> > Perhaps nothing, but if it was necessary wouldn't it be needed on
> native
> > too?
> 
> I don't think its *necessary*  (BIOS would have to be desperately
> broken to mark anything in that range as E820_RAM), but I'd prefer to
> avoid unneeded conditionals just to try and make testing simpler.

The two cases already diverged at the earlier:
        op = xen_initial_domain() ?
                XENMEM_machine_memory_map :
                XENMEM_memory_map;
        rc = HYPERVISOR_memory_op(op, &memmap);
You could say that reserving this region actually adds another fork in
the test coverage e.g. before we had native, domU and dom0 e820 layouts
(the third being an amalgamation of the first two) to consider and we
now have only the native and domU cases.

If there are quirks required in the machine memory map then they should
really be applied up in the generic x86 code since they impact native
too.

I guess having native add the region when sanitising the e820 map isn't
actually a crazy idea in the face of potentially insane BIOS provided
maps.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel