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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8f95bb250611141047k2f879893g7ea42768247e576@mail.gmail.com>
Date:	Tue, 14 Nov 2006 10:47:20 -0800
From:	"Aaron Durbin" <adurbin@...gle.com>
To:	"Andi Kleen" <ak@...e.de>
Cc:	linux-kernel@...r.kernel.org, "Matthew Wilcox" <matthew@....cx>
Subject: Re: [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@...e.de> wrote:
> Andi Kleen <ak@...e.de> writes:
>
> > From: "Aaron Durbin" <adurbin@...gle.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/