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

[H. Peter Anvin]

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
    resources.

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.

	-hpa
--
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/