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

Re: [Xen-users] VGA passthrough: "invalid access size alignment" solution?

On Tue, May 5, 2015 at 7:22 AM, Zytaruk, Kelly <Kelly.Zytaruk@xxxxxxx> wrote:

>From: Scott Helvick [mailto:scott.helvick@xxxxxxxxx]
>Sent: Tuesday, May 05, 2015 3:38 AM
>To: xen-users@xxxxxxxxxxxxx; Zytaruk, Kelly
>Subject: VGA passthrough: "invalid access size alignment" solution?
>** Not on mailing list, please CC, thanks. **
>Hey folks, I'm trying to pass through a Radeon R9 290X to Win7 and running into these infamous errors:
>pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
>I'm getting similar errors with both qemu-dm and qemu-xen-traditional. This is on Xen 4.4.2 and kernel 3.18.10.
>Kelly -- I'm including you because AFAICT you're one of the most recent people to have worked on this (http://lists.xen.org/archives/html/xen-devel/2014-04/msg01510.html) and potentially figured it out >(http://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters). The wiki claims you got it working on Xen 4.2 and kernel 3.4.9; can you say more about what's different in that config and whether you checked with any >newer Xens/kernels?
>Pointers from anyone else are welcome too, of course. Otherwise, I'll do my best to dig in and report any findings back to the group.


From my testing I was able to trace the request back to the Win 7 guest OS request. I don't know why the OS is making a 4 byte request on a 2 byte boundary. I did not dig any deeper than that. From my testing it appeared that the error message was a red-herring as it was not the root of my problem and I can successfully pass through devices while still seeing these error messages.

If anyone is interested in finding the root of the problem my suggestion would be to continue where I left off. You will have to 'hack' around a bit. I used Windbg in the Win7 guest and you can either use Xenctx or incorporate the same API that Xenctx uses in QEMU to try and dump a stack trace when the error occurs. Once you have a stack trace you can reflect it back to actual functions back in the Windbg session. It gets a bit tricky if you pause the guest because the Windbg session will also freeze.

I imagine that there must be some way of taking a 'snap-shot' of the guest when the error occurs and debugging the snap-shot but I don't know how to do that. If anyone can provide instructions on how to do that I would really love to learn how to do it.

My problem was related to the VBios of the secondary adapter not being posted properly. When the adapter is set as the primary the VBios is posted by the SBios. On the other hand when the adapter is set as the secondary the adapter relies on the video driver to post the VBios. Make sure that you have up to date video drivers to support your card.


Circling back for the benefit of others.

Kelly's answer seems to be correct (thanks!) in that this error message is a red herring -- or at worst, a non-showstopper bug. Getting the drivers installed was a non-trivial process involving a few crashes/incomplete installs; I couldn't tell if the eventual success was due to multiple partial installs or just a stroke of luck that the VM didn't crash for the fourth time. But once that worked, I ran some benchmarks which looked solid, and the video has been at least mostly stable ever since.

Xen-users mailing list



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