Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Robin Murphy <robin.murphy@arm.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"devel@acpica.org" <devel@acpica.org>
Cc: Linuxarm <linuxarm@huawei.com>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	wanghuiqiang <wanghuiqiang@huawei.com>,
	"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>,
	Jonathan Cameron <jonathan.cameron@huawei.com>
Subject: RE: [RFC PATCH 3/4] ACPI/IORT: Add RMR memory regions reservation helper
Date: Fri, 6 Nov 2020 16:00:23 +0000
Message-ID: <4e1e1d3d873049cfaedda14a1187e1cd@huawei.com> (raw)
In-Reply-To: <b0123797-4b49-8256-1080-36b9a6f7eee6@arm.com>



> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: 06 November 2020 13:06
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
> iommu@lists.linux-foundation.org; devel@acpica.org
> Cc: Linuxarm <linuxarm@huawei.com>; lorenzo.pieralisi@arm.com;
> joro@8bytes.org; wanghuiqiang <wanghuiqiang@huawei.com>; Guohanjun
> (Hanjun Guo) <guohanjun@huawei.com>; Jonathan Cameron
> <jonathan.cameron@huawei.com>
> Subject: Re: [RFC PATCH 3/4] ACPI/IORT: Add RMR memory regions reservation
> helper
> 
> On 2020-11-06 08:30, Shameerali Kolothum Thodi wrote:
> >
> >
> >> -----Original Message-----
> >> From: Robin Murphy [mailto:robin.murphy@arm.com]
> >> Sent: 05 November 2020 18:04
> >> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> >> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
> >> iommu@lists.linux-foundation.org; devel@acpica.org
> >> Cc: Linuxarm <linuxarm@huawei.com>; lorenzo.pieralisi@arm.com;
> >> joro@8bytes.org; wanghuiqiang <wanghuiqiang@huawei.com>; Guohanjun
> >> (Hanjun Guo) <guohanjun@huawei.com>; Jonathan Cameron
> >> <jonathan.cameron@huawei.com>
> >> Subject: Re: [RFC PATCH 3/4] ACPI/IORT: Add RMR memory regions
> reservation
> >> helper
> >>
> >> On 2020-10-27 11:26, Shameer Kolothum wrote:
> >>> Add a helper function that retrieves RMR memory descriptors
> >>> associated with a given endpoint dev. These memory regions
> >>> should have a unity mapping in the SMMU. So reserve them as
> >>> IOMMU_RESV_DIRECT.
> >>
> >> As a general observation, we also need a way into this that isn't from
> >> the perspective of endpoint devices. With SMMUv3 we need to know all the
> >> active stream IDs relevant to a given SMMU instance at probe time, so
> >> that we can set up some kind of valid stream table entries *before*
> >> enabling the SMMU in the reset routine.
> >
> > So I guess, the idea is to provide an interface here to retrieve those active
> > stream Ids? The problem is, at present(AFAICS), RMR doesn’t have any
> > means to specify such devices.
> 
> I'm thinking we need to check if any RMRs exist in the IORT, if so find
> the devices that map to them, then resolve those devices' ID mappings.
> In terms of the interface, maybe the better option is to do something
> closer to what intel-iommu does and handle *all* the processing up-front
> - let the IOMMU driver just call into the firmware code once to retrieve
> a complete list of all the relevant abstracted RMR (or DT equivalent)
> information, so it can then resolve both its own early initialisation
> and the later per-device setup without calling back into firmware code
> again.

Ok. I will try to change the interface then.

> >   Otherwise we're just going to
> >> kill ongoing traffic (e.g. EFI GOP) with C_BAD_STE long before we ever
> >> start adding devices and worrying about reserved regions for them.
> >> Similarly for the initial SMR/S2CR state on SMMUv2 with disable_bypass.
> >
> > Ok. I see the discussion here,
> >
> https://lore.kernel.org/linux-iommu/484b9e90-7395-6161-577c-4d3f3716997e
> @arm.com/
> >
> >  From what I gather, the plan is to setup a default IDENTITY_DOMAIN for
> > devices that have live stream going on during boot/SMMU probe time.
> 
> Well, whether we use bypass or a temporary translation context for the
> period before we even get to default domains... that's a discussion that
> can wait until we have the ability to set up the STEs at all ;)

