Messages in this thread | | | From | "Wu, Feng" <> | Subject | RE: [v8 3/9] iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip | Date | Wed, 3 Jun 2015 01:05:24 +0000 |
| |
> -----Original Message----- > From: Thomas Gleixner [mailto:tglx@linutronix.de] > Sent: Tuesday, June 02, 2015 9:59 PM > To: Wu, Feng > Cc: joro@8bytes.org; dwmw2@infradead.org; jiang.liu@linux.intel.com; > iommu@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
| |