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]
Date:	Mon, 03 Nov 2008 16:36:19 -0700
From:	Bob Montgomery <>
To:	Dave Airlie <>
Cc:	Dave Jones <>, Yinghai Lu <>,
	Ingo Molnar <>,
	"" <>,
	"" <>,
	Linus Torvalds <>,
	"" <>,
	Joerg Roedel <>,
	FUJITA Tomonori <>,
	Jesse Barnes <>,
	Pavel Machek <>
Subject: Re: [PATCH] disable CPU side GART accesses

On Wed, 2008-10-29 at 21:40 +0000, Dave Airlie wrote:
> On Thu, Oct 30, 2008 at 7:32 AM, Dave Jones <> wrote:
> > On Thu, Oct 30, 2008 at 07:24:34AM +1000, Dave Airlie wrote:
> >
> >  > This stops the CPU from using the aperture for most DRI things. I
> >  > can't confirm this won't regress working systems
> >  > though. The whole AMD GART thing scares me, esp if some of the host
> >  > chipsets also have an AGP GART.
> >
> > The easy cop-out for those in the past has been 'dont support them'.
> > It's why we removed some K8 chipset PCI IDs from the via driver for eg.
> > iirc, if we leave them unprogrammed, they're essentially irrelevant.
> >
> I was more going the other way, why use the IOMMU for AGP when it has
> other tasks to
> do, and we have a host chipset GART.
> Granted I've never had an AMD + AGP system to ever care about this.

We're specifically talking about AMD64, and we're not using an IOMMU for
AGP, we're using the AMD64 implementation of the GART for an IOMMU.
The (possible) danger is that some old AMD64 system could also (or
instead) try using the GART for AGP and run into a problem since my
patch wants to disable CPU side access to the aperture, which is fine
when we're using it as an IOMMU.

In drivers/gpu/drm/drm_memory.c:agp_remap(), there are these comments
about the part of the code that deals with "cant_use_aperture":

 * OK, we're mapping AGP space on a chipset/platform on which
 * memory accesses by the CPU do not get remapped by the GART.
 * We fix this by using the kernel's page-table instead (that's
 * probably faster anyhow...).

So that's encouraging.  Now the question is this:  Can I just go into
amd64-agp.c and add ".cant_use_aperture=true" to the agp_bridge_driver
struct?  Who's brave enough to say that will just work? :-)

static const struct agp_bridge_driver amd_8151_driver = {

The "cant_use_aperture" paths have possibly
never been tested on amd64 agp systems, but
are in use on these systems:

alpha-agp.c:    .cant_use_aperture      = true,
hp-agp.c:       .cant_use_aperture      = true,
i460-agp.c:     .cant_use_aperture      = true,
parisc-agp.c:   .cant_use_aperture      = true,
sgi-agp.c:      .cant_use_aperture = true,
uninorth-agp.c: .cant_use_aperture      = true,
uninorth-agp.c: .cant_use_aperture      = true,

Thanks for any more enlightenment,
Bob Montgomery

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists