-----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
|
Home