Sure.

Thanks,
Shameer
 
> Robin.
> 
> >>> Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi@huawei.com>
> >>> ---
> >>>    drivers/acpi/arm64/iort.c | 56
> >> +++++++++++++++++++++++++++++++++++++++
> >>>    include/linux/acpi_iort.h |  4 +++
> >>>    2 files changed, 60 insertions(+)
> >>>
> >>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> >>> index b32cd53cca08..c0700149e60b 100644
> >>> --- a/drivers/acpi/arm64/iort.c
> >>> +++ b/drivers/acpi/arm64/iort.c
> >>> @@ -842,6 +842,60 @@ static inline int iort_add_device_replay(struct
> >> device *dev)
> >>>    	return err;
> >>>    }
> >>>
> >>> +static bool iort_dev_has_rmr(struct device *dev, struct iort_rmr_entry
> *e)
> >>> +{
> >>> +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> >>> +	struct acpi_iort_node *iommu;
> >>> +	struct iort_rmr_id *rmr_ids = e->rmr_ids;
> >>> +	int i, j;
> >>> +
> >>> +	iommu = iort_get_iort_node(fwspec->iommu_fwnode);
> >>> +
> >>> +	for (i = 0; i < e->rmr_ids_num; i++, rmr_ids++) {
> >>> +		for (j = 0; j < fwspec->num_ids; j++) {
> >>> +			if (rmr_ids->sid == fwspec->ids[j] &&
> >>> +			    rmr_ids->smmu == iommu)
> >>> +				return true;
> >>> +		}
> >>> +	}
> >>> +
> >>> +	return false;
> >>> +}
> >>> +
> >>> +/**
> >>> + * iort_dev_rmr_get_resv_regions - RMR Reserved region driver helper
> >>> + * @dev: Device from iommu_get_resv_regions()
> >>> + * @head: Reserved region list from iommu_get_resv_regions()
> >>> + *
> >>> + * Returns: 0 on success, <0 failure
> >>> + */
> >>> +int iort_dev_rmr_get_resv_regions(struct device *dev, struct list_head
> >> *head)
> >>> +{
> >>> +	struct iort_rmr_entry *e;
> >>> +
> >>> +	list_for_each_entry(e, &iort_rmr_list, list) {
> >>> +		struct iommu_resv_region *region;
> >>> +		struct acpi_iort_rmr_desc *rmr;
> >>> +		int prot = IOMMU_READ | IOMMU_WRITE |
> >>> +			   IOMMU_NOEXEC | IOMMU_MMIO;
> >>> +
> >>> +		if (!iort_dev_has_rmr(dev, e))
> >>> +			continue;
> >>> +
> >>> +		rmr = e->rmr_desc;
> >>> +		region = iommu_alloc_resv_region(rmr->base_address,
> >>> +						 rmr->length, prot,
> >>> +						 IOMMU_RESV_DIRECT);
> >>> +		if (!region) {
> >>> +			dev_err(dev, "Out of memory allocating RMR regions\n");
> >>> +			return -ENOMEM;
> >>> +		}
> >>> +		list_add_tail(&region->list, head);
> >>> +	}
> >>> +
> >>> +	return 0;
> >>> +}
> >>> +
> >>>    /**
> >>>     * iort_iommu_msi_get_resv_regions - Reserved region driver helper
> >>>     * @dev: Device from iommu_get_resv_regions()
> >>> @@ -1112,6 +1166,8 @@ int iort_iommu_msi_get_resv_regions(struct
> >> device *dev, struct list_head *head)
> >>>    const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
> >>>    						const u32 *input_id)
> >>>    { return NULL; }
> >>> +int iort_dev_rmr_get_resv_regions(struct device *dev, struct list_head
> >> *head)
> >>> +{ return 0; }
> >>>    #endif
> >>>
> >>>    static int nc_dma_get_range(struct device *dev, u64 *size)
> >>> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> >>> index 20a32120bb88..6dd89faf340c 100644
> >>> --- a/include/linux/acpi_iort.h
> >>> +++ b/include/linux/acpi_iort.h
> >>> @@ -38,6 +38,7 @@ void iort_dma_setup(struct device *dev, u64
> >> *dma_addr, u64 *size);
> >>>    const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
> >>>    						const u32 *id_in);
> >>>    int iort_iommu_msi_get_resv_regions(struct device *dev, struct
> list_head
> >> *head);
> >>> +int iort_dev_rmr_get_resv_regions(struct device *dev, struct list_head
> >> *head);
> >>>    #else
> >>>    static inline void acpi_iort_init(void) { }
> >>>    static inline u32 iort_msi_map_id(struct device *dev, u32 id)
> >>> @@ -55,6 +56,9 @@ static inline const struct iommu_ops
> >> *iort_iommu_configure_id(
> >>>    static inline
> >>>    int iort_iommu_msi_get_resv_regions(struct device *dev, struct
> list_head
> >> *head)
> >>>    { return 0; }
> >>> +static inline
> >>> +int iort_dev_rmr_get_resv_regions(struct device *dev, struct list_head
> >> *head)
> >>> +{ return 0; }
> >>>    #endif
> >>>
> >>>    #endif /* __ACPI_IORT_H__ */
> >>>

  reply index

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-27 11:26 [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node Shameer Kolothum
2020-10-27 11:26 ` [RFC PATCH 1/4] ACPICA: IORT: Update for revision E Shameer Kolothum
     [not found]   ` <BYAPR11MB3256AFF743B4FCC400F4181C87160@BYAPR11MB3256.namprd11.prod.outlook.com>
     [not found]     ` <610c14ef56d64fe087ca52aede07d811@huawei.com>
     [not found]       ` <MWHPR11MB1599988D7C857E3AFFA4A48AF0170@MWHPR11MB1599.namprd11.prod.outlook.com>
2020-10-28 18:40         ` [Devel] " Shameerali Kolothum Thodi
2020-10-27 11:26 ` [RFC PATCH 2/4] ACPI/IORT: Add support for RMR node parsing Shameer Kolothum
2020-10-28 18:43   ` [Devel] " David E. Box
2020-11-09 12:29     ` [Devel] " Sami Mujawar
2020-11-19 12:07       ` Shameerali Kolothum Thodi
2020-10-27 11:26 ` [RFC PATCH 3/4] ACPI/IORT: Add RMR memory regions reservation helper Shameer Kolothum
2020-11-05 18:03   ` Robin Murphy
2020-11-06  8:30     ` Shameerali Kolothum Thodi
2020-11-06 13:06       ` Robin Murphy
2020-11-06 16:00         ` Shameerali Kolothum Thodi [this message]
2020-10-27 11:26 ` [RFC PATCH 4/4] iommu/dma: Reserve any RMR regions associated with a dev Shameer Kolothum
2020-10-28 16:43 ` [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node Steven Price
2020-10-28 18:24   ` Shameerali Kolothum Thodi
2020-11-06 15:22     ` Steven Price
2020-11-06 16:17       ` Shameerali Kolothum Thodi
2020-11-06 16:26         ` Steven Price
2020-11-06 17:09           ` Robin Murphy

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=4e1e1d3d873049cfaedda14a1187e1cd@huawei.com \
    --to=shameerali.kolothum.thodi@huawei.com \
    --cc=devel@acpica.org \
    --cc=guohanjun@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jonathan.cameron@huawei.com \
    --cc=joro@8bytes.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linuxarm@huawei.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=wanghuiqiang@huawei.com \
    /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

Linux-ACPI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-acpi/0 linux-acpi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-acpi linux-acpi/ https://lore.kernel.org/linux-acpi \
		linux-acpi@vger.kernel.org
	public-inbox-index linux-acpi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-acpi


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git