linux-kernel - Idea: Make drivers/char/agp/*.c use the PCI API.

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>] [day] [month] [year] [list]

Message-ID: <20101130174325.GA10507@dumpdata.com>
Date:	Tue, 30 Nov 2010 12:43:25 -0500
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	airlied@...ux.ie, tglx@...utronix.de, hpa@...or.com
Cc:	linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Idea: Make drivers/char/agp/*.c use the PCI API.

Hey guys,

I am working on getting Linux Xen PV guests to be able to use graphics card.
The crux of the problem I am running into is that any of the 'page_to_phys'
or 'virt_to_phys' macros under Xen return a PFN which is actually not the 
_real_ PFN (called Machine Frame Number, MFN in Xen terminology). So when
we program the GATT bus address, the PFN of the GATT != MFN. Hence the bridge
ends up looking for the GATT somewhere completely different than what we expected.

In the past I've inserted some nasty skanky lookup code to in drivers/char/agp/*.c
so that the GATT bus address, and the bus addresses of the pages that are to be
mapped to the GATT get the MFN - but that was a band-aid solution.

I was wondering what you guys thought if I reworked the drivers/char/agp to use
the PCI API, similarly to what drivers/char/agp/intel-gtt.c is doing right now.
Perhaps even go further and squash the intel-gtt.c scatter-list usage into the
generic.c. Other ideas?

I've some of the old hardware laying around so I can definitly test some subset
of the hardware. Are there some particular ones I should look for that had
trouble?

--
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/