[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Patch RFC 02/13] vt-d: Register MSI for async invalidation completion interrupt.
>>> On 16.09.15 at 15:23, <quan.xu@xxxxxxxxx> wrote: > +/* IOMMU Queued Invalidation(QI). */ > +static void _qi_msi_unmask(struct iommu *iommu) > +{ > + u32 sts; > + unsigned long flags; > + > + /* Clear IM bit of DMAR_IECTL_REG. */ > + spin_lock_irqsave(&iommu->register_lock, flags); > + sts = dmar_readl(iommu->reg, DMAR_IECTL_REG); > + sts &= ~DMA_IECTL_IM; > + dmar_writel(iommu->reg, DMAR_IECTL_REG, sts); > + spin_unlock_irqrestore(&iommu->register_lock, flags); > +} I think rather than duplicating all this code from the fault interrupt you should instead re-factor to make the original usable for both purposes. Afaics the differences really are just the register and bit locations. > +static void _do_iommu_qi(struct iommu *iommu) > +{ > +} ??? > +static void qi_msi_unmask(struct irq_desc *desc) > +{ > + _qi_msi_unmask(desc->action->dev_id); > +} > + > +static void qi_msi_mask(struct irq_desc *desc) > +{ > + _qi_msi_mask(desc->action->dev_id); > +} These wrappers look pretty pointless. > +static void qi_msi_end(struct irq_desc *desc, u8 vector) > +{ > + ack_APIC_irq(); > +} Why is there, other than for its fault counterpart, no unmask operation here? > @@ -1123,6 +1243,7 @@ int __init iommu_alloc(struct acpi_drhd_unit *drhd) > return -ENOMEM; > > iommu->msi.irq = -1; /* No irq assigned yet. */ > + iommu->qi_msi.irq = -1; /* No irq assigned yet. */ Which suggests that (perhaps in patch 1) the existing field should be renamed to e.g. fe_msi. > @@ -1985,6 +2109,9 @@ static void adjust_irq_affinity(struct acpi_drhd_unit > *drhd) > cpumask_intersects(&node_to_cpumask(node), cpumask) ) > cpumask = &node_to_cpumask(node); > dma_msi_set_affinity(irq_to_desc(drhd->iommu->msi.irq), cpumask); > + > + if ( ats_enabled ) > + qi_msi_set_affinity(irq_to_desc(drhd->iommu->qi_msi.irq), cpumask); > } > > int adjust_vtd_irq_affinities(void) > @@ -2183,6 +2310,11 @@ int __init intel_vtd_setup(void) > > ret = iommu_set_interrupt(drhd, &dma_msi_type, "dmar", > &drhd->iommu->msi, > iommu_page_fault); > + if ( ats_enabled ) > + ret = iommu_set_interrupt(drhd, &qi_msi_type, "qi", > + &drhd->iommu->qi_msi, > + iommu_qi_completion); > + Would there be any harm from leaving out most/all of these ats_enabled conditionals, despite right now that code only intended to be used for ATS invalidations? I.e. wouldn't it just be that the interrupt never triggers? > --- a/xen/drivers/passthrough/vtd/iommu.h > +++ b/xen/drivers/passthrough/vtd/iommu.h > @@ -47,6 +47,11 @@ > #define DMAR_IQH_REG 0x80 /* invalidation queue head */ > #define DMAR_IQT_REG 0x88 /* invalidation queue tail */ > #define DMAR_IQA_REG 0x90 /* invalidation queue addr */ > +#define DMAR_IECTL_REG 0xA0 /* invalidation event contrl register */ > +#define DMAR_IEDATA_REG 0xA4 /* invalidation event data register */ > +#define DMAR_IEADDR_REG 0xA8 /* invalidation event address register */ > +#define DMAR_IEUADDR_REG 0xAC /* invalidation event upper address > register */ > +#define DMAR_ICS_REG 0x9C /* invalidation completion status > register */ Numerically ordered please. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |