Re: [PATCH for 2.6.19] [6/9] x86_64: Update MMCONFIG resource insertion to check against e820 map.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 14 Nov 2006 19:38:49 +0100, Andi Kleen <[email protected]> wrote:
Andi Kleen <[email protected]> writes:

> From: "Aaron Durbin" <[email protected]>
> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux