[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] IOMMU: don't disable bus mastering on faults for devices used by Xen or Dom0
>>> On 06.11.12 at 14:58, Tim Deegan <tim@xxxxxxx> wrote: > At 12:51 +0000 on 06 Nov (1352206269), Jan Beulich wrote: >> >>> On 06.11.12 at 13:06, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote: >> > On Tue, 2012-11-06 at 09:44 +0000, Tim Deegan wrote: >> >> > 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. >> >> >> > Right. But moving the fault handling code to softirq should have already >> > helped solving/mitigating that, hasn't it? >> >> It helps keeping Xen alive, but doesn't for any specific domain >> (including Dom0). > > Indeed. (Intel) IOMMU interrupts are suppressed until the softirq > handler acknowledges the error, but if the softirq handler doesn't > disable the device, it will take another IOMMU interrupt immediately. > I thought the AMD side behaved eth same but clearly not -- I'll try to > take a look at that later in the week. I don't think AMD's behaves much different, it's just that for the PPR case nothing is being done in that regard (and it's unclear whether or under what circumstances a high rate of these could occur). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |