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] Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kerne

To: dri-devel@xxxxxxxxxxxxxxxxxxxxx <dri-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel
From: Pekka Paalanen <pq@xxxxxx>
Date: Thu, 11 Mar 2010 13:02:58 +0200
Cc: Arvind R <arvino55@xxxxxxxxx>, nouveau@xxxxxxxxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 29 Mar 2010 08:26:44 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=WVPCScc4ux2bQXd2VNPuz8ScQ1D6Ivm1cyum6zp4OvM=; b=rcDY2QWK+Bkq6IMt+V4KjhWIiEJotfWNb/cCXam6MZZ/f6nFmGDTLAPNUIHLB2iE0j eizJMHx27mDL6OEyO5gpBBdtdoEUsqAsk4HkEf+MmVLihd3Y7IQ0azuCNWVOrtr49NGM DtFzCmwxmWPiN/61LKy3nmwt3/wIWb0qrkeao=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; b=FSetfaxEGt+OxJ7mzaBoPLeiRQQSJo1ZaSvNhm472IfPY7EzKdLm1c1Vi5bEmnDj6k jCdzkvJSwghztQt15PcDyshq41upbJv3RSFKm7Pgfqg2Hp31TxuzXBAQrwFiU5bgSizP b7WVN1X2EpGyEQMJJaB7F8TwmIMRvT1vc1JF4=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <d799c4761003100521h663c82eepda85f3f0309828c2@xxxxxxxxxxxxxx>
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>
References: <d799c4761003100521h663c82eepda85f3f0309828c2@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I'm adding dri-devel@ to CC, since this suggested patch touches
TTM code, and none of the Nouveau code. TTM patches go via


On Wed, 10 Mar 2010 18:51:21 +0530
Arvind R <arvino55@xxxxxxxxx> 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
> 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 |
> +       vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP |
> +       if (!((bo->mem.placement & TTM_PL_MASK_MEM) &
> +               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

Xen-devel mailing list