[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


On Tue, May 28, 2013 at 11:49 AM, 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

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" ?

The issue will occur with both 4.1 and 4.2 - there was a security advisory ( XSA-36 ), the patch for which added in parsing of the IVRS table to validate certain information being returned (such as the IO-APIC details). Patches were released for both 4.1 and 4.2.


Xen-users mailing list



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