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] Nouveau on dom0

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] Nouveau on dom0
From: Arvind R <arvino55@xxxxxxxxx>
Date: Wed, 3 Mar 2010 22:41:19 +0530
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 03 Mar 2010 09:12:01 -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=+qwsEjfnoYDkutTE2Pe6yM2FbLZC3MuqjgGvOoI2RJo=; b=C3SkM/VDbq/J3tCjjqq5qmlP3eUwN/0vvib5zR+q4YtTpvSurn+numRCCItP1R6KLM fZQAqmeTVXTljWNLVDr40isIfADr42Lej4q24rh4pn1x0Bz8gzKBnGJShGEklz+5T5p/ YGUfBnisIs+Za1Fr2DT0HXI5Osb0AKOPbHlBE=
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=tWXX/v2GC5TGs/kbIdeLxkmzHPx0H02xr8JLr0God9B0m9rPim0sPJvbTQL35hzfLR zbIj165OACd7F7+pEjIcnOHpbOA/XLBTE5LRgOWf1xw+5NyjkNAZjWInr3CrYM146Lrc ptmX6cMwOvqDh/hCi1vGBPesDHrAM4JyiuLeI=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <d799c4761003021334t58815ed3p96dc343635b2da2c@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: <d799c4761002250046j4fc14785ue17db46d6e3e71ce@xxxxxxxxxxxxxx> <20100225125552.GC9040@xxxxxxxxxxxxxxxxxxx> <d799c4761002250901g6029a69et21fcf1d8556f047@xxxxxxxxxxxxxx> <20100225174411.GA13270@xxxxxxxxxxxxxxxxxxx> <d799c4761002260734j13bc01e3vfd7788b6196230ea@xxxxxxxxxxxxxx> <20100301160130.GB7881@xxxxxxxxxxxxxxxxxxx> <d799c4761003021334t58815ed3p96dc343635b2da2c@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, Mar 3, 2010 at 3:04 AM, Arvind R <arvino55@xxxxxxxxx> wrote:
> On Mon, Mar 1, 2010 at 9:31 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx> wrote:
>> On Fri, Feb 26, 2010 at 09:04:33PM +0530, Arvind R wrote:
>>> On Thu, Feb 25, 2010 at 11:14 PM, Konrad Rzeszutek Wilk
>>> <konrad.wilk@xxxxxxxxxx> wrote:
>>> > On Thu, Feb 25, 2010 at 09:01:48AM -0800, Arvind R wrote:
>>> >> On Thu, Feb 25, 2010 at 6:25 PM, Konrad Rzeszutek Wilk
>>> >> <konrad.wilk@xxxxxxxxxx> wrote:
>>> >> > On Thu, Feb 25, 2010 at 02:16:07PM +0530, Arvind R wrote:
>>> >> >> I merged the drm-tree from 2.6.33-rc8 into jeremy's master 
>>> >> >> and
>>> >> ======= snip =======
>>> >> > is not. Would it be possible to trace down who allocates that *chan? 
>>> >> > You
>>> >> > say it is 'PRAMIN' - is that allocated via pci_alloc_* call?
>>> ======= snip =======
>>> >> So, there must be a mmap call somewhere to map the area to user-space
>>> >> for that problem write to work on non-Xen boots. Will try track down 
>>> >> some more
>>> >> and post. With mmaps and PCIGARTs - it will be some hunt!
>>>  ======= snip =======
>>> > to the drm_radeon driver which used it as a ring buffer. Took a bit of
>>> > hoping around to find who allocated it in the first place.
>>> >
>>> The pushbuf (FIFO/RING) is the only means of programming the card DMA

>> the 'ttm_bo_init'. I remember Pasi having an issue with this on Radeon
>> and I provided a hack to see if it would work. Take a look at this
>> e-mail:
>> http://lists.xensource.com/archives/cgi-bin/extract-mesg.cgi?a=xen-devel&m=2010-01&i=20100115071856.GD17978%40reaktio.net

>> It looks to be using 'ioremap' which is Xen safe. Unless your card has
>> an AGP bridge on it, at which point it would end up using
>> dma_alloc_coherent in all likehood.

Can't do that - some later allocations are huge.

>>> As of now, accelerator on Xen stops right at the initialisation stage - when

>> I think that the ttm_bo calls set up pages in the 4KB size, but the
>> initial channel requests a 64KB one. I think it also sets up

> Your ttm patch using dma_alloc_coherent instead of alloc_page resulted in
> the same problem as with the Radeon report - leaking pages, erroneous page 
> count

>> page-table directory so that when the GPU accesses the addresses, it
>> gets the real bus address. I wonder if it fails at that thought -
>> meaning that the addresses that are written to the page table are
>> actually the guest page numbers (gpfn) instead of the machine page numbers 
>> (mfn).
> No, I don't think thats how it works. The user-space write triggers an
> aio-write -

which triggers do_page_fault, handle_mm_fault, do_linear_fault, __do_fault
and finally ttm_bo_vm_fault.
ttm_bo_fault returns VM_FAULT_NOPAGE

 - but xen-boot keeps on re-triggering the same fault.
when vm_fault calls ttm_tt_get_page, the page is already there, and
the handler does another vm_insert_page (i changed vm_insert_mixed
vm_insert_page/pfn based on io_mem, now the only patch, and it works on
bare machine) on and on and on.

What can possibly cause the fault-handler to repeat endlessly?
If a wrong page is backed at the user-address, it should create bad_access or
some other subsequent events - but the system is running fine minus all local
consoles! If the insertion is to a wrong place, this can happen; but
the top-level
trap is the only provider of the address - and the fault addres and
vma address match,
and the same code works fine on bare-boot.

ttm_tt_get_page calls alloc in a loop - so it may allocate multiple pages from
start/end depending on Highmem memory or not - implying asynchronous allocation
and mapping.

All I want now is *ptr = (uint32_t)data to work as of now!

Xen-devel mailing list