From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Nouveau on dom0 Date: Mon, 8 Mar 2010 12:51:27 -0500 Message-ID: <20100308175127.GF4568@phenom.dumpdata.com> References: <20100303181303.GA21078@phenom.dumpdata.com> <20100304182518.GB20263@phenom.dumpdata.com> <20100305202309.GA15454@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Arvind R Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Sun, Mar 07, 2010 at 05:26:12AM +0530, Arvind R wrote: > On Sun, Mar 7, 2010 at 2:29 AM, Arvind R wrote: > > On Sat, Mar 6, 2010 at 1:46 PM, Arvind R wrote: > >> 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: > > >>> (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. > > My typo and testing mistakes. > Patched ttm_bo_mmap > vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND; > if (bo->type != ttm_bo_type_device) > vma->vm_flags |= VM_IO; > > Then, put sleep and exit in libdrm OUT_RING. > The fault-handler worked fine! 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? > > One question - How to get DMA addresses for user-buffers under Xen. This is the X part right? Where the X driver takes control of the GPU and starts having fun? I am not that familiar with how the drm_nouvou module hands over the pointers and such to the X driver? Does it reset it and start from scratch (as if you had no KMS enabled?) Or does it use the allocated buffers and such and then asks for more using ioctl such as DRM_ALLOCATE_SCATTER_GATHER (don't remember if that was the right name). 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. Either way, the PCI DMA API _always_ return the DMA address for pages. So as long as a user-buffer has 'struct page' backing it it should be possible to get the DMA address. Hopefully I've not confused this matter :-( > Will work on that. > > HUGE THANKS! Oh, thank you!