[Intel-gfx] Ugly patches for stolen reservation

[H. Peter Anvin]

So the bootloader is just as likely to step on things... what happens when/if it does?

Ingo Molnar <mingo at kernel.org> wrote:
>
>* Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
>
>> Patch 2/2 has the description, but suffice it to say I'm 
>> not really pleased with this, though it does solve a 
>> problem we have.  On some machines, we get MMIO space 
>> allocated on top of this hidden memory, which can cause 
>> problems.  I'm not sure if there are similar problems for 
>> other hunks of the address space; if so it's possible 
>> this could be made more general (though the bits for 
>> looking up the address of this region are definitely 
>> Intel graphics specific).
>
>It looks pretty hardware specific. Discovering it the hard 
>way and marking it e820 reserved in an early quirk is what 
>the firmware should have done to begin with - and I doubt 
>the kernel could do anything significantly cleaner.
>
>How does Windows manage to not crash? By luckily never 
>allocating PCI resources on top of the RAM? Or does it have 
>a quirk?
>
>> Chris has some patches on top to add a new E820 type so 
>> we can look up the region later, which removes some 
>> redundant code in the i915 driver at least.
>> 
>> Any comments?  I assume no one likes this, but maybe it's 
>> just another early quirk we'll have to live with...
>
>No strong feelings against it - my only suggestion would be 
>to make this more visible - right now it's added as e820 
>reserved which hides amongst other areas already marked 
>reserved - would a low-key printk() of the range added make 
>it more apparent that a kernel quirk activated here?
>
>Just so that people know that it came from the kernel, not 
>the firmware.
>
>But in any case:
>
>Acked-by: Ingo Molnar <mingo at kernel.org>
>
>Thanks,
>
>	Ingo

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.