[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 1/3] x86/physdev: factor out the code to allocate and map a pirq
On Fri, May 12, 2017 at 06:56:01AM -0600, Jan Beulich wrote: > >>> On 19.04.17 at 17:11, <roger.pau@xxxxxxxxxx> wrote: > > +int allocate_and_map_gsi_pirq(struct domain *d, int *index, int *pirq_p) > > +{ > > + int irq, pirq, ret; > > + > > + if ( *index < 0 || *index >= nr_irqs_gsi ) > > + { > > + dprintk(XENLOG_G_ERR, "dom%d: map invalid irq %d\n", d->domain_id, > > + *index); > > + return -EINVAL; > > + } > > + > > + irq = domain_pirq_to_irq(current->domain, *index); > > + if ( irq <= 0 ) > > + { > > + if ( is_hardware_domain(current->domain) ) > > + irq = *index; > > + else { > > Please adjust coding style issues like the brace placement here. Done. > > + pcidevs_lock(); > > + /* Verify or get pirq. */ > > + spin_lock(&d->event_lock); > > + pirq = domain_irq_to_pirq(d, irq); > > + > > + if ( *pirq_p < 0 ) > > + { > > + if ( pirq ) > > + { > > + dprintk(XENLOG_G_ERR, "dom%d: %d:%d already mapped to %d\n", > > + d->domain_id, *index, *pirq_p, pirq); > > + if ( pirq < 0 ) > > + { > > + ret = -EBUSY; > > + goto done; > > + } > > + } > > + else > > + { > > + pirq = get_free_pirq(d, MAP_PIRQ_TYPE_GSI); > > + if ( pirq < 0 ) > > + { > > + dprintk(XENLOG_G_ERR, "dom%d: no free pirq\n", > > d->domain_id); > > + ret = pirq; > > + goto done; > > + } > > + } > > + } > > + else > > + { > > + if ( pirq && pirq != *pirq_p ) > > + { > > + dprintk(XENLOG_G_ERR, "dom%d: pirq %d conflicts with irq %d\n", > > + d->domain_id, *index, *pirq_p); > > + ret = -EEXIST; > > + goto done; > > + } > > + else > > + pirq = *pirq_p; > > + } > > + > > + ret = map_domain_pirq(d, pirq, irq, MAP_PIRQ_TYPE_GSI, NULL); > > + if ( ret == 0 ) > > + *pirq_p = pirq; > > + > > + done: > > + spin_unlock(&d->event_lock); > > + pcidevs_unlock(); > > All of the code above is being repeated in allocate_and_map_msi_pirq(), > merely with the multi-MSI addition. This is too much code duplication for > my taste. I can try to factor this out into a separate helper that's used by both. > Additionally, with it being split like this it is then questionable > what acquiring the PCI devices lock is good for here (I would think it is > needed at most in the MSI case). Right, also I'm not sure why the PCI devices lock is acquired before calling into domain_irq_to_pirq, is that because of lock ordering rules with the domain event lock? > > +int allocate_and_map_msi_pirq(struct domain *d, int *index, int *pirq_p, > > + struct msi_info *msi) > > +{ > > + int irq, pirq, ret, type; > > + > > + irq = *index; > > + if ( irq == -1 || msi->entry_nr > 1 ) > > + irq = create_irq(NUMA_NO_NODE); > > This doesn't look to be an exact equivalent of the original code: Even > with MAP_PIRQ_TYPE_MULTI_MSI entry_nr may be 1, and the original > code calls create_irq() also in that case. If this is an intended change, > the rationale should be provided in the commit message. But as you > don't alter map_domain_pirq(), I doubt this is correct. My bad then, it's quite hard for me to figure out exactly what's the meaning/usage of those types, since they are not documented anywhere that I can find. physdev.h contains 3 different MSI related types: * MAP_PIRQ_TYPE_MSI_SEG maps into MAP_PIRQ_TYPE_MSI. * MAP_PIRQ_TYPE_MULTI_MSI is only available to map MSI interrupts (no MSI-X). * MAP_PIRQ_TYPE_MSI can map both MSI/MSI-X: - If table_base != 0 it's a MSI-X interrupt. - If table_base == 0 it's a single MSI interrupt AND entry_nr must be 1. Let me know if this is accurate. > > + if ( irq < nr_irqs_gsi || irq >= nr_irqs ) > > + { > > + dprintk(XENLOG_G_ERR, "dom%d: can't create irq for msi!\n", > > + d->domain_id); > > + ret = -EINVAL; > > + goto free_irq; > > + } > > + > > + msi->irq = irq; > > + type = (msi->entry_nr > 1 && !msi->table_base) ? > > MAP_PIRQ_TYPE_MULTI_MSI > > + : MAP_PIRQ_TYPE_MSI; > > Same here - you're not necessarily reconstructing the type passed > into the hypercall. Right, see my comment above. Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |