Re: [Nouveau] [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel
On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen p...@iki.fi 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 arvin...@gmail.com 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
[Nouveau] [Patch RFC] nouveau accelerated on Xen pv-ops kernel
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. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] nouveau on xen, almost there
Hi all, I backported nouveau-git20100222 to pv_ops 2.6.31.6 by replacing the whole drm-tree and includes. Just needed a minor fix in drm_sysfs.c to compile. nouveau works fine with 2D acceleration enabled when booted without xen. Even nouveau-dri works! But when booted on Xen, X hangs if Accel enabled Works fine with Option NoAccel True in xorg.conf. Found to be stuck in nv_accel_common_init. Call traced in xf86-nouveau: in nv_accel_common.c; NVAccelInit2D_NV50(ScrnInfoPtr pScrn) nouveau_grobj_alloc(chan, Nv2D, NV50_2D,pNv-Nv2D) finishes. BEGIN_RING(chan, eng2d, NV50_2D_DMA_NOTIFY, 3) hangs. system with blank screen. Can connect with ssh. Card is GeForce 9400 GT with 1Gb vram. debug trace tail from syslog: kernel: [drm] nouveau :06:00.0: nouveau_ramht_insert:141 - insert ch2 0x00c0: h=0xd803, c=0x0e0a kernel: [drm:drm_ioctl], pid=6225, cmd=0x400c6444, nr=0x44, dev 0xe200, auth=1 kernel: [drm] nouveau :06:00.0: nouveau_gpuobj_gr_new:840 - ch2 class=0x502d kernel: [drm] nouveau :06:00.0: nouveau_gpuobj_new:216 - ch2 size=24 align=16 flags=0x0006 kernel: [drm] nouveau :06:00.0: nouveau_gpuobj_new:224 - gpuobj 880006a90140 kernel: [drm] nouveau :06:00.0: nouveau_gpuobj_new:237 - private heap kernel: [drm] nouveau :06:00.0: nouveau_gpuobj_ref_add:457 - ch2 h=0x8020 gpuobj=880006a90140 kernel: [drm] nouveau :06:00.0: nouveau_ramht_hash_handle:75 - ch2 handle=0x8020 kernel: [drm] nouveau :06:00.0: nouveau_ramht_hash_handle:86 - hash=0x0180 kernel: [drm] nouveau :06:00.0: nouveau_ramht_insert:141 - insert ch2 0x0180: h=0x8020, c=0x00100e0c Am game to try to fix - need help. Arvind R. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] nouveau on xen dom0 working!
Hi all, Some good news on my first post to this list - git20100218 backport of mesa, drm, xorg, nouveau (kernel and xf86) and xen-testing finally enabled me to get Xorg on 2.6.31.6-xen kernel dom0! Clean VT switches at last on dom0. Clean (self-built) debian packages used for all components. Now the bad news. Had to scour the net for some drm and ttm patches. Have to disable acceleration on xf86-nouveau driver. So glxgears reports a measly 180 fps - but VERY stable (24 hours). The graphics card is GeForce 9400 GT. With acceleration enabled, syslog is OK with - Allocating FIFO number 2 - nouveau_channle_alloc: initialised FIFO 2 but Xorg.0.log ends with - NOUVEAU(0): Opened GPU channel 2 but never gets to - NOUVEAU(0): [DRI2] Setup complete BTW, does anyone know what the modesetting_drv.so built in the mesa tree is? On non-xen boots, using that instead of xf86-video-nouveau driver reports 3D acceleration enabled but 2D disabled! Only noticeable bug is the garbled graphic cursor that hangs aroung even in the console screens. Hope this post is not amiss in this list. Pls. contact me for any info that would be useful. Arvind R. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
