From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Spinlock inversion in amd/iommu_init Date: Thu, 18 Dec 2014 18:02:57 +0000 Message-ID: <549316D1.4060707@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Suravee Suthikulpanit , Aravind Gopalakrishnan Cc: Jan Beulich , Xen-devel List List-Id: xen-devel@lists.xenproject.org Hi, XenServers Coverity scanning has identified a spinlock inversion, where enable_iommu() takes the iommu lock and irq_desc lock in an opposite order to the rest of the interrupt handling. (I suspect Coverity Scan is not identifying this as it is not configured to perform function pointer analysis.) This codepath is used during boot, and on resume from S3, and presumably has not been hit in practice as the irq_desc lock is only taken when interrupts from the IOMMU are quiesced. In terms of fixing the locking inversion, I think the affinity setting part of enable_iommu() can safely move to set_iommu_interrupt_handler(). Having said that, it occurs to me that nothing currently changes the msi affinity at all, as cpus come up and down. Furthermore, it seems unwise to have the affinity any bigger than the local numa set anyway, as this interrupt is specifically not associated with a vcpu. ~Andrew