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


[Xen-devel] Re: VGA passthrough on unstable

Hi all,
Im trying to get VGA passthrough working for Nvidia GTX460 (like u), but i
can't apply any patches without errors... im following these steps:
and using those patches, but I am only able to apply the first and the third
patch succesfully while the others seems to not fit with the actual version
of xen-unstable code 
(Some Hunks say succeed and some say failed, for example the 4th patch
(hvmloader.patch) returns
   # patch -p0 < hvmloader.patch
  patching file tools/firmware/hvmloader/hvmloader.c
  Hunk #1 succeeded at 114 with fuzz 2 (offset -1 lines).
  Hunk #2 FAILED at 220.
  Hunk #3 succeeded at 436 (offset -257 lines).
  1 out of 3 hunks FAILED -- saving rejects to file

the path "makefile" neither works.. )
Also i have tried to use the patches that Mr Teo En Ming attach at the end
of this post
but I've got similarly errors..

Could you post how do you proceed to make this patches work? Did u make your
own patches?
I really need to make this work.. 

Thank you for your time.

Pasi Kärkkäinen wrote:
> 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]
> Hmm.. 
> 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
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

View this message in context: 
Sent from the Xen - Dev mailing list archive at Nabble.com.

Xen-devel mailing list