lkml.org 
[lkml]   [2006]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH for 2.6.19] [6/9] x86_64: Update MMCONFIG resource insertion to check against e820 map.
On 14 Nov 2006 19:38:49 +0100, Andi Kleen <ak@suse.de> wrote:
> Andi Kleen <ak@suse.de> writes:
>
> > From: "Aaron Durbin" <adurbin@google.com>
> > Check to see if MMCONFIG region is marked as reserved in the e820 map before
> > inserting the MMCONFIG region into the resource map. If the region is not
> > entirely marked as reserved in the e820 map attempt to find a region that is.
> > Only insert the MMCONFIG region into the resource map if there was a region
> > found marked as reserved in the e820 map. This should fix a known regression
> > in 2.6.19 by not reserving all of the I/O space on misconfigured systems.
>
>
> [...]
>
> Before anyone complains. This one patch is actually not in, because
> Linus' decision was it instead to revert the mcfg reservation
> code for .19. He already did it for i386 and i followed on x86-64.
> But this patch went into the posted patchkit by mistake.
> Will be probably revisited for .20.

I would like to know what others think regarding this area. I think it
would be a good
idea to converge the mmconfig.c implementations for both x86-64 and i386. Is
this not feasable for some reasons I am unaware of? It should lead to more
code reuse and allow for a more unified stance in how both architectures handle
the PCI memory-mapped config space.

What is everyone's thoughts and ideas on such a suggestion?

I think the resource allocation can be addressed in the future after we have
tackled a unified approach.


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

\
 
 \ /
  Last update: 2006-11-14 19:51    [W:0.045 / U:0.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site