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

[Xen-users] Re: Second Dom0-like DomU with graphics hardware access


  • To: xen-users <xen-users@xxxxxxxxxxxxxxxxxxx>
  • From: Paul Schulze <avlex@xxxxxxx>
  • Date: Fri, 8 Aug 2008 03:58:51 +0200
  • Delivery-date: Thu, 07 Aug 2008 19:26:04 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:content-type:message-id :content-transfer-encoding:from:subject:date:to:x-pgp-agent:x-mailer :sender; b=GPEHeBjCk0Y4rhP4M0CTNk2mOOC4n8PLYUYthZkLBBG5uzAnQRNQ61hCZvqppQMkGe 1CHAl7/XwNAz0wzIG2H7BlTVoauPaimhy8ST6cTw2764DXuPzMEIa3zug4okrFyz26RL n/lfDpszqFeacXUOCTJcwKXf/J06KU7yd0i5M=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey everyone,

This is a little followup on my previous messages, to let you know what I found out until now. I haven't really solved any of these problems, but I am getting closer and I wanted to let you guys know what I found out in case someone wants to try or has an idea here.

Am 01.08.2008 um 21:26 schrieb Paul Schulze:

First, I think I just more or less succeeded on passing my primary (and only) graphics card, an onboard ATI Radeon HD3200, through to a DomU. Or at least there is no error message stating otherwise, when I start the DomU and the device is shown when lspci is used. Before someone gets too excited, Xorg still complains about not finding the device and the output from booting the Xen kernel is still the only thing, displayed on the connected monitor.

I managed to make Xorg detect the card by simply fixing arch/x86/mm/ hypervisor.c with having it export xen_invlpg_mask in the Ubuntu source package. I think this was also making trouble for people using the fglrx driver in Dom0, so here is the patch for the Ubuntu source package (might work with other systems too):

- --- debian/binary-custom.d/xen/patchset/005-xen-fglrx-fix.patch - ------------------------------------ diff -Naur linux-2.6.24.orig/arch/x86/mm/hypervisor.c linux-2.6.24/ arch/x86/mm/hypervisor.c - --- linux-2.6.24.orig/arch/x86/mm/hypervisor.c 2008-08-07 03:36:57.000000000 +0200 +++ linux-2.6.24/arch/x86/mm/hypervisor.c 2008-08-07 03:38:32.000000000 +0200
@@ -157,6 +157,7 @@
        set_xen_guest_handle(op.arg2.vcpumask, mask->bits);
        BUG_ON(HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF) < 0);
 }
+EXPORT_SYMBOL(xen_invlpg_mask);

 #endif /* CONFIG_SMP */

- --- End 005-xen-fglrx-fix.patch - ------------------------------------------------------------------------ - -------

This actually enables me to load the closed source kernel module, which at the moment seems to be the only device driver in the Ubuntu repositories that really recognizes my onboard ATI Radeon HD3200 (the AMD 780G chipset was released in May, Ubuntu 8.04 in April, so its no surprise that neither the radeonfb nor radeon(hd) drivers find it). I am not sure why VESA mode isn't working, but I suspect that there are interface parts from the system BIOS needed and I highly doubt that Xen provides those (or Asus just skipped the VESA BIOS on my board). I also passed the PCI-to-PCI bridge for the graphics card along to the DomU, whereby I am not so sure if that is really needed. The problem now is, that I don't get any output on the monitor and the X server fails with:

(II) LoadModule: "vgahw"
(II) Loading /usr/lib/xorg/modules//libvgahw.so
(II) Module vgahw: vendor="X.Org Foundation"
        compiled for 1.4.0.90, module version = 0.1.0
        ABI class: X.Org Video Driver, version 2.0
