> -----Original Message----- > From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Tuesday, June 02, 2015 9:59 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: [v8 3/9] iommu, x86: Implement irq_set_vcpu_affinity for > intel_ir_chip > > On Wed, 27 May 2015, Feng Wu wrote: > > + /* stop posting interrupts, back to remapping mode */ > > + if (!vcpu_info) { > > + modify_irte(&ir_data->irq_2_iommu, &ir_data->irte_entry); > > + } else { > > + vcpu_pi_info = (struct vcpu_data *)vcpu_info; > > + > > + /* > > + * "ir_data->irte_entry" saves the remapped format of IRTE, > > + * which being a cached irte is still updated when setting > > + * the affinity even when we are in posted mode. So this make > > s/make/makes/ > > > + * it possible to switch back to remapped mode from posted mode, > > + * we can just set "ir_data->irte_entry" to hardware for that > > + * purpose. Here we store the posted format of IRTE in another > > + * new member "ir_data->irte_pi_entry" to not corrupt > > Remove the 'another new member' please. That member is not longer new > once that patch is applied. > > Now there is another question. Are we actually using that pi_entry > cached value for anything else than this code here? If not, we can do > this on the stack and avoid the extra storage in ir_data. >
That's a good comments. I also thought about this before. Right now the cached value is only used here in this function, but I am not sure whether we need it in future. Anyway, I think we can delete it now. Thanks, Feng > 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/
