Re: [PATCH] iommu/vt-d: Fix IQE handling to cover all descriptors in submission range

[Baolu Lu <baolu.lu@linux.intel.com>]

On 8/21/2026 10:56 AM, Baolu Lu wrote:
> On 8/20/26 22:47, Guanghui Feng wrote:
>> Currently, qi_check_fault() only handles IQE (Invalidation Queue Error)
>> when the faulting descriptor index exactly matches the first descriptor
>> of the current submission (head == index). This is too restrictive in
>> multi-descriptor submissions where the error could occur at any
>> descriptor within the batch.
>>
>> If the IQE is triggered by a descriptor that belongs to the current
>> submission but is not at the starting index, the function returns 0
>> without clearing the IQE fault status. Since hardware stops fetching
>> new descriptors until IQE is cleared, this leads to an indefinite wait
>> on the wait descriptor completion - effectively a deadlock.
>>
>> Fix this by expanding the IQE handling condition to cover all descriptors
>> within the circular range [index, wait_index]. Use explicit bounds
>> checking that properly handles the wrap-around case of the circular
>> queue.
>>
>> Signed-off-by: Guanghui Feng <guanghuifeng@linux.alibaba.com>
>> Signed-off-by: bikuan.zbk <bikuan.zbk@alibaba-inc.com>
>> ---
>>   drivers/iommu/intel/dmar.c | 15 ++++++++++++++-
>>   1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
>> index ba675b08cd20..ecc95af06f61 100644
>> --- a/drivers/iommu/intel/dmar.c
>> +++ b/drivers/iommu/intel/dmar.c
>> @@ -1366,8 +1366,21 @@ static int qi_check_fault(struct intel_iommu 
>> *iommu, int index, int wait_index)
>>        * is cleared.
>>        */
>>       if (fault & DMA_FSTS_IQE) {
>> +        int head_idx;
>> +
>>           head = readl(iommu->reg + DMAR_IQH_REG);
>> -        if ((head >> shift) == index) {
>> +        head_idx = head >> shift;
>> +
>> +        /*
>> +         * The faulting descriptor can be anywhere within the current
>> +         * submission's range [index, wait_index]. Since the queue is
>> +         * circular, this submission may wrap around QI_LENGTH
>> +         * (index > wait_index in that case), so check both the
>> +         * non-wrapped and wrapped cases of the range.
>> +         */
>> +        if (index <= wait_index ?
>> +            (head_idx >= index && head_idx <= wait_index) :
>> +            (head_idx >= index || head_idx <= wait_index)) {
>>               struct qi_desc *desc = qi->desc + head;
>>               /*
> 
> Could you also please take a look at the comments from Sashiko?
> 
> https://sashiko.dev/#/patchset/20260805042012.2363698-1- 
> guanghuifeng%40linux.alibaba.com
> 
> https://sashiko.dev/#/patchset/20260820144741.920858-1- 
> guanghuifeng%40linux.alibaba.com

I think some points from the Sashiko review are valid, and we should
address them.

For example,

"
When an IQE is cleared and -EINVAL is returned, hardware is unhalted and
continues processing the rest of the abandoned batch. If another
descriptor in that batch faults, hardware halts again. Since the
original thread already returned -EINVAL and left its wait loop, a new
thread checking faults may compare that new IQE against its own
unrelated [new_index, new_wait_index] range, miss the fault, and leave
hardware permanently deadlocked.
"
and

"
When the wait loop aborts, qi_submit_sync() immediately marks the batch
slots as QI_FREE and reclaims them. But hardware may still be processing
descriptors from that batch asynchronously. Reusing those slots too
early allows concurrent overwrite, and hardware can then fetch corrupted
descriptors.
"

So it seems safer to overwrite all remaining slots in the failed batch
(starting from the faulting slot) with a wait descriptor (effectively a
no-op), then wait until hardware consumes them, and only then return
-EINVAL and let the caller abandon the batch.

As for the question, “...what if the hardware returns a large or
negative value?”, the IQ head register is in the root complex and is
expected to remain accessible as long as the platform is operational.

Thanks,
baolu