Re: [patch 33/37] iommu/arm-smmu-v3: Use msi_get_virq()

From: Robin Murphy
Date: Mon Nov 29 2021 - 09:56:31 EST


On 2021-11-29 14:42, Thomas Gleixner wrote:
On Mon, Nov 29 2021 at 13:13, Robin Murphy wrote:
On 2021-11-29 10:55, Will Deacon wrote:
- }
+ smmu->evtq.q.irq = msi_get_virq(dev, EVTQ_MSI_INDEX);
+ smmu->gerr_irq = msi_get_virq(dev, GERROR_MSI_INDEX);
+ smmu->priq.q.irq = msi_get_virq(dev, PRIQ_MSI_INDEX);

Prviously, if retrieval of the MSI failed then we'd fall back to wired
interrupts. Now, I think we'll clobber the interrupt with 0 instead. Can
we make the assignments to smmu->*irq here conditional on the MSI being
valid, please?

I was just looking at that too, but reached the conclusion that it's
probably OK, since consumption of this value later is gated on
ARM_SMMU_FEAT_PRI, so the fact that it changes from 0 to an error value
in the absence of PRI should make no practical difference.

It's actually 0 when the vector cannot be found.

Oh, -1 for my reading comprehension but +1 for my confidence in the patch then :)

I'll let Will have the final say over how cautious we really want to be here, but as far as I'm concerned it's a welcome cleanup as-is. Ditto for patch #32 based on the same reasoning, although I don't have a suitable test platform on-hand to sanity-check that one.

Cheers,
Robin.

If we don't have MSIs at all, we'd presumably still fail earlier
either at the dev->msi_domain check or upon trying to allocate the
vectors, so we'll still fall back to any previously-set wired values
before getting here. The only remaining case is if we've
*successfully* allocated the expected number of vectors yet are then
somehow unable to retrieve one or more of them - presumably the system
has to be massively borked for that to happen, at which point do we
really want to bother trying to reason about anything?

Probably not. At that point something is going to explode sooner than
later in colorful ways.

Thanks,

tglx