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] VGA passthrough on unstable

To: Liwei <xieliwei@xxxxxxxxx>
Subject: Re: [Xen-devel] VGA passthrough on unstable
From: Pasi Kärkkäinen <pasik@xxxxxx>
Date: Thu, 5 May 2011 18:20:20 +0300
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 05 May 2011 08:21:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BANLkTinrcbm-J6rDzTRQDUyjnKgd_LUwpg@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: <BANLkTi=O1JkLyayYr4gx87QKqbRNRLnGOQ@xxxxxxxxxxxxxx> <BANLkTinrcbm-J6rDzTRQDUyjnKgd_LUwpg@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Thu, May 05, 2011 at 07:33:46PM +0800, Liwei wrote:
> (Pardon me if I broke any rules or this post doesn't belong to this list)
> I forward patched yesterday'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).

Being able to specify which vgabios file to load would be great..
Feel free to send patches!

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


So did you apply the vBar == pBar patches ?
Did you modify them to fit your hardware? 

-- Pasi

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

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

Xen-devel mailing list