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

Re: [Xen-users] VGA Passthrough / Xen 4.2 / Linux 3.9.2

Hello again, hope this doesn't make it hard to read, I know mobile devices like to top post :)

On Thu, May 16, 2013 at 9:42 AM, Gordan Bobic <gordan@xxxxxxxxxx> wrote:
Apologies, top posting because my mail reader is truncating that previous message
content when replying to it.

I was having issues passing through USB devices, so I figured I'd just pass
the PCI devices that are the USB controllers associated with the relevant ports.
I'll try passing just the USB devices again.

That's a reasonable thing to do, and I have tried it before; I'm just saying that reliability may be hit or miss depending on a variety of circumstances :P

As for the PCI hole - is there a parameter to achieve this on xen? Or a patch
for xen/qemu that fixes the problem?


With the PCI hole thing, when I first started trying to work with IOMMU on an AMD system---though AFAIK the Intel vs. AMD thing doesn't make a difference in VMware land for this particular issue---this workaround was unique to VMware.  It wasn't at all necessary for my Xen VMs on the same physical hardware.

I'm just seeing that, for you, this behavior is eerily similar to a long-standing problem on VMware and may be worth looking at to see if it's a problem here, too. :)

On Thu, May 16, 2013 at 2:25 AM, Gordan Bobic <gordan@xxxxxxxxxx> wrote:

    On 05/16/2013 01:17 AM, Alex Karaoui wrote:

        Aloha Gordon,

        When you say "BSOD on subsequent start-ups," are you saying that on the
        boot after AMD driver installation your system BSODs?  How do you manage
        to get around that, by simply restarting the host?

    What I am referring to is the following:

    1) Boot up host.
    2) Start up domU - works every time now with <= 2GB of RAM (any more 3GB sometimes works. 4GB+ hardly ever gets to the login screen)

I thought I'd write in because I've seen this before.  This behavior....

    3) Shut down domU
    4) At this stage, starting up the domU usually works. Maybe half of the time it BSODs or loses the USB devices (they show up with a yellow exclamation mark in device manager - ejecting them doesn't help).
    5) Repeat from 3) At this point things never get past a BSOD and the only way to get the domU working again is to reboot the host.

    This should now probably become a couple of new threads:
    1) VGA passthrough BSOD-ing with a domU with more than 2GB of RAM

...and more specifically, this behavior---I'm referring to a BSOD that precedes the login screen; before the video driver switches out of the Windows Boot Manager's VGA(?) mode---is eerily similar to a longstanding issue with passing through PCIe devices on ESXi.  The workaround is to configure the VM with a custom PCI Hole mapping; I use "pciHole.start = 1100" and "pciHole.end = 2200", though pretty much any "total" exceeding either 1024 (or perhaps simply the memory total in MB on the PCIe device itself), where 2200-1100 in this case = 1100, just fixes the problem entirely.

I don't know for sure if they're related, but the kicker here is that the workaround is required when and only when passing through a PCIe video card to a VM that has more than 2GB of RAM assigned to it!  The thread on their forums[1] where I first found this some time ago is ~44 pages long.

    2) domU reboots cause USB controllers to become unavailable


I may be getting lost in the email chain, but I think that USB controllers are the one thing I've never had a problem with.  I haven't ever tried attaching an onboard controller though, because every onboard controller I've come across is a regular PCI device... problems passing those are basically to be expected :(

If you want to throw money at that problem, grab a RocketU 1144A or B.  The lspci entries for the device[2] are a passthrough-user's dream come true.

There's also the USB/IP project, but I haven't had a lot of luck with it.  I actually think that it's an ideal solution to passing USB devices, as I've used commercial software that does the same, and it's good enough to connect audio, keyboard, and mouse to machines that are actually on physically different hosts with zero noticeable lag or packet loss.  I'd love to see someone get the F/OSS version working... personally I'd buy the commercial software if it wasn't priced to gouge the crap out of a corporate wallet :(


Just my two cents of course!  I wish I could be a little more helpful here.  I seriously admire your persistence on this issue; I probably would have quit a week ago and just bought something else, and am really happy to see you making progress!

I'm currently ignoring my desktop... I just got a ThinkPad Helix tablet and am focusing on getting Xen to work on it for the time being.

Also, on a side note, I can confirm that my HD 4000 graphics does not support FLR... and appears to be a PCI device :(


Xen-users mailing list



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