[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f6ee653e-01d8-5728-207b-f423f979b624@linux.intel.com>
Date: Fri, 8 May 2020 09:37:01 +0800
From: Lu Baolu <baolu.lu@...ux.intel.com>
To: Jacob Pan <jacob.jun.pan@...ux.intel.com>
Cc: baolu.lu@...ux.intel.com, Joerg Roedel <joro@...tes.org>,
ashok.raj@...el.com, Liu Yi L <yi.l.liu@...el.com>,
kevin.tian@...el.com, iommu@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/5] iommu/vt-d: debugfs: Add support to show inv queue
internals
Hi Jacob,
On 5/8/20 12:47 AM, Jacob Pan wrote:
> Hi Baolu,
>
> Very helpful feature, thanks for doing this. Just a small suggestion.
Thanks a lot for reviewing my patch.
>
> On Thu, 7 May 2020 08:55:31 +0800
> Lu Baolu<baolu.lu@...ux.intel.com> wrote:
>
>> Export invalidation queue internals of each iommu device through the
>> debugfs.
>>
>> Example of such dump on a Skylake machine:
>>
>> $ sudo cat /sys/kernel/debug/iommu/intel/invalidation_queue
>> Invalidation queue on IOMMU: dmar1
>> Base: 0x1672c9000 Head: 80 Tail: 80
>> Index qw0 qw1 status
>> 0 0000000000000004 0000000000000000
>> 0000000000000000 1 0000000200000025 00000001672be804
>> 0000000000000000 2 0000000000000011 0000000000000000
>> 0000000000000000 3 0000000200000025 00000001672be80c
>> 0000000000000000 4 00000000000000d2 0000000000000000
>> 0000000000000000 5 0000000200000025 00000001672be814
>> 0000000000000000 6 0000000000000014 0000000000000000
>> 0000000000000000 7 0000000200000025 00000001672be81c
>> 0000000000000000 8 0000000000000014 0000000000000000
>> 0000000000000000 9 0000000200000025 00000001672be824
>> 0000000000000000
>>
> Head and Tail shows the offset, and queue is dump with index. Would it
> be nice to mark where the Head and Tail is in the list?
The Head and Tail actually show the index. I will mark it clearly in the
dump to avoid any confusion. Thanks for the reminding.
> In your example, the queue is empty (H=T), would be nice to see where
> the previous entry is if there were any faults.
>
The qi_check_fault() has already cleared the faults and moved ahead the
HEAD register. So probably the developers have to check the kernel log
and locate the fault descriptor by themselves.
Best regards,
baolu
Powered by blists - more mailing lists