From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suravee Suthikulpanit Subject: Re: [PATCH 1/2 v5] iommu/amd: Fix logic for clearing the IOMMU interrupt bits Date: Wed, 12 Jun 2013 20:44:17 -0500 Message-ID: <51B923F1.7000802@amd.com> References: <1370840751-11277-1-git-send-email-suravee.suthikulpanit@amd.com> <51B5CCF002000078000DC9A5@nat28.tlf.novell.com> <20130610121855.GE8802@ocelot.phlegethon.org> <51B5E58802000078000DCA7E@nat28.tlf.novell.com> <51B6E40A02000078000DCF6C@nat28.tlf<51B6E40A02000078000DCF6C@nat28.tlf.novell.com> <51B7ACB5.7070805@amd.com> <51B8303302000078000DD6B6@nat28.tlf.novell.com> <51B8F814.70202@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51B8F814.70202@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: "Shin, Jacob" , xen-devel@lists.xen.org, Tim Deegan , "Hurwitz, Sherry" List-Id: xen-devel@lists.xenproject.org On 6/12/2013 5:37 PM, Suravee Suthikulpanit wrote: > On 6/12/2013 1:24 AM, Jan Beulich wrote: >>> If more entries are added to the event log during the time that event >>> log interrupt is disabled (in the control register), >>> the IOMMU hardware will generate interrupt once the the interrupt >>> enable >>> bit in the control register changes from 0 to 1 and set the status >>> register. Since the "iommu_interrupt_handler" code is already calling >>> "schedule_tasklet", we should not need to "re-schedule" tasklet here. >>> I have confirmed the hardware behavior described with the hardware >>> designer. This is also the same on the PPR log. >> And also the same between v1 and v2 hardware? Again, I'd like to >> be on the safe side, and rather do a reschedule too much than one >> too little. And in any case, having your documentation made more >> precise in these respects would be much appreciated. >> >> Jan >> >> > Understand. I apologize if the AMD IOMMU specification does not > describe the behavior quite clearly. Let me know if I could help > clarifing any issues with the hardware designers. > > Since we are modifying the IOMMU interrupt enabling/disabling, I have > been doing some more testing on the IOMMU interrupt handling. I found > that IOMMU MSI interrupt is currently broken, but I think this is > because of some older changes. I am still tracking down the issue, > and will update my findings. > > Thank you, > > Suravee The following commit broke the IOMMU MSI interrupt: 2012-11-28 899110e3f6d2a191638e8b50a981c551eeec49e6 AMD IOMMU: include IOMMU interrupt information in 'M' debug key output (http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=899110e3f6d2a191638e8b50a981c551eeec49e6) This patch also need the following patch to resolve kernel panic: c759fee45bf44f2947a3480d54c03ff7e028c39e AMD IOMMU: add locking missing from c/s 26198:ba90ecb0231f (http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=c759fee45bf44f2947a3480d54c03ff7e028c39e) I'll update once I root cause the issue. Suravee > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >