Well e820_setup_gap is a bit more descriptive, but if you're factoring out 
common code in the x86 tree, it may as well be even more descriptive, e.g. 

Andi may remember some of the history here.  It seems like we should be 
reserving those regions early on like the x86_64 code does, but it's possible 
that will create more conflicts later on for some platforms (I don't know of 

For future patches and x86 specific questions, you should probably cc lkml and 
the x86 maintainers, they may be able to provide additional feedback.

Thanks,
Jesse
--

I tried that some time ago and it turned out that some systems have
mappings in holes and don't boot anymore when you fill the holes too much. 
But that was only considering e820. if you do this it might work if you 

I don't remember why it is different. Probably wasn't intentional.
But in general x86-64 is less fragile than i386 here because it has the e820
allocator and can deal better with conflicts.

-Andi
--

wonder if using holes in MTRR AND e820 could help...

YH
--

Typically not, since the MTRRs won't tell you what is free address space 
and what is occupied by non-BAR I/O devices.

	-hpa
--

Yes, considering all possible reservation schemes is really critical 

Yes, and that's definitely the model we want on both sides.  Working on 
this is way high on my personal priority list at the moment.

	-hpa

--

Yeah, good point.  There's code to check for ACPI reserved regions when 
verifying MCFG space, so at least we're starting to do this...

Thanks,
Jesse

--