mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Jingqi Liu <Jingqi.liu@intel.com>,
	iommu@lists.linux.dev, Tian Kevin <kevin.tian@intel.com>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>
Cc: baolu.lu@linux.intel.com, linux-kernel@vger.kernel.org
Subject: Re: [PATH v5 3/3] iommu/vt-d: debugfs: Support dumping a specified page table
Date: Mon, 16 Oct 2023 11:04:25 +0800	[thread overview]
Message-ID: <fd56b69d-d9ea-411c-9eaa-454b3d64f51e@linux.intel.com> (raw)
In-Reply-To: <20231013135811.73953-4-Jingqi.liu@intel.com>

On 10/13/23 9:58 PM, Jingqi Liu wrote:
> The original debugfs only dumps all page tables without pasid. With
> pasid supported, the page table with pasid also needs to be dumped.
> 
> This patch supports dumping a specified page table in legacy mode or
> scalable mode with or without a specified pasid.
> 
> For legacy mode, according to bus number and DEVFN, traverse the root
> table and context table to get the pointer of page table in the
> context table entry, then dump the specified page table.
> 
> For scalable mode, according to bus number, DEVFN and pasid, traverse
> the root table, context table, pasid directory and pasid table to get
> the pointer of page table in the pasid table entry, then dump the
> specified page table..
> 
> Examples are as follows:
> 1) Dump the page table of device "0000:00:1f.0" that only supports
>     legacy mode.
>     $ sudo cat
>     /sys/kernel/debug/iommu/intel/0000:00:1f.0/domain_translation_struct
> 
> 2) Dump the page table of device "0000:00:0a.0" with PASID "1" that
>     supports scalable mode.
>     $ sudo cat
>     /sys/kernel/debug/iommu/intel/0000:00:0a.0/1/domain_translation_struct
> 
> Suggested-by: Kevin Tian <kevin.tian@intel.com>
> Signed-off-by: Jingqi Liu <Jingqi.liu@intel.com>
> ---
>   drivers/iommu/intel/debugfs.c | 154 ++++++++++++++++++++++++++--------
>   1 file changed, 120 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/iommu/intel/debugfs.c b/drivers/iommu/intel/debugfs.c
> index 8a18a7be5215..239136727ac4 100644
> --- a/drivers/iommu/intel/debugfs.c
> +++ b/drivers/iommu/intel/debugfs.c
> @@ -347,58 +347,141 @@ static void pgtable_walk_level(struct seq_file *m, struct dma_pte *pde,
>   	}
>   }
>   
> -static int __show_device_domain_translation(struct device *dev, void *data)
> +static int domain_translation_struct_show(struct seq_file *m,
> +					  struct device_domain_info *info,
> +					  ioasid_t pasid)
>   {
> -	struct dmar_domain *domain;
> -	struct seq_file *m = data;
> -	u64 path[6] = { 0 };
> -
> -	domain = to_dmar_domain(iommu_get_domain_for_dev(dev));
> -	if (!domain)
> -		return 0;
> +	bool scalable, found = false;
> +	struct dmar_drhd_unit *drhd;
> +	struct intel_iommu *iommu;
> +	u16 devfn, bus, seg;
>   
> -	seq_printf(m, "Device %s @0x%llx\n", dev_name(dev),
> -		   (u64)virt_to_phys(domain->pgd));
> -	seq_puts(m, "IOVA_PFN\t\tPML5E\t\t\tPML4E\t\t\tPDPE\t\t\tPDE\t\t\tPTE\n");
> +	bus = info->bus;
> +	devfn = info->devfn;
> +	seg = info->segment;
>   
> -	pgtable_walk_level(m, domain->pgd, domain->agaw + 2, 0, path);
> -	seq_putc(m, '\n');
> +	rcu_read_lock();
> +	for_each_active_iommu(iommu, drhd) {
> +		struct context_entry *context;
> +		u64 pgd, path[6] = { 0 };
> +		u32 sts, agaw;
>   
> -	/* Don't iterate */
> -	return 1;
> -}
> +		if (seg != iommu->segment)
> +			continue;
>   
> -static int show_device_domain_translation(struct device *dev, void *data)
> -{
> -	struct iommu_group *group;
> +		sts = dmar_readl(iommu->reg + DMAR_GSTS_REG);
> +		if (!(sts & DMA_GSTS_TES)) {
> +			seq_printf(m, "DMA Remapping is not enabled on %s\n",
> +				   iommu->name);
> +			continue;
> +		}
> +		if (dmar_readq(iommu->reg + DMAR_RTADDR_REG) & DMA_RTADDR_SMT)
> +			scalable = true;
> +		else
> +			scalable = false;
>   
> -	group = iommu_group_get(dev);
> -	if (group) {
>   		/*
> -		 * The group->mutex is held across the callback, which will
> -		 * block calls to iommu_attach/detach_group/device. Hence,
> +		 * The iommu->lock is held across the callback, which will
> +		 * block calls to domain_attach/domain_detach. Hence,
>   		 * the domain of the device will not change during traversal.
>   		 *
> -		 * All devices in an iommu group share a single domain, hence
> -		 * we only dump the domain of the first device. Even though,
> -		 * this code still possibly races with the iommu_unmap()
> +		 * Traversing page table possibly races with the iommu_unmap()
>   		 * interface. This could be solved by RCU-freeing the page
>   		 * table pages in the iommu_unmap() path.
>   		 */
> -		iommu_group_for_each_dev(group, data,
> -					 __show_device_domain_translation);
> -		iommu_group_put(group);
> +		spin_lock(&iommu->lock);
> +
> +		context = iommu_context_addr(iommu, bus, devfn, 0);
> +		if (!context || !context_present(context))
> +			goto iommu_unlock;
> +
> +		if (scalable) {	/* scalable mode */
> +			struct pasid_dir_entry *dir_tbl, *dir_entry;
> +			struct pasid_entry *pasid_tbl, *pasid_tbl_entry;
> +			u16 pasid_dir_size, dir_idx, tbl_idx, pgtt;
> +			u64 pasid_dir_ptr;

0day robot complained:

    drivers/iommu/intel/debugfs.c: In function 
'domain_translation_struct_show':
 >> drivers/iommu/intel/debugfs.c:401:29: warning: variable 
'pasid_dir_size' set but not used [-Wunused-but-set-variable]
      401 |                         u16 pasid_dir_size, dir_idx, 
tbl_idx, pgtt;
          |                             ^~~~~~~~~~~~~~

I have removed pasid_dir_size and queue the whole series for v6.7.

Thank you!

Best regards,
baolu

  reply	other threads:[~2023-10-16  3:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-13 13:58 [PATH v5 0/3] iommu/vt-d: debugfs: Enhancements to IOMMU debugfs Jingqi Liu
2023-10-13 13:58 ` [PATH v5 1/3] iommu/vt-d: debugfs: Dump entry pointing to huge page Jingqi Liu
2023-10-13 13:58 ` [PATH v5 2/3] iommu/vt-d: debugfs: Create/remove debugfs file per {device, pasid} Jingqi Liu
2024-11-12 21:22   ` Kees Bakker
2024-11-13  2:13     ` Baolu Lu
2024-11-13 20:35       ` Kees Bakker
2024-11-14  1:29         ` Baolu Lu
2023-10-13 13:58 ` [PATH v5 3/3] iommu/vt-d: debugfs: Support dumping a specified page table Jingqi Liu
2023-10-16  3:04   ` Baolu Lu [this message]
2023-10-17  3:02     ` Liu, Jingqi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fd56b69d-d9ea-411c-9eaa-454b3d64f51e@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=Jingqi.liu@intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome