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


Re: [Xen-devel] [Solved] Nouveau on dom0

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] [Solved] Nouveau on dom0
From: Arvind R <arvino55@xxxxxxxxx>
Date: Wed, 10 Mar 2010 18:20:42 +0530
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 10 Mar 2010 04:51:27 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ebg1F9PHmGsie9RdstiNyrhn13uVsw50gYJl5YYx/XU=; b=BINc2OK6rrXW8JYctp8qyS5Drshuq1OgVid3mI8DxfdefSRBx876w/lNv3h5wh7FhY vHmF95UEVX9fhlzxNyAnZzos3fDt4Xj9egWLV2yJ0YgWFGDs+f1Nvo9VK6Tu7/Rvrjuy xzGRZQwsa+dFqpuPVdjf98+iXRHewKRYvSpp0=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=M2zr/8aPQBsJDrCQksfTT0b1Cm9a+ALWF9XG0EZxxd6DyYwwLDdl7MJQwlnuqoO/Zn GP5YM+UXBU4VcCV5onHgKv9O35vvbACP0LXRJSYV4ZuMLKxf/eA8k9m/bf7dZg0mMl4j Se1WMnXCcf+rqLaKbYlMRYlnFAUsblYfoJOqk=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100308175127.GF4568@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>
References: <d799c4761003021334t58815ed3p96dc343635b2da2c@xxxxxxxxxxxxxx> <20100303181303.GA21078@xxxxxxxxxxxxxxxxxxx> <d799c4761003040117g1c5c072v8a996b6f9af1fb32@xxxxxxxxxxxxxx> <20100304182518.GB20263@xxxxxxxxxxxxxxxxxxx> <d799c4761003042346k1bc2477mb7711927ea54fb7a@xxxxxxxxxxxxxx> <20100305202309.GA15454@xxxxxxxxxxxxxxxxxxx> <d799c4761003060016o292a5874s91d729893db465c6@xxxxxxxxxxxxxx> <d799c4761003061259u1c8986e9j4ef1e84e1ee8e7df@xxxxxxxxxxxxxx> <d799c4761003061556k795b674do622e0a7d038e0b9@xxxxxxxxxxxxxx> <20100308175127.GF4568@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, Mar 8, 2010 at 11:21 PM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
> On Sun, Mar 07, 2010 at 05:26:12AM +0530, Arvind R wrote:
>> On Sun, Mar 7, 2010 at 2:29 AM, Arvind R <arvino55@xxxxxxxxx> wrote:
>> > On Sat, Mar 6, 2010 at 1:46 PM, Arvind R <arvino55@xxxxxxxxx> wrote:
>> >> On Sat, Mar 6, 2010 at 1:53 AM, Konrad Rzeszutek Wilk
>> >> <konrad.wilk@xxxxxxxxxx> wrote:
>> >>> On Fri, Mar 05, 2010 at 01:16:13PM +0530, Arvind R wrote:
>> >>>> On Thu, Mar 4, 2010 at 11:55 PM, Konrad Rzeszutek Wilk
>> >>>> <konrad.wilk@xxxxxxxxxx> wrote:
>> >>>> > On Thu, Mar 04, 2010 at 02:47:58PM +0530, Arvind R wrote:
>> >>>> >> On Wed, Mar 3, 2010 at 11:43 PM, Konrad Rzeszutek Wilk
>> >>>> >> <konrad.wilk@xxxxxxxxxx> wrote:
>> >>> (FYI, look at
>> >>> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=e84db8b7136d1b4a393dbd982201d0c5a3794333)
>> THAT SOLVED THE FAULTING; OUT_RING now completes under Xen.
> That is great! Thanks for doing all the hard-work in digging through the
> code.
> So this means you got graphics on the screen? Or at least that Kernel
> Mode Setting and the DRM parts show fancy graphics during boot?

AT LAST, yes! Patch: (after aboout 600 reboots!)

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;

The previous patch worked for memory-space exported to user via
mmap. That worked for the pushbuf, but not for mode-setting (I guess).
The ensuing crashes were hard - no logs, nothing. So had to devise
ways of forcing log-writing before crashing (and praying). The located
iomem problem and had search code for appropriate condition.
And setting the vm_page_prot IS important!

Nouveau does kernel-modesetting only. The framebuffer device uses
channel 1 and is as regular a framebuffer as any other. 2D graphics
operations use channel 2 (xf86-video-nouveau). 3D graphics (gallium)
use a channel for every 3D window. There are 128 channels, 0 and 127
being reserved. Every channel has a dma-engine which is user triggered
thro' pushbuffer rings. Every DMA has a 1MiB VRAM space which forms one
of the targets of DMA ops - the other being in the opaque GPU-space. The
BO encapsualtes the virtual-address space of the user VM. and the GPU-DMA
is provided a constructed PageTable that is consistent with the kernel view of
that space. The GEM_NEW ioctl sets up the whole space-management machinery,
the user-space is mmaped out, and the operations triggered thro the pushbuf.

> But to answer your question, the DMA address is actually the MFN
> (machine frame number) which is bitshifted by twelve and an offset
> added. The debug patch I provided gets that from the
> PTE value:
>        if (xen_domain()) {
> +               phys = (pte_mfn(*pte) << PAGE_SHIFT) + offset;
> The 'phys' now has the physical address that PCI bus (and the video
> card) would utilize to request data to. Please keep in mind that the
> 'pte_mfn' is a special Xen function. Normally one would do 'pte'.
> There is a layer of indirection in the Linux pvops kernel that makes
> this a bit funny. Mainly most of the time you get something called GPFN
> which is a psedu-physical MFN. Then there is a translation of PFN to
> MFN (or vice-versa). For pages that are being utilized for PCI devices
> (and that have _PAGE_IOMAP PTE flag set), the GPFN is actually the MFN,
> while for the rest (like the pages allocated by the mmap and then
> stitched up in the ttm_bo_fault handler), it is the PFN.
> .. back to the DMA part. When kernel subsystems do DMA they go through a
> PCI DMA API. This API has things such as 'dma_map_page', which through
> layers of indirection calls the Xen SWIOTLB layer. The Xen SWIOTLB is
> smart enough (actually, the enligthen.c) to distinguish if the page has
> _PAGE_IOMAP set or not and to figure out if the PTE has a MFN or PFN.
> Hopefully I've not confused this matter :-(
On the contrary, a neat essence of the matter - only wish it was clear to me
a month ago:-(

YAHOO! (just a simple shout)

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>