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

[Xen-devel] Re: [PATCH] AMD IOMMU: Fix an interrupt remapping issue

To: "Wei Wang2" <wei.wang2@xxxxxxx>
Subject: [Xen-devel] Re: [PATCH] AMD IOMMU: Fix an interrupt remapping issue
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 08 Apr 2011 14:43:57 +0100
Cc: Boris Ostrovsky <boris.ostrovsky@xxxxxxx>, Wei Huang2 <Wei.Huang2@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 08 Apr 2011 06:44:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <201104081335.36718.wei.wang2@xxxxxxx>
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: <201104081335.36718.wei.wang2@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 08.04.11 at 13:35, Wei Wang2 <wei.wang2@xxxxxxx> wrote:
> Some device could generate bogus interrupts if an IO-APIC RTE and an iommu 
> interrupt remapping entry are not consistent during 2 adjacent 64bits IO-APIC 
> RTE updates. For example, if the 2nd operation updates destination bits in 
> RTE for SATA device and unmask it, in some case, SATA device will assert 
> ioapic pin to generate interrupt immediately using new destination but iommu 
> could still translate it into the old destination, then dom0 would be 
> confused. To fix that, we sync up interrupt remapping entry with IO-APIC IRE 
> on every 32 bits operation and foward IOAPIC RTE updates after interrupt 
> remapping table has been changed. 

I don't think this is correct: Without the patch, the filling of ioapic_rte
takes into account the value already written. Now that you only write
the value at the end of the function, you should overwrite the
affected half with "value" immediately before calling
update_intremap_entry_from_ioapic(). (Without knowing which half
gets written, passing "value" to update_intremap_entry_from_ioapic()
is pointless, and indeed the function doesn't use that parameter.)

Eliminating the double write if reg == rte_lo would also seem desirable
(and in no case should you write back the old value after having called
update_intremap_entry_from_ioapic()).

Jan


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