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

[feral <blistovmhz@xxxxxxxxx>]

So next question then.  How did IOMMU work before these checks if I'm
affected by the latter bug, where the ID simply isn't listed?  Did we
fall back on global pool anyway?

On Tue, May 28, 2013 at 11:25 AM, David Sutton <kantras@xxxxxxxxx> wrote:
> Feral,
>
>
> On Tue, May 28, 2013 at 12:40 PM, feral <blistovmhz@xxxxxxxxx> wrote:
>>
>> I agree entirely about who should be taking responsibility, but we all
>> know of course, that Asus will never fix this.  There are probably
>> less than 5000 people in the world affected by this, and if we assume
>> most of them will still buy Asus's next board that has working IVRS
>> tables, Asus doesn't care.
>>
>> I'm more interested in knowing why the
>> "iommu=no-amd-iommu-perdev-intremap" option doesn't cover my issue
>> though.  It seems odd to me that this option was implemented precisely
>> to work around the regression issue, but somehow it didn't catch them
>> all.  Goddamn I can't wait for the Xen Documentation to take form :)
>>
>
> The problem is that there were two issues which were identified, and that
> flag only deals with one of them; the first issue is where the IVRS has two
> entries for the IO-APIC (for NB and SB) but has the same id listed for both
> (causing a conflict). This means you can't split across the different
> IO-APICs because its not sure which is which - the option allows it to use a
> global pool, decreasing security but allowing things to work. The second
> issue is where the IVRS table doesn't have a valid id listed for the IO-APIC
> at all. This second case, because there isn't an id listed, is the one where
> it just disables AMD-Vi support.
>
> Regards,
>
>   David



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

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