lkml.org 
[lkml]   [2008]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86: split e820 reserved entries record to late v4

* Yinghai Lu <yhlu.kernel@gmail.com> 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


\
 
 \ /
  Last update: 2008-08-29 09:01    [W:0.152 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site