WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Nouveau on dom0

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] Nouveau on dom0
From: Arvind R <arvino55@xxxxxxxxx>
Date: Sat, 6 Mar 2010 13:46:18 +0530
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 06 Mar 2010 00:16:55 -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=uxsLclkv6BtEV5VwJsdvLwgJHA1XTtE1k3mdVF/JHhw=; b=EMa74BQMa4/IlJlAjS+svi0ln2FZAAU0lf0xXWVPvjk/KcRC2tbe2rKzFpLIt9XOuV xtYzESG/Z9xktJnPHV2vWpLX0e0PK+cCDXvtSvKBxhJmXFIvvabL5Es7eP68IoPu2XJA t4E4ZCs9ojowcfEPA8tnQBv7+gVSStdA22J6Y=
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=GZldNwPlgXzPifCT/AkShKa5S294W7vdPSQUGuNy4IhLhdgy9UI0hjxOAcRWTxtVGw F4yCoOxMHGTzcVfefX6gHcN3RWLmw5iPEARaUL0qu3p/Ma4y/Bqj5Y8kXJ0R4uLrQ0vc X7VurmScNEz2ObNZqr1WAF2LRPs/kyV2Oz3Cg=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100305202309.GA15454@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: <d799c4761002250901g6029a69et21fcf1d8556f047@xxxxxxxxxxxxxx> <d799c4761002260734j13bc01e3vfd7788b6196230ea@xxxxxxxxxxxxxx> <20100301160130.GB7881@xxxxxxxxxxxxxxxxxxx> <d799c4761003021334t58815ed3p96dc343635b2da2c@xxxxxxxxxxxxxx> <d799c4761003030911l51013f07mc1bf4aa15df519c4@xxxxxxxxxxxxxx> <20100303181303.GA21078@xxxxxxxxxxxxxxxxxxx> <d799c4761003040117g1c5c072v8a996b6f9af1fb32@xxxxxxxxxxxxxx> <20100304182518.GB20263@xxxxxxxxxxxxxxxxxxx> <d799c4761003042346k1bc2477mb7711927ea54fb7a@xxxxxxxxxxxxxx> <20100305202309.GA15454@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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:
> Yeah... Can you also instrument the code to print the PFN? The code goes
> through insert_pfn->pfn_pte, which calls xen_make_pte, which ends up
> doing pte_pfn_to_mfn. That routine does a pfn_to_mfn which does a
> get_phys_to_machine(pfn). The last routine looks up the PFN->MFN lookup
> table and finds a MFN that corresponds to this PFN. Since the memory
> was allocated from ... well this is the big question.
>
> Is the memory allocated from normal kernel space or is really backed by
> the video card. In your previous e-mails you mentioned that is_iomem is
> set to zero, which implies that the memory for these functions is NOT
> memory backed.
>
> the VM_IO is OK if the memory that is being referenced is the video
> driver memory. _BUT_ if the memory is being allocated through the
> alloc_page (ttm_tt_alloc_page) , or kmalloc, then this will cause us
> headaches. You might want to check in  ttm_bo_vm_fault what the
> vma->vm_flags are and if VM_IO is set.
>
> (FYI, look at
> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=e84db8b7136d1b4a393dbd982201d0c5a3794333)
How do you remember these refs?!

>
> Thought I am not sure if the ttm_bo_mmap is used by the nvidia driver.
U mean nouveau? Only for accelerated graphics.

> Attached is a re-write of the debug patch I sent earlier. I compile
> tested it but haven't yet run it (just doing that now).
>
Output: (snipped/cut/pasted for easier association)

Trace of Pushbuf Memory Access, Bare-BOOT:
X: OUT_RING: Enter: chan=0x8170a0, id=2, data=0x48000, chan->cur=0x7f0aa3594054
kernel: [TTM] FAULTing-in address=0x7f0aa3594000, bo->buffer_start=0x0
kernel: [ BEFORE]PFN: 0x7513f PTE: 0x750001e3 (val:750001e3): [    RW
       PSE GLB x  ] [2M]
kernel: [    AFTER]PFN: 0x7513f PTE: 0x750001e3 (val:750001e3): [
RW         PSE GLB x  ] [2M]
kernel: [BEFORE]PFN: 0x75144 PTE: 0x750001e3 (val:750001e3): [    RW
      PSE GLB x  ][2M]
kernel: [   AFTER]PFN: 0x75144 PTE: 0x750001e3 (val:750001e3): [    RW
        PSE GLB x  ] [2M]
< --- and so on for 14 more pages --->
X: OUT_RING: updated data
X: OUT_RING: Exit

Trace of Pushbuf Memory Access, Xen-BOOT:
X: OUT_RING: Enter: chan=0x8170a0, id=2, data=0x44000, chan->cur=0x7f98838df000
kernel: [TTM] FAULTing-in address=0x7f98838df000, bo->buffer_start=0x0
kernel: [BEFORE]PFN: 0x16042 PTE: 0x10000068042067
(val:10000068042067): [mfn:426050->ffff880016042000USR RW
   x  ] [4K]
kernel: [   AFTER]PFN: 0x16042 PTE: 0x10000068042067
(val:10000068042067): [mfn:426050->ffff880016042000USR RW
   x  ] [4K]
kernel: [BEFORE]PFN: 0x16043 PTE: 0x10000068043067
(val:10000068043067): [mfn:426051->ffff880016043000USR RW
   x  ] [4K]
kernel: [   AFTER]PFN: 0x16043 PTE: 0x10000068043067
(val:10000068043067): [mfn:426051->ffff880016043000USR RW
   x  ] [4K]
< --- and so on for 14 more pages --->
< --- and repeat fault --->
kernel: [TTM] FAULTing-in address=0x7f98838df000, bo->buffer_start=0x0

Do you know what is happening? Is a solution feasible?

Sequence of nouveau operation as I understand it:
1. prepare for user pushbuf write by grabbing memory access rights
(exclude GPU access)
2. Do the write
3. finish and release grab

The memory may/maynot be on the video card. There is a vram_pushbuf
module option which would probably complicate things more. GPU is
informed about the address, I suppose,
in the prepare and finish pre/postamble to RING access.

and, THANKS hugely for your help.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel