From: Arvind R <arvino55-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
Subject: [Patch RFC] nouveau accelerated on Xen pv-ops kernel
Date: Wed, 10 Mar 2010 18:51:21 +0530 [thread overview]
Message-ID: <d799c4761003100521h663c82eepda85f3f0309828c2@mail.gmail.com> (raw)
Hi,
Following is a simple patch that is needed in nouveau to get
accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's
2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is
almost the mainline merge), was substituted into the kernel-tree.
All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) used
of the same day.
Patch:
diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c
nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c
--- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27
10:19:28.000000000 +0530
+++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10
17:28:59.000000000 +0530
@@ -271,7 +271,10 @@
*/
vma->vm_private_data = bo;
- vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXPAND;
+ vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND;
+ if (!((bo->mem.placement & TTM_PL_MASK_MEM) & TTM_PL_FLAG_TT))
+ vma->vm_flags |= VM_IO;
+ vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags);
return 0;
out_unref:
ttm_bo_unref(&bo);
This patch is necessary because, in Xen, PFN of a page is virtualised.
So physical addresses
for DMA programming needs to use the MFN. Xen transparently does the
correct translation
using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, then Xen
assumes that the backing
memory is in the IOMEM space, and PFN equals MFN. If not set,
page_to_pfn() returns MFN.
The patch enables the ttm_bo_vm_fault() handler to behave correctly
under Xen, and has no
side-effects on normal (not under Xen) operations. The use of
TTM_PL_FLAG_TT in the
check assumes that all other placements are backed by device memory or
IO. If there are
any other placements that use system memory, that flag has to be OR'ed
into the check.
The above patch has no implications on a normal kernel or a Xen pv_ops
kernel booted without
the Xen hypervisor. My testing is on a debian-lenny environment on a
Core2 processor with
nVidia GeForce 9400 GT.
next reply other threads:[~2010-03-10 13:21 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-10 13:21 Arvind R [this message]
[not found] ` <d799c4761003100521h663c82eepda85f3f0309828c2-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-03-11 11:02 ` [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel Pekka Paalanen
2010-03-12 5:27 ` Arvind R
2010-03-28 10:20 ` Joanna Rutkowska
2010-03-30 5:50 ` Arvind R
2010-03-12 12:45 ` Arvind R
2010-03-12 13:20 ` Michael D Labriola
2010-03-13 22:03 ` Joanna Rutkowska
2010-03-15 14:44 ` Michael D Labriola
2010-03-15 23:13 ` Jeremy Fitzhardinge
2010-03-16 7:18 ` Arvind R
2010-03-16 16:48 ` Michael D Labriola
2010-03-16 16:40 ` Michael D Labriola
2010-03-16 17:21 ` Konrad Rzeszutek Wilk
2010-03-16 19:39 ` Michael D Labriola
2010-03-16 19:41 ` Konrad Rzeszutek Wilk
2010-03-17 1:01 ` Konrad Rzeszutek Wilk
2010-03-18 6:09 ` Arvind R
2010-03-19 15:29 ` Michael D Labriola
2010-03-20 6:01 ` Arvind R
2010-03-22 21:14 ` Michael D Labriola
2010-03-23 6:21 ` Arvind R
2010-03-23 12:45 ` Michael D Labriola
2010-03-23 13:27 ` Michael D Labriola
2010-03-25 7:05 ` Arvind R
2010-03-25 7:18 ` Jeremy Fitzhardinge
2010-03-29 14:42 ` Michael D Labriola
2010-06-09 17:43 ` Konrad Rzeszutek Wilk
2010-06-09 18:39 ` Pasi Kärkkäinen
2010-06-09 19:31 ` Konrad Rzeszutek Wilk
2010-06-17 17:51 ` Konrad Rzeszutek Wilk
2010-06-22 22:32 ` Joanna Rutkowska
2010-06-23 12:54 ` Konrad Rzeszutek Wilk
2010-06-23 13:21 ` Joanna Rutkowska
2010-06-23 14:38 ` Konrad Rzeszutek Wilk
2010-06-23 15:08 ` Konrad Rzeszutek Wilk
2010-06-24 19:55 ` Pasi Kärkkäinen
2010-06-24 21:00 ` Konrad Rzeszutek Wilk
[not found] ` <d799c4761003120445h57ab1373m31eb0add242ef74c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-03-16 13:25 ` Thomas Hellstrom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d799c4761003100521h663c82eepda85f3f0309828c2@mail.gmail.com \
--to=arvino55-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).