(II) fglrx(0): PCI bus 0 card 5 func 0
(**) fglrx(0): Depth 24, (--) framebuffer bpp 32
(II) fglrx(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
(==) fglrx(0): Default visual is TrueColor
(II) fglrx(0): PCS database file /etc/ati/amdpcsdb not found
(II) fglrx(0):   Creating PCS database from initial defaults instead
(==) fglrx(0): RGB weight 888
(II) fglrx(0): Using 8 bits per RGB (8 bit DAC)
(==) fglrx(0): Gamma Correction for I is 0x06419064
(==) fglrx(0): Gamma Correction for II is 0x06419064
(==) fglrx(0): Buffer Tiling is ON
(--) fglrx(0): Chipset: "ATI Radeon HD 3200 Graphics" (Chipset = 0x9610)
(--) fglrx(0): (PciSubVendor = 0x1002, PciSubDevice = 0x0000)
(--) fglrx(0): board vendor info: original ATI graphics adapter
(--) fglrx(0): Linear framebuffer (phys) at 0x40000000
(--) fglrx(0): MMIO registers at 0x50000000
(==) fglrx(0): ROM-BIOS at 0x000c0000
(WW) System lacks support for changing MTRRs

Fatal server error:
xf86MapVidMem: Could not mmap framebuffer (0x000a0000,0x20000) (Bad address)

The same error message has been reported about 2 months ago (on this list I believe) for a NVidia graphics adapter, which sounds to me like it is a "problem" with Xen, rather than the closed source driver. If anyone knows of a way to fix this, please let me know.

Now the first question is, does anyone have an idea on how to prevent Xen from grabbing and writing its output to the VGA hardware, if it should already have a serial console to work with? I am assuming, that even if I have the kernel output to the serial console and have pciback hide the graphics card, Xen still hands the graphics card directly to the Dom0, if it shows its messages on one and the kernel grabs it, even if it isn't needed for output. This might cause Xorg in the DomU not to find the device. If this isn't the problem here, does anyone have any ideas on what is going wrong?

To not have Xen output on the VGA hardware, the console=com1 is also needed in addition to the com1= parameter for Xen, since the default seems to be to use VGA hardware above everything else. I am not sure if the graphics card isn't still being grabbed by something though, since it is showing an empty screen with a text mode cursor blinking in the upper left corner. This would also explain the above Xorg error message, but I am really not sure about this. Opposing it would be the fact, that I tried to send text to every console, available in /dev in Dom0 and DomU and nothing got printed, which for me would be to be expected if all the console devices in the Xen DomU are fake except for xvc0. For now, I have Grub, Xen and Linux output to com1/ ttyS0 and switched all the VMs to use ttyS for console output too (though I am not sure if this is correct, but just to be safe for testing). Did I miss anything here?

The second question is, does anyone know if it is possible to have PS2 devices (aka. keyboard and mouse) exclusively assigned to one DomU? I would really like to separate the VM, controlling Xen and my desktop VM for various reasons (f.e. to not have to restart every DomU along with the Dom0, if the desktop system receives an update, security and so on). Since I can use the serial console from another device to control Xen (or use SSH), I really don't need keyboard and mouse in the Dom0 and having PS2 support in the Desktop DomU would be just nice, especially since I'm a little short on USB input devices right now, so the USB controllers, I passed to the same DomU aren't much help.

Nothing new here, I am still trying to figure out the best way to work around the limitations, but apparently, USB is the only choice here for now. Guess its time to buy a new keyboard.

And the third problem, I am facing at the moment, I still don't get the boot output or any login prompt on the connected monitor, probably because the TTYs are fake in a Xen DomU. Is there a way to have these connect to the real VGA adapter instead?

Nothing new here either, any hint would be appreciated. If someone has an idea on one or more of these problems, please let me know.

Thanks.


Paul.

P.S.: Oh yeah, while I was on my crazy PCI passthrough run, I also managed to pass the onboard sound device(s) to the desktop DomU. The board is an Asus M3A-H/HDMI with AMD 780G chipset. The sound seems to be working rather well I'd say.
- --
Paul Schulze
avlex@xxxxxxx
Public Key: http://solaris-net.dyndns.org/keys/key_avlex.asc

"Making mistakes is human,
but to really fuck things up you need Computers"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFIm6hcYDWOGtiChoARAh4GAJ0admT+/ZuMSAzpB0NxKVQbvXvuTQCdEiZv
RX3KKTT5X1n5CWnPuZqXC64=
=L3nW
-----END PGP SIGNATURE-----

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


 


Rackspace

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