WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Xen Advisory 5 (CVE-2011-3131) IOMMU fault livelock

To: "Allen M Kay" <allen.m.kay@xxxxxxxxx>
Subject: RE: [Xen-devel] Xen Advisory 5 (CVE-2011-3131) IOMMU fault livelock
From: "Jan Beulich" <JBeulich@xxxxxxxx>
Date: Wed, 21 Sep 2011 07:47:37 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Donald D Dugger <donald.d.dugger@xxxxxxxxx>, "Xen.orgsecurity team" <security@xxxxxxx>
Delivery-date: Tue, 20 Sep 2011 23:47:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <987664A83D2D224EAE907B061CE93D5301EDED333E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20037.10841.995717.397090@xxxxxxxxxxxxxxxxxxxxxxxx> <4E454C880200007800051000@xxxxxxxxxxxxxxxxxxxx> <20110812140901.GC11708@xxxxxxxxxxxxxxxxxxxxx> <4E4559440200007800051062@xxxxxxxxxxxxxxxxxxxx> <20110815092608.GD11708@xxxxxxxxxxxxxxxxxxxxx> <4E4A32650200007800051651@xxxxxxxxxxxxxxxxxxxx> <20110816150621.GM11708@xxxxxxxxxxxxxxxxxxxxx> <4E4AAFF402000078000518CF@xxxxxxxxxxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D5301EDED333E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 21.09.11 at 02:07, "Kay, Allen M" <allen.m.kay@xxxxxxxxx> wrote:
> Catching up on an old thread ...
> 
> If I understand correctly, the proposal is to check for VT-d faults in 
> do_softirq() handler.  If so, we probably don't even need to enable VT-d MSI 
> interrupt at all if iommu_debug is not set, basically handling VT-d faults 
> with polling method.

No, I don't think switching to polling mode was implied here. My thinking
was rather along the lines of a dedicated softirq that the interrupt
handler would raise, for the bulk of the handling to take place there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>