[lkml]   [2008]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] x86: split e820 reserved entries record to late v2
Ingo Molnar wrote:
> Here we have the problem of overlap i outlined earlier: if there's a
> partial overlap at this stage (as i think it can happen in the hpet case
> on David's box), we wont insert the E820_RESERVED resource.
> The hpet hang will be solved, because we dont reprogram the BAR, but we
> now keep the formerly e820-reserved area as 'free' - which the PCI code
> could allocate new resources into - which could cause other problems
> (hangs, non-working devices, etc.) down the line.
> Which most likely wont happen currently in practice (there's enough free
> space elsewhere), but it's still a not truly 'free' area and it would be
> nice to have a complete and correct picture, based on all sources of
> information we have.

This may be a rehash of things previously discussed in this thread; my
email seems to be a bit flakey to the point that I don't know if I have
gotten all the messages.

Either way, Ingo mentioned in a private messages four steps, basically
summarizing the above email:

1 - first we allocate the absolute essentials (e820 RAM and a few low
RAM specials)
2 - then we register all existing PCI resources - but do not reallocate
any PCI resources that conflict with existing step #1 resources
3 - then we allocate e820 reserved entries (and whatever special non-PCI
resources we might know about in general) - these are less trusted
than any of the existing PCI resources but still it can hurt us
badly if the PCI code allocates new resources on them.
4 - then the PCI code can run and allocate free resources to all the
zero, not yet allocated BARs, and can reallocate any resources that
might conflict with existing [step #1 or step #3] registered

I agree that this is almost certainly what we should be doing; there is
a difference between claiming resources already allocated and allocating
resources to new address space, in which case we want to be as
conservative as possible.

The key, of course, is that nothing goes in #1 unless we are bloody
damned sure that if a BAR points there, that BAR is unconditionally
broken and pointing into hyperspace. Something claiming RAM or, say,
the legacy KBC might fall in this area.


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