From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arvind R Subject: Re: Nouveau on dom0 Date: Sat, 6 Mar 2010 13:46:18 +0530 Message-ID: References: <20100301160130.GB7881@phenom.dumpdata.com> <20100303181303.GA21078@phenom.dumpdata.com> <20100304182518.GB20263@phenom.dumpdata.com> <20100305202309.GA15454@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20100305202309.GA15454@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Sat, Mar 6, 2010 at 1:53 AM, Konrad Rzeszutek Wilk 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 >> 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 >> >> 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 =A0ttm_bo_vm_fault what the > vma->vm_flags are and if VM_IO is set. > > (FYI, look at > http://git.kernel.org/?p=3Dlinux/kernel/git/konrad/xen.git;a=3Dcommit;h= =3De84db8b7136d1b4a393dbd982201d0c5a3794333) 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=3D0x8170a0, id=3D2, data=3D0x48000, chan->cur=3D0x= 7f0aa3594054 kernel: [TTM] FAULTing-in address=3D0x7f0aa3594000, bo->buffer_start=3D0x0 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=3D0x8170a0, id=3D2, data=3D0x44000, chan->cur=3D0x= 7f98838df000 kernel: [TTM] FAULTing-in address=3D0x7f98838df000, bo->buffer_start=3D0x0 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=3D0x7f98838df000, bo->buffer_start=3D0x0 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.