linux-kernel - Re: [RFC PATCH] Utilize the PCI API in the AGP framework.

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]

Date:	Tue, 07 Dec 2010 11:16:49 +1000
From:	Dave Airlie <airlied@...hat.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	airlied@...ux.ie, tglx@...utronix.de, hpa@...or.com,
	linux-kernel@...r.kernel.org, konrad@...nel.org,
	Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [RFC PATCH] Utilize the PCI API in the AGP framework.

On Mon, 2010-12-06 at 19:48 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 07, 2010 at 10:02:06AM +1000, Dave Airlie wrote:
> > On Mon, 2010-12-06 at 18:24 -0500, Konrad Rzeszutek Wilk wrote:
> > > Attached is a set of RFC patches that make it possible for AGP graphic drivers to
> > > work under Xen. The major problem that Linux kernel has when running under Xen
> > > is that the usage of "virt_to_phys(x) >> PAGE_SIZE" to get the DMA address is not
> > > applicable. That is due to the fact that the PFN value is not the real Machine
> > > Frame Number (MFN), hence virt_to_phys(x) >> PAGE_SIZE ends up pointing to a
> > > random physical address. But if you use the PCI API, then the DMA (bus) address
> > > returned is a valid MFN.
> > 
> > Can I ask you to go back a step and address what the use case for all of
> > this is, the patch description doesn't address why anyone cares about
> > AGP in 2010, esp with Xen. Virtualising hw  drivers for the sake of it
> > is all well and good, but since most of these drivers are for really
> > legacy systems I can't imagine we are going to see a lot of regression
> > testing before they hit distros like Debian two years from now, though
> > maybe Gentoo might pick up some, (is anyone even running IA64?).
> 
> Hey Dave,
> Thank you for you quick reply and brief look at the code. When I wrote
> this code a similar thought went through my head, and around that
> time three bugs from Debian (#601341, #602418 and #604096) asked what
> is the the status of making AGP work with Xen. I've asked the folks
> on the bugs to provide input on your question. In regards to regressions
> I've a lot of these machines so I can definitly test them for
> regressions (my thought was to run the OpenArena, TuxRace, and watch
> some flash - is that a good enough test or should I expand it?)
> But obviously I don't have all of them so yeah something might break.

Okay reading that I'm not sure you've started at the right end.

I just read 601341, and it concerns nouveau, which shouldn't on the hw
described be touching AGP at all. Its a PCIE machine, so the DRM/TTM
code won't use any of the AGP paths.

Now if we have fixes for TTM/nouveau/radeon that make it work under Xen
then that is a whole different story, however these patches are not
those.

I'd suggest you reverse the priority, of the comment

a) Fix the GART/AGP backend (so drivers/char/agp/*.c) so they use the
PCI API.
   Only the i915 and higher are using the PCI API and I've some of the older
   boxes with i860 so can actually test it.
 b) Fix the TTM to use the DMA API.
 c) Lastly, get rid of _PAGE_IOMAP so we don't have to depend on radeon/nouveau/etc
   to set the proper _PAGE_IOMAP on the PFNs/BARs..

to do c, then b, and finally figure out if anyone cares about a, unless there is a major dependency in the code that requires this ordering.

Dave.

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