public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: kan.liang@linux.intel.com, joro@8bytes.org, will@kernel.org,
	dwmw2@infradead.org, robin.murphy@arm.com,
	robert.moore@intel.com, rafael.j.wysocki@intel.com,
	lenb@kernel.org, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org
Cc: baolu.lu@linux.intel.com
Subject: Re: [PATCH 1/7] iommu/vt-d: Support size of the register set in DRHD
Date: Thu, 12 Jan 2023 20:42:53 +0800	[thread overview]
Message-ID: <367345ad-33cc-2268-63e1-979299d42c2e@linux.intel.com> (raw)
In-Reply-To: <20230111202504.378258-2-kan.liang@linux.intel.com>

On 2023/1/12 4:24, kan.liang@linux.intel.com wrote:
> From: Kan Liang <kan.liang@linux.intel.com>
> 
> A new field, which indicates the size of the remapping hardware register
> set for this remapping unit, is introduced in the DMA-remapping hardware
> unit definition (DRHD) structure with the VT-d Spec 4.0.
> With the information, SW doesn't need to 'guess' the size of the
> register set anymore.
> 
> Update the struct acpi_dmar_hardware_unit to reflect the field.
> 
> Store the size of the register set in struct dmar_drhd_unit for each
> dmar device.
> 
> The 'size' information is ResvZ for the old BIOS and platforms. Fall
> back to the old guessing method. There is nothing changed.
> 
> Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
> ---
>   drivers/iommu/intel/dmar.c | 25 ++++++++++++++++++-------
>   include/acpi/actbl1.h      |  2 +-
>   include/linux/dmar.h       |  1 +
>   3 files changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
> index b00a0ceb2d13..6a411d964474 100644
> --- a/drivers/iommu/intel/dmar.c
> +++ b/drivers/iommu/intel/dmar.c
> @@ -399,6 +399,13 @@ dmar_find_dmaru(struct acpi_dmar_hardware_unit *drhd)
>   	return NULL;
>   }
>   
> +/* The size of the register set is 2 ^ N 4 KB pages. */
> +static unsigned long
> +dmar_get_drhd_reg_size(u8 npages)

No need to divide it into two lines. Or put this line of code directly
where it is called?

