Re: [Nouveau] [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel
Arvind R wrote: On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen wrote: I'm adding dri-devel@ to CC, since this suggested patch touches TTM code, and none of the Nouveau code. TTM patches go via dri-de...@. Thanks. This is a NAK in its current form. First, At mmap() time, the placement may not be known, and even if it is known, the placement may change. Second, VM_IO is used to avoid including bos in core dumps, and make sure get_user_pages() isn't lazily called on BOs. That would cause the lock inversion prevention to fail. Third, I'm not sure the Xen strategy will work for VM_MIXEDMAP, which may contain both IO- and real pages? Thanks, Thomas On Wed, 10 Mar 2010 18:51:21 +0530 Arvind R wrote: 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.0 +0530 +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 17:28:59.0 +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); sorry for the typo and other procedural errors. the last added line should be +vma->vm_page_prot = vm_get_page_prot(vma->vm_flags) 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. Efficacy of patch: successful flightgear run on dom0 AND bareboot! Arvind R. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel
On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen wrote: > I'm adding dri-devel@ to CC, since this suggested patch touches > TTM code, and none of the Nouveau code. TTM patches go via > dri-de...@. > > Thanks. > > > On Wed, 10 Mar 2010 18:51:21 +0530 > Arvind R wrote: > >> 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.0 +0530 >> +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 >> 17:28:59.0 +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); >> sorry for the typo and other procedural errors. the last added line should be +vma->vm_page_prot = vm_get_page_prot(vma->vm_flags) >> 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. > Efficacy of patch: successful flightgear run on dom0 AND bareboot! Arvind R. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel
I'm adding dri-devel@ to CC, since this suggested patch touches TTM code, and none of the Nouveau code. TTM patches go via dri-de...@. Thanks. On Wed, 10 Mar 2010 18:51:21 +0530 Arvind R wrote: > 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.0 +0530 > +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 > 17:28:59.0 +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. -- Pekka Paalanen http://www.iki.fi/pq/ ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
