Re: [PATCH v3 6/7] irqchip/gic-v3-mbi: Don't map the MSI page in mbi_compose_m{b, s}i_msg()

[Robin Murphy]

On 03/05/2019 15:27, Marc Zyngier wrote:
> On 01/05/2019 14:58, Julien Grall wrote:
> > The functions mbi_compose_m{b, s}i_msg may be called from non-preemptible
> > context. However, on RT, iommu_dma_map_msi_msg() requires to be called
> > from a preemptible context.
> >
> > A recent patch split iommu_dma_map_msi_msg in two new functions:
> > one that should be called in preemptible context, the other does
> > not have any requirement.
> >
> > The GICv3 MSI driver is reworked to avoid executing preemptible code in
> > non-preemptible context. This can be achieved by preparing the two MSI
> > mappings when allocating the MSI interrupt.
> >
> > Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
> >
> > ---
> >      Changes in v2:
> >          - Rework the commit message to use imperative mood
> > ---
> >   drivers/irqchip/irq-gic-v3-mbi.c | 15 +++++++++++++--
> >   1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-gic-v3-mbi.c b/drivers/irqchip/irq-gic-v3-mbi.c
> > index fbfa7ff6deb1..d50f6cdf043c 100644
> > --- a/drivers/irqchip/irq-gic-v3-mbi.c
> > +++ b/drivers/irqchip/irq-gic-v3-mbi.c
> > @@ -84,6 +84,7 @@ static void mbi_free_msi(struct mbi_range *mbi, unsigned int hwirq,
> >   static int mbi_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> >   				   unsigned int nr_irqs, void *args)
> >   {
> > +	msi_alloc_info_t *info = args;
> >   	struct mbi_range *mbi = NULL;
> >   	int hwirq, offset, i, err = 0;
> >   
> > @@ -104,6 +105,16 @@ static int mbi_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> >   
> >   	hwirq = mbi->spi_start + offset;
> >   
> > +	err = iommu_dma_prepare_msi(info->desc,
> > +				    mbi_phys_base + GICD_CLRSPI_NSR);
> > +	if (err)
> > +		return err;
> > +
> > +	err = iommu_dma_prepare_msi(info->desc,
> > +				    mbi_phys_base + GICD_SETSPI_NSR);
> > +	if (err)
> > +		return err;
>
> Nit here: The two registers are guaranteed to be in the same 4k page
> (respectively offsets 0x48 and 0x40), so the second call is at best
> useless. I'll fix it when applying it, no need to resend.

Ack; the second call will simply find the existing page and overwrite 
desc->iommu_cookie with the same value. And if the two calls *did* ever 
come back with different pages, that logic would be quietly broken anyway.

Robin.