RE: [PATCH v2 10/13] x86/irq: Extend checks for pending vectors to posted interrupts

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


> From: Jacob Pan <jacob.jun.pan@xxxxxxxxxxxxxxx>
> Sent: Saturday, April 6, 2024 6:31 AM
> During interrupt affinity change, it is possible to have interrupts delivered
> to the old CPU after the affinity has changed to the new one. To prevent lost
> interrupts, local APIC IRR is checked on the old CPU. Similar checks must be
> done for posted MSIs given the same reason.
> Consider the following scenario:
> 	Device		system agent		iommu		memory
> 2			Interrupt request
> 3						Fetch IRTE	->
> 4						->Atomic Swap PID.PIR(vec)
> 						Push to Global
> Observable(GO)
> 5						if (ON*)
> 	i						done;*

there is a stray 'i'

> 						else
> 6							send a notification ->
> * ON: outstanding notification, 1 will suppress new notifications
> If the affinity change happens between 3 and 5 in IOMMU, the old CPU's
> posted
> interrupt request (PIR) could have pending bit set for the vector being moved.

how could affinity change be possible in 3/4 when the cache line is
locked by IOMMU? Strictly speaking it's about a change after 4 and
before 6.

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux