[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Spinlock inversion in amd/iommu_init


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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.