> +{
> +	return 1UL << (npages + 12);
> +}
> +
>   /*
>    * dmar_parse_one_drhd - parses exactly one DMA remapping hardware definition
>    * structure which uniquely represent one DMA remapping hardware unit
> @@ -427,6 +434,7 @@ static int dmar_parse_one_drhd(struct acpi_dmar_header *header, void *arg)
>   	memcpy(dmaru->hdr, header, header->length);
>   	dmaru->reg_base_addr = drhd->address;
>   	dmaru->segment = drhd->segment;
> +	dmaru->reg_size = dmar_get_drhd_reg_size(drhd->size);
>   	dmaru->include_all = drhd->flags & 0x1; /* BIT0: INCLUDE_ALL */
>   	dmaru->devices = dmar_alloc_dev_scope((void *)(drhd + 1),
>   					      ((void *)drhd) + drhd->header.length,
> @@ -880,6 +888,7 @@ dmar_validate_one_drhd(struct acpi_dmar_header *entry, void *arg)
>   	struct acpi_dmar_hardware_unit *drhd;
>   	void __iomem *addr;
>   	u64 cap, ecap;
> +	unsigned long size;
>   
>   	drhd = (void *)entry;
>   	if (!drhd->address) {
> @@ -887,10 +896,11 @@ dmar_validate_one_drhd(struct acpi_dmar_header *entry, void *arg)
>   		return -EINVAL;
>   	}
>   
> +	size = dmar_get_drhd_reg_size(drhd->size);
>   	if (arg)
> -		addr = ioremap(drhd->address, VTD_PAGE_SIZE);
> +		addr = ioremap(drhd->address, size);
>   	else
> -		addr = early_ioremap(drhd->address, VTD_PAGE_SIZE);
> +		addr = early_ioremap(drhd->address, size);
>   	if (!addr) {
>   		pr_warn("Can't validate DRHD address: %llx\n", drhd->address);
>   		return -EINVAL;
> @@ -902,7 +912,7 @@ dmar_validate_one_drhd(struct acpi_dmar_header *entry, void *arg)
>   	if (arg)
>   		iounmap(addr);
>   	else
> -		early_iounmap(addr, VTD_PAGE_SIZE);
> +		early_iounmap(addr, size);
>   
>   	if (cap == (uint64_t)-1 && ecap == (uint64_t)-1) {
>   		warn_invalid_dmar(drhd->address, " returns all ones");

The cap and ecap registers are always in the first page. Just map one
4K page is enough. There is no need to change it?

> @@ -956,17 +966,18 @@ static void unmap_iommu(struct intel_iommu *iommu)
>   /**
>    * map_iommu: map the iommu's registers
>    * @iommu: the iommu to map
> - * @phys_addr: the physical address of the base resgister
> + * @drhd: DMA remapping hardware definition structure
>    *
>    * Memory map the iommu's registers.  Start w/ a single page, and
>    * possibly expand if that turns out to be insufficent.
>    */
> -static int map_iommu(struct intel_iommu *iommu, u64 phys_addr)
> +static int map_iommu(struct intel_iommu *iommu, struct dmar_drhd_unit *drhd)
>   {
> +	u64 phys_addr = drhd->reg_base_addr;
>   	int map_size, err=0;
>   
>   	iommu->reg_phys = phys_addr;
> -	iommu->reg_size = VTD_PAGE_SIZE;
> +	iommu->reg_size = drhd->reg_size;
>   
>   	if (!request_mem_region(iommu->reg_phys, iommu->reg_size, iommu->name)) {
>   		pr_err("Can't reserve memory\n");
> @@ -1050,7 +1061,7 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
>   	}
>   	sprintf(iommu->name, "dmar%d", iommu->seq_id);
>   
> -	err = map_iommu(iommu, drhd->reg_base_addr);
> +	err = map_iommu(iommu, drhd);
>   	if (err) {
>   		pr_err("Failed to map %s\n", iommu->name);
>   		goto error_free_seq_id;
> diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
> index 4175dce3967c..bdded0ac46eb 100644
> --- a/include/acpi/actbl1.h
> +++ b/include/acpi/actbl1.h
> @@ -802,7 +802,7 @@ struct acpi_dmar_pci_path {
>   struct acpi_dmar_hardware_unit {
>   	struct acpi_dmar_header header;
>   	u8 flags;
> -	u8 reserved;
> +	u8 size;		/* Size of the register set */
>   	u16 segment;
>   	u64 address;		/* Register Base Address */
>   };
> diff --git a/include/linux/dmar.h b/include/linux/dmar.h
> index d81a51978d01..51d498f0a02b 100644
> --- a/include/linux/dmar.h
> +++ b/include/linux/dmar.h
> @@ -46,6 +46,7 @@ struct dmar_drhd_unit {
>   	u8	include_all:1;
>   	u8	gfx_dedicated:1;	/* graphic dedicated	*/
>   	struct intel_iommu *iommu;
> +	unsigned long reg_size;		/* size of register set */

Move it up and pair it with reg_base_addr.

>   };
>   
>   struct dmar_pci_path {

--
Best regards,
baolu

  reply	other threads:[~2023-01-12 12:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-11 20:24 [PATCH 0/7] iommu/vt-d: Support performance monitoring for IOMMU kan.liang
2023-01-11 20:24 ` [PATCH 1/7] iommu/vt-d: Support size of the register set in DRHD kan.liang
2023-01-12 12:42   ` Baolu Lu [this message]
2023-01-12 16:42     ` Liang, Kan
2023-01-11 20:24 ` [PATCH 2/7] iommu/vt-d: Retrieve IOMMU perfmon capability information kan.liang
2023-01-13 12:58   ` Baolu Lu
2023-01-13 16:32     ` Liang, Kan
2023-01-11 20:25 ` [PATCH 3/7] iommu/vt-d: Support Enhanced Command Interface kan.liang
2023-01-13 13:55   ` Baolu Lu
2023-01-13 14:12     ` Baolu Lu
2023-01-13 19:02       ` Liang, Kan
2023-01-13 18:19     ` Liang, Kan
2023-01-11 20:25 ` [PATCH 4/7] iommu/vt-d: Add IOMMU perfmon support kan.liang
2023-01-14  9:00   ` Baolu Lu
2023-01-16 15:12     ` Liang, Kan
2023-01-17  8:12       ` Baolu Lu
2023-01-11 20:25 ` [PATCH 5/7] iommu/vt-d: Support cpumask for IOMMU perfmon kan.liang
2023-01-11 20:25 ` [PATCH 6/7] iommu/vt-d: Add IOMMU perfmon overflow handler support kan.liang
2023-01-14 11:05   ` Baolu Lu
2023-01-16 15:20     ` Liang, Kan
2023-01-17 16:52       ` Liang, Kan
2023-01-11 20:25 ` [PATCH 7/7] iommu/vt-d: Enable IOMMU perfmon support kan.liang

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=367345ad-33cc-2268-63e1-979299d42c2e@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kan.liang@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=robert.moore@intel.com \
    --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