Consult on ARM SMMU debugfs

[chenxiang (M)]

在 2021/1/12 4:01, Robin Murphy 写道:
> On 2021-01-07 02:45, chenxiang (M) wrote:
>> Hi Will,  Robin or other guys,
>>
>> When debugging SMMU/SVA issue on huawei ARM64 board, we find that it 
>> lacks of enough debugfs for ARM SMMU driver (such as
>>
>> the value of STE/CD which we need to check sometimes). Currently it 
>> creates top-level iommu directory in debugfs, but there is no debugfs
>>
>> for ARM SMMU driver specially. Do you know whether ARM have the plan 
>> to do that recently?
>
> FWIW I don't think I've ever felt the need to need to inspect the 
> Stream Table on a live system. So far the nature of the STE code has 
> been simple enough that it's very hard for any given STE to be *wrong* 
> - either it's set up as expected and thus works fine, or it's not 
> initialised at all and you get C_BAD_STE, where 99% of the time you 
> then just cross-reference the Stream ID against the firmware and find 
> that the DT/IORT is wrong.
>
> Similarly I don't think I've even even *seen* an issue that could be 
> attributed to a context descriptor, although I appreciate that as we 
> start landing more PASID and SVA support the scope for that starts to 
> widen considerably.

Thank you for your reply.  I aggree that it is very hard for the content 
of STE/CD to be wrong in current code, but  there are more upsteaming 
features(such as SVA/vSMMU) which are related to SMMU,
when debugging with those features, it is useful for us to locate issues 
if there are interfaces to dump those info. And also when debugging 
together with hardware guys, the content of dump is important for them too.

>
> Feel free to propose a patch if you believe it would be genuinely 
> useful and won't just bit-rot into a maintenance burden, but it's not 
> something that's on our roadmap here.

OK, we are considering about incorporating following requirements into 
the plan:
- Dump the value of STE/CD of devices
- Dump page table entries of devices
- Dump the entries info of CMDQ/EVENTQ

>
> Thanks,
> Robin.
>
> .
>