[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 11/17] vt-d: Add API to update IRTE when VT-d PI is used
On Wed, Aug 12, 2015 at 10:35:32AM +0800, Feng Wu wrote: > This patch adds an API which is used to update the IRTE > for posted-interrupt when guest changes MSI/MSI-X information. > > CC: Yang Zhang <yang.z.zhang@xxxxxxxxx> > CC: Kevin Tian <kevin.tian@xxxxxxxxx> > CC: Keir Fraser <keir@xxxxxxx> > CC: Jan Beulich <jbeulich@xxxxxxxx> > CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > Signed-off-by: Feng Wu <feng.wu@xxxxxxxxx> > Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> > --- > v5: > - Make some function parameters const > - Call "spin_unlock_irq(&desc->lock);" a little eariler > - Add "ASSERT(spin_is_locked(&pcidevs_lock))" > - -EBADSLT -> -ENODEV, EBADSLT is removed in the lasted Xen > > v4: > - Don't inline setup_posted_irte() > - const struct pi_desc *pi_desc for setup_posted_irte() > - return -EINVAL when pirq_spin_lock_irq_desc() fails. > - Make some variables const > - Release irq desc lock earlier in pi_update_irte() > - Remove the pointless do-while() loop when doing cmpxchg16b() > > v3: > - Remove "adding PDA_MASK()" when updating 'pda_l' and 'pda_h' for IRTE. > - Change the return type of pi_update_irte() to int. > - Remove some pointless printk message in pi_update_irte(). > - Use structure assignment instead of memcpy() for irte copy. > > xen/drivers/passthrough/vtd/intremap.c | 112 > +++++++++++++++++++++++++++++++++ > xen/drivers/passthrough/vtd/iommu.h | 2 + > xen/include/asm-x86/iommu.h | 2 + > 3 files changed, 116 insertions(+) > > diff --git a/xen/drivers/passthrough/vtd/intremap.c > b/xen/drivers/passthrough/vtd/intremap.c > index e9fffa6..8ec85d3 100644 > --- a/xen/drivers/passthrough/vtd/intremap.c > +++ b/xen/drivers/passthrough/vtd/intremap.c > @@ -899,3 +899,115 @@ void iommu_disable_x2apic_IR(void) > for_each_drhd_unit ( drhd ) > disable_qinval(drhd->iommu); > } > + > +static void setup_posted_irte( space before '{]' > + struct iremap_entry *new_ire, > + const struct pi_desc *pi_desc, > + const uint8_t gvec) Not sure why but your parameters are on their own line? Shouldnt at least one be with the function name - and then the rest on the same offset? > +{ > + new_ire->post.urg = 0; > + new_ire->post.vector = gvec; > + new_ire->post.pda_l = virt_to_maddr(pi_desc) >> (32 - PDA_LOW_BIT); > + new_ire->post.pda_h = virt_to_maddr(pi_desc) >> 32; > + > + new_ire->post.res_1 = 0; > + new_ire->post.res_2 = 0; > + new_ire->post.res_3 = 0; > + new_ire->post.res_4 = 0; > + new_ire->post.res_5 = 0; > + > + new_ire->post.im = 1; > +} > + > +/* > + * This function is used to update the IRTE for posted-interrupt > + * when guest changes MSI/MSI-X information. > + */ > +int pi_update_irte( > + const struct vcpu *v, > + const struct pirq *pirq, > + const uint8_t gvec) Ditto - perhaps move these to be right after the function name? > +{ > + struct irq_desc *desc; > + const struct msi_desc *msi_desc; > + int remap_index; > + int rc = 0; > + const struct pci_dev *pci_dev; > + const struct acpi_drhd_unit *drhd; > + struct iommu *iommu; > + struct ir_ctrl *ir_ctrl; > + struct iremap_entry *iremap_entries = NULL, *p = NULL; > + struct iremap_entry new_ire, old_ire; > + const struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc; > + __uint128_t ret; > + > + desc = pirq_spin_lock_irq_desc(pirq, NULL); > + if ( !desc ) > + return -EINVAL; > + > + msi_desc = desc->msi_desc; > + if ( !msi_desc ) > + { > + rc = -ENODEV; > + goto unlock_out; > + } > + > + pci_dev = msi_desc->dev; > + if ( !pci_dev ) > + { > + rc = -ENODEV; > + goto unlock_out; > + } > + > + remap_index = msi_desc->remap_index; > + > + spin_unlock_irq(&desc->lock); > + > + ASSERT(spin_is_locked(&pcidevs_lock)); > + > + /* > + * For performance concern, we will store the 'iommu' pointer in > + * 'struct msi_desc' in some other place, so we don't need to waste > + * time searching it here. I will fix this later. > + */ > + drhd = acpi_find_matched_drhd_unit(pci_dev); > + if ( !drhd ) > + { > + rc = -ENODEV; > + goto unlock_out; But you already unlocked desc->lock (so doing unlock_out would do a second spin unlock)? Should this be an return -ENODEV? > + } > + > + iommu = drhd->iommu; > + ir_ctrl = iommu_ir_ctrl(iommu); > + if ( !ir_ctrl ) > + { > + rc = -ENODEV; > + goto unlock_out; Ditto. > + } > + > + spin_lock_irq(&ir_ctrl->iremap_lock); > + > + GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, remap_index, iremap_entries, p); > + > + old_ire = new_ire = *p; > + > + /* Setup/Update interrupt remapping table entry. */ > + setup_posted_irte(&new_ire, pi_desc, gvec); > + ret = cmpxchg16b(p, &old_ire, &new_ire); > + > + ASSERT(ret == *(__uint128_t *)&old_ire); > + > + iommu_flush_cache_entry(p, sizeof(*p)); The other use sites of iommu_flush_cache_entry are sizeof(struct iremap_entry). I think if you are doing this modification - then you should also have an patch to modify the other code to be in sync. Or just use the sizeof(struct ...). > + iommu_flush_iec_index(iommu, 0, remap_index); > + > + unmap_vtd_domain_page(iremap_entries); > + > + spin_unlock_irq(&ir_ctrl->iremap_lock); > + > + return 0; > + > + unlock_out: > + spin_unlock_irq(&desc->lock); > + > + return rc; > +} > diff --git a/xen/drivers/passthrough/vtd/iommu.h > b/xen/drivers/passthrough/vtd/iommu.h > index 6fca430..ff4ceb6 100644 > --- a/xen/drivers/passthrough/vtd/iommu.h > +++ b/xen/drivers/passthrough/vtd/iommu.h > @@ -322,6 +322,8 @@ struct iremap_entry { > }; > }; > Perhaps a comment about it? > +#define PDA_LOW_BIT 26 > + > /* Max intr remapping table page order is 8, as max number of IRTEs is 64K */ > #define IREMAP_PAGE_ORDER 8 > > diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h > index 29203d7..92f0900 100644 > --- a/xen/include/asm-x86/iommu.h > +++ b/xen/include/asm-x86/iommu.h > @@ -31,6 +31,8 @@ int iommu_supports_eim(void); > int iommu_enable_x2apic_IR(void); > void iommu_disable_x2apic_IR(void); > > +int pi_update_irte(const struct vcpu *v, const struct pirq *pirq, const > uint8_t gvec); > + > #endif /* !__ARCH_X86_IOMMU_H__ */ > /* > * Local variables: > -- > 2.1.0 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |