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

[Xen-devel] VGA passthrough on unstable


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: Liwei <xieliwei@xxxxxxxxx>
  • Date: Tue, 3 May 2011 14:29:54 +0800
  • Delivery-date: Tue, 17 May 2011 16:19:53 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=Z3GIewlYvHPS5UJE4d6zGohUuXhscWR7c6iVr5Ixz29bLPvs2reQDRLpNgWu31jnHW ViTKzConJ1sC6FhUvYa7Ku7ajHVbgMZhbqsUIBxnlm/qu8uybl6hQzpLkfMskKm7jphq BNXfkweIWl5vu0tV6Mfen/g/OL8xJ9WC2MDuE=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

(Pardon me if I broke any rules or this post doesn't belong to this list)

I forward patched today's copy of the unstable repo in an attempt to
get VGA passthrough working for a Nvidia GTX460 on a HVM DomU.
(Surprisingly, it wasn't hard at all to get the patches in - getting
them to work is another ongoing story)

The patches were based on this post:
http://wiki.xensource.com/xenwiki/XenVGAPassthrough

I dumped the card's BIOS using nvtool as per the post's instructions.
The only major change was that the BIOS ROM setup code was shifted
into its own file and some adjustment was needed for that. I'll create
a new patchset once I get this fully working. I also hope to push this
into being accepted by the devs for future releases by allowing the
user to configure this option and provide his own BIOS dump (instead
of hardcoding everything).

My card doesn't seem to support FLR, since xend complains about being
unable to reset the device.

With or without the
qemu-claim-cycle-for-secondary-gfx-passthrough.patch, the secondary
graphics card does not show anything at all (maybe because it is
behind a PCI-E bridge?), and xl list seems to show the guest consuming
all CPU resources.

However, using the primary graphics card, again with or without the
secondary passthrough patch, it actually managed to partially work
booting up the Windows 7 install. It manages to reach the pulsating
windows logo before BSOD-ing with 0x0000000A (IRQ_NOT_LESS_OR_EQUAL).
Meanwhile, the logs show a lot of:

    pt_pci_read_config: Error: Failed to read register with invalid
access size alignment. [00:05.0][Offset:0eh][Length:4]
    pt_pci_read_config: Error: Failed to read register with invalid
access size alignment. [00:06.0][Offset:0eh][Length:4]

Reduced the amount of allocated memory to 4096MB will introduce video
corruption in the pulsating logo, followed by the same BSOD.

Reducing the amount of allocated memory to below 2048MB or 1024MB will
cause a 0x000000A5 BSOD (BIOS ACPI not compliant).

Attempting to boot the same setup (with 8192MB of memory) with vCPU
set to 8 produced slightly different behaviour. Qemu seems to crash
and reboot a few seconds after the pulsating windows logo appears
(earlier than before the BSOD appeared before). At this point, it
should be noted that the 8 vCPU and 8192MB configuration worked with
4.0. I couldn't test it in the patched unstable because VNC will only
produce a white screen (wrong VGA BIOS executed?).

Attempting to boot Ubuntu also produced similar results, except the
log now shows errors similar to (I did not copy out the log before
they were overwritten):

    Error: Failed to write register with invalid access size

The boot up seems to fail at trying to read from the emulated SATA
drive though, something about interrupt lost, and keeps on trying
again and again forever.

With the above tests, I also unscientifically fiddled around with the
pci_power_mgmt, pci_msitranslate, hap, hpet, pae, apic, acpi and
viridian toggleable settings.

I made no functional changes to the patches however, so maybe there
was something that I had to change in order to customise it for my
card. It'd be great if someone points that out to me if it is true.

I cannot use my USB keyboard and mouse at all in all my tests with
unstable, USB controller is passed in. USB works on 4.0 in the windows
installer, but I haven't tested them before the installer boots, so it
may be possible that passthrough is broken with my setup (does the
BIOS initialise USB peripherals for use during boot?).

So how should I proceed on from here?

Setup details as follows:

EVGA P55 Classified
Intel i7 860
8GB Memory
2x Palit Nvidia GTX460 (Primary and secondary)

Debian Squeeze
Dom0 is 2.6.32+29 (From repo)

PCI devices (Only those bound to xen_pciback are listed):
(It should be noted that except for the primary GFX, all other devices
are behind a NF200 PCI-E bridge)
0b:00.0 - Secondary GFX
0b:00.1 - Secondary GFX audio
01:00.0 - Primary GFX
01:00.1 - Primary GFX audio
0e:00.0 - Multiport network card
04:00.0 - Singleport network card
00:1a.0 - USB2 root
00:1b.0 - HD audio device
00:1d.0 - USB2 root

PCI devices combinations tested (in each case, the audio is
passthroughed with the GFX):
(OT: Why doesn't multi-device BDF binding work on xen_pciback?)
Primary GFX only
Secondary GFX only
Primary GFX + Secondary GFX
Primary GFX + others
Secondary GFX + others
Primary GFX + Secondary GFX + others

Attached: Log files produced by xend and qemu and config files
(Sorry that only one set of logs are available, wasn't thinking
properly when executing rm *.log)

Attachment: ~qemu-dm-W7Test.log
Description: Binary data

Attachment: ~W7Test.cfg
Description: Binary data

Attachment: ~xend.log
Description: Binary data

Attachment: ~xend-config.sxp
Description: Binary data

Attachment: ~xend-debug.log
Description: Binary data

Attachment: ~xl-W7Test.log
Description: Binary data

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

 


Rackspace

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