[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Nouveau on dom0

  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: Arvind R <arvino55@xxxxxxxxx>
  • Date: Thu, 25 Feb 2010 14:16:07 +0530
  • Delivery-date: Thu, 25 Feb 2010 00:46:29 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Ut2WLCpupIKmduc5vr7JPbDL3Tp1ugChSAW5GfsDRLPz1UoHeD3hGZUi6kb3p7I5eR 0U14EmA1J6aBz6u2f10AtRMu9voV3dxbOvXy2pZLK9tbTJfw3efPVZCbzrY2wbPBR/1U Kczuy7NPvYuRXm3VQRGIBW63qjjUHr1w+jk7Q=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Hi all,
I merged the drm-tree from 2.6.33-rc8 into jeremy's master and
got X working on dom0 - but only with option "ShadowFB" set. Using Xorg-7.5,
mesa-git, libdrm-git xf86-video-nouveau-git, xen-testing-git and
qemu-dm-git. Ensured dependencies by deb-packaging everything. Kernel
built without drm and the nouveau driver built as a separate
out-of-tree modules package- to ensure
correct ttm modules. Tried WinXP and debianetch domUs - which worked fine.

On bare-metal boot, everything works - even 3D accelerated rendering. But
when booted on Xen, X works ONLY - as mentioned - with ShadowFB set,
which in turn, turns off even 2D acceleration. The only difference in the boots
is that bare-metal boot has 2GB RAM whereas dom0 has 512M. The graphics
card is a nVidia GeForce 9400GT, and the distro is basically debian lenny.

Turned debug on in the nouveau driver and patched some into libdrm and
compared the outputs on bare-metal and xen boot. Identical output upto
problem point - only differing fields were time-stamp, process pid, and
grobj allocation addresses.

Problem Point:
libdrm has an inlined function OUT_RING, defined in
static __inline__ void
OUT_RING(struct nouveau_channel *chan, unsigned data)
    *(chan->cur++) = (data);
- chan->cur is a uint32_t *

The function is entered by X through ScrnInit in the DDX driver.
Patched log-message on entry is written to syslog, and then -
X seems to get suspended. chan->cur can be read on entry,
so (assumed) suspension is on write. System loses consoles,
but can be ssh'ed into - no killed processes, no segfault.

The area pointed to be the pushbuf - which is apparently the
PRAMIN area on the graphics card. Modern graphics is not
my forte - so I am seeking some pointers to resolve this from
anyone. I think that if this is solved, Xen would have open-source
3D-acceleration support! Am game for testing, patching, etc.

I am basically interested in having a develepment domU and
another testing domU without devel-packages.

Arvind R.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.