> -----Original Message----- > From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Tuesday, May 26, 2015 6:00 PM > To: Wu, Feng > Cc: j...@8bytes.org; dw...@infradead.org; jiang....@linux.intel.com; > io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org > Subject: RE: [v7 4/8] iommu, x86: No need to migrating irq for VT-d > Posted-Interrupts > > On Tue, 26 May 2015, Wu, Feng wrote: > > > On Mon, 25 May 2015, Feng Wu wrote: > > > > + > > > > + /* We don't need to modify irte if the interrupt is for > > > > posting. */ > > > > + if (irte->pst != 1) > > > > + modify_irte(&ir_data->irq_2_iommu, irte); > > > > > > I don't think this is correct. ir_data->irte_entry contains the non > > > posted version, which has pst == 0. > > > > > > You need some other way to store whether you are in posted mode or > > > not. > > > > Yes, seems this is incorrect. Thank you for pointing this out. After more > > thinking about this, I think I can do it this way: > > #1. Check the 'pst' field in hardware > > #2. If 'pst' is 1, we don't update the IRTE in hardware. > > > > However, the question is the check and update operations should be > protected > > by the same spinlock ' irq_2_ir_lock ', otherwise, race condition may > > happen. > > Why? > > set_affinity() and vcpu_set_affinity() are serialized via > irq_desc->lock. And vcpu_set_affinity() is the only way to switch from > and to posted mode.
Oh, Yes, I didn't notice that they are both protected by that lock. In that case, I can just add a filed like you mentioned below. Thanks for the comments! Thanks, Feng > > So all you need is a field in intel_irq_data which captures whether > posted is enabled or not. > > Thanks, > > tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
