Re: [PATCH] x86: split e820 reserved entries record to late v4

[Ingo Molnar]

* Yinghai Lu <yhlu.kernel@xxxxxxxxx> wrote:

> >  BIOS-e820: 0000000077ff0000 - 0000000078000000 (reserved)
> >  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
> >  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
> >
> > which overlaps with the chipset PCI BAR (hpet) resource:
> >
> >   pci 0000:00:14.0: BAR has HPET at fed00000-fed003ff
> >
> > so due to this 1K conflict we take the full e820-reserved entry out and
> > give the range 0xfec00000-0x100000000 as 'free'.
> 
> you will get
> fec00000 - ffffffff reserved
>    fed0000 - fed003ff hpet
>      fed0000 - fed003ff 0000:00:14.0

ok - because it's fully contained insert_resource() will succeed? I 
thought it would only succeed if the new resource was smaller than (a 
subset of) the existing resource. In the other direction, when a newly 
inserted resource is a superset of the existing resource, i thought we'd 
fail.

hypothetical scenario, what if we had neither a superset nor a subset 
scenario, but a partial overlap, between:

> >  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)

and:

> >   pci 0000:00:14.0: BAR has HPET at feb0f000-fec01000

i.e. we have:

      [... PCI BAR ...]
            [... e820 reservation ...]

in that case the insert_resource() will fail due to the conflict. Can we 
declare it in that case that the e820 reserved entry is mortally broken 
and we just ignore it?

At least we should emit a prominent warning if insert_resource() fails, 
and add in an mdelay(2000) so that the user sees it.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/