This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] [Nouveau][Patch RFC] nouveau accelerated on Xen pv-ops kerne

To: nouveau@xxxxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [Nouveau][Patch RFC] nouveau accelerated on Xen pv-ops kernel
From: Arvind R <arvino55@xxxxxxxxx>
Date: Wed, 10 Mar 2010 18:51:21 +0530
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 10 Mar 2010 05:22:04 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=T/yII/1lkHfgNfbYuEBHixs3fF5uB/elLAVq7SzT8d8=; b=wElFqv/nP7RR+vQUap7S8F1uoOsTBQ5KtlURcsXAEOd/tgWD7Fz/Ue/Q44ZFAbALh6 w1wGyN35REa2Z8hOW7Akfk4q1dornAsnpMPmFJd28/ikDU20YzL6g1YWGXNRkY0kCVwV Ri3aLVLtGrQRGkONH8pHuChJZ5nqzpfw1AfSI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=kOy/zD/PG1RDkZk5t4M/1fqQ5LJG0x1aGACGoKGQc0SUAHBnE2tTBZB65ijIeUXle+ RZW3mYCJ0vEypCTqXaOAmbDcTdluABJhMq8qJDHLiKITEvwhUhyxBEQr6p8ou4F8yefk PbrnSY34YRd2tq1B0SBmpszch1NVtz/9Gju4o=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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 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.

diff -Naur nouveau-kernel.orig/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;

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

Xen-devel mailing list