Re: [Xen-devel] [PATCH] IOMMU: don't disable bus mastering on faults for devices used by Xen or Dom0

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.11.12 at 10:44, Tim Deegan <tim@xxxxxxx> wrote:
> At 09:08 +0000 on 06 Nov (1352192909), Jan Beulich wrote:
>> >>> On 05.11.12 at 18:15, Keir Fraser <keir@xxxxxxx> wrote:
>> > On 05/11/2012 16:53, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> > 
>> >> Under the assumption that in these cases recurring faults aren't a
>> >> security issue and it can be expected that the drivers there are going
>> >> to try to take care of the problem.
>> >> 
>> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> > 
>> > Solving an observed problem?
>> 
>> In the context of analyzing the situation described in
>> "iommu=dom0-passthrough behavior"
>> (http://lists.xen.org/archives/html/xen-devel/2012-11/msg00140.html)
>> I suppressed the IOMMU setup for some device in Dom0, and
>> was quite puzzled to find that only a single fault would occur.
> 
> I think it would be better to allow some small number of faults per
> device before disabling it rather than give dom0 carte blanche.
> 
> This check is really there to stop a mad device from hosing the system
> rather than to contain a malicious OS, and a properly out-of-control
> device needs to be stopped or it will livelock Xen with iommu faults.
> In a uniprocessor system, dom0 might never get the chance to fix it.

If that's the main goal, then on the AMD side the code may not do
what you want it to: PPR log entries, causing interrupts too, don't
get limited/suppressed in any way, yet are obviously to some
extent under guest control.

But yes, for the purpose here limiting the fault rate in some way
(with a slightly higher limit for Dom0 than DomU-s) would indeed
be the better route.

Jan


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