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

Re: [Xen-users] Xen IOMMU disabled due to IVRS table... Blah blah blah



FYI, I finally got a response from Asus Engineering.  Unfortunately they're all speaking something I am not, so we had to do 3 layers of translation both ways to get it done, but I believe the issue may now be resolved.
I sent them the ACPI dump and gave them the correct addresses for IOMMU 1 and 2 (or 0 and 1?).
I'm in the middle of moving into my new place, so haven't had a heap of time to test yet, but passthrough did work correctly (HDMI audio even works now) and no errors in dmesg.  I'm currently testing with KVM.

So that said, attached is the test BIOS we got hacked together.  Flash at your own risk.  I'm running it without any noticeable issues, but as I said, I haven't had time to do any rigorous testing or deep eval. on the actual IOMMU addresses (ie: haven't dumped ACPI/IVRS yet to confirm anything).




On Mon, Jul 15, 2013 at 4:14 PM, gizmochicken <gizmochicken@xxxxxxxxx> wrote:
I haven't yet tried it with vanilla Xen, but at least with XenServer 6.2 (which relies on Xen 4.1.5), IOMMU can be forced to initiate on my Asus M5A99FX Pro R2.0 motherboard (which suffers from an erroneous IVRS table) using the following:

      iommu=no-intremap

More information about this option, which seems to have been released for Intel setups, can be found here:  http://support.citrix.com/article/CTX136517







On Tue, May 28, 2013 at 12:49 PM, feral <blistovmhz@xxxxxxxxx> wrote:
> In my case, the handle id is wrong ( you can see what it should be on the
> support document http://support.amd.com/us/Processor_TechDocs/48882.pdf -
> per tables 77/79 it should be the ID of the IO-APIC). Unlike the conflict
> error, which can be worked around by passing another command line option,
> invalid IO-APIC entries in the IVRS table will always cause AMD-Vi to fail
> to be enabled if you have the XSA-36 patch installed.

This is the part I have an angry nerd rage issue with.  I'm pretty
sure I fall into the latter category where there is no option to
forcibly enable IOMMU.  I'd understand if the patch wasn't actually
removing functionality but in our case, it seems the patch does just
this even though the "bug" being addressed doesn't concern me (and
probably quite a few others) whatsoever.  The machine in question is
my gaming rig primarily, and gets a lot of use in QA, but nothing
mission critical.  I'd rather hobble along with a known bad IVRS table
if it has no affect on my work (or games) than be locked out entirely
:p.

I'm still a little confused though as I've heard a few people say that
this patch wasn't introduced until Xen 4.2 but I saw the issue first
pop up in Xen 4.1.2 and later.  Am I even looking at the right bug?
And what options are available to forcibly disable the checks other
than the "iommu=no-amd-iommu-perdev-intremap" ?




--
_____
Fact:
1. Ninjas are mammals.
2. Ninjas fight ALL the time.
3. The purpose of the ninja is to flip out and kill people.

Attachment: SABERTOOTH-990FX-R20-ASUS-9901.CAP
Description: Binary data

Attachment: SABERTOOTH-990FX-R20-ASUS-9901.ROM
Description: Binary data

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

 


Rackspace

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