All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Yicong Yang <yangyicong@hisilicon.com>,
	gregkh@linuxfoundation.org, helgaas@kernel.org,
	alexander.shishkin@linux.intel.com, lorenzo.pieralisi@arm.com,
	will@kernel.org, mark.rutland@arm.com,
	mathieu.poirier@linaro.org, suzuki.poulose@arm.com,
	mike.leach@linaro.org, leo.yan@linaro.org,
	jonathan.cameron@huawei.com, daniel.thompson@linaro.org,
	joro@8bytes.org, john.garry@huawei.com,
	shameerali.kolothum.thodi@huawei.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org,
	linux-pci@vger.kernel.org, linux-perf-users@vger.kernel.org,
	iommu@lists.linux-foundation.org
Cc: prime.zeng@huawei.com, linuxarm@huawei.com,
	zhangshaokun@hisilicon.com, liuqi115@huawei.com
Subject: Re: [PATCH v2 2/6] hwtracing: Add trace function support for HiSilicon PCIe Tune and Trace device
Date: Tue, 16 Nov 2021 10:56:39 +0000	[thread overview]
Message-ID: <0b67745c-13dd-1fea-1b8b-d55212bad232@arm.com> (raw)
In-Reply-To: <20211116090625.53702-3-yangyicong@hisilicon.com>

On 2021-11-16 09:06, Yicong Yang via iommu wrote:
[...]
> +/*
> + * Get RMR address if provided by the firmware.
> + * Return 0 if the IOMMU doesn't present or the policy of the
> + * IOMMU domain is passthrough or we get a usable RMR region.
> + * Otherwise a negative value is returned.
> + */
> +static int hisi_ptt_get_rmr(struct hisi_ptt *hisi_ptt)
> +{
> +	struct pci_dev *pdev = hisi_ptt->pdev;
> +	struct iommu_domain *iommu_domain;
> +	struct iommu_resv_region *region;
> +	LIST_HEAD(list);
> +
> +	/*
> +	 * Use direct DMA if IOMMU does not present or the policy of the
> +	 * IOMMU domain is passthrough.
> +	 */
> +	iommu_domain = iommu_get_domain_for_dev(&pdev->dev);
> +	if (!iommu_domain || iommu_domain->type == IOMMU_DOMAIN_IDENTITY)
> +		return 0;
> +
> +	iommu_get_resv_regions(&pdev->dev, &list);
> +	list_for_each_entry(region, &list, list)
> +		if (region->type == IOMMU_RESV_DIRECT &&
> +		    region->length >= HISI_PTT_TRACE_BUFFER_SIZE) {
> +			hisi_ptt->trace_ctrl.has_rmr = true;
> +			hisi_ptt->trace_ctrl.rmr_addr = region->start;
> +			hisi_ptt->trace_ctrl.rmr_length = region->length;
> +			break;
> +		}
> +
> +	iommu_put_resv_regions(&pdev->dev, &list);
> +	return hisi_ptt->trace_ctrl.has_rmr ? 0 : -ENOMEM;
> +}

No.

The whole point of RMRs is for devices that are already configured to 
access the given address range in a manner beyond the kernel's control. 
If you can do this, it proves that you should not have an RMR in the 
first place.

The notion of a kernel driver explicitly configuring its device to DMA 
into any random RMR that looks big enough is so egregiously wrong that 
I'm almost lost for words...

Robin.

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Yicong Yang <yangyicong@hisilicon.com>,
	gregkh@linuxfoundation.org, helgaas@kernel.org,
	alexander.shishkin@linux.intel.com, lorenzo.pieralisi@arm.com,
	will@kernel.org, mark.rutland@arm.com,
	mathieu.poirier@linaro.org, suzuki.poulose@arm.com,
	mike.leach@linaro.org, leo.yan@linaro.org,
	jonathan.cameron@huawei.com, daniel.thompson@linaro.org,
	joro@8bytes.org, john.garry@huawei.com,
	shameerali.kolothum.thodi@huawei.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org,
	linux-pci@vger.kernel.org, linux-perf-users@vger.kernel.org,
	iommu@lists.linux-foundation.org
Cc: zhangshaokun@hisilicon.com, liuqi115@huawei.com,
	linuxarm@huawei.com, prime.zeng@huawei.com
Subject: Re: [PATCH v2 2/6] hwtracing: Add trace function support for HiSilicon PCIe Tune and Trace device
Date: Tue, 16 Nov 2021 10:56:39 +0000	[thread overview]
Message-ID: <0b67745c-13dd-1fea-1b8b-d55212bad232@arm.com> (raw)
In-Reply-To: <20211116090625.53702-3-yangyicong@hisilicon.com>

On 2021-11-16 09:06, Yicong Yang via iommu wrote:
[...]
> +/*
> + * Get RMR address if provided by the firmware.
> + * Return 0 if the IOMMU doesn't present or the policy of the
> + * IOMMU domain is passthrough or we get a usable RMR region.
> + * Otherwise a negative value is returned.
> + */
> +static int hisi_ptt_get_rmr(struct hisi_ptt *hisi_ptt)
> +{
> +	struct pci_dev *pdev = hisi_ptt->pdev;
> +	struct iommu_domain *iommu_domain;
> +	struct iommu_resv_region *region;
> +	LIST_HEAD(list);
> +
> +	/*
> +	 * Use direct DMA if IOMMU does not present or the policy of the
> +	 * IOMMU domain is passthrough.
> +	 */
> +	iommu_domain = iommu_get_domain_for_dev(&pdev->dev);
> +	if (!iommu_domain || iommu_domain->type == IOMMU_DOMAIN_IDENTITY)
> +		return 0;
> +
> +	iommu_get_resv_regions(&pdev->dev, &list);
> +	list_for_each_entry(region, &list, list)
> +		if (region->type == IOMMU_RESV_DIRECT &&
> +		    region->length >= HISI_PTT_TRACE_BUFFER_SIZE) {
> +			hisi_ptt->trace_ctrl.has_rmr = true;
> +			hisi_ptt->trace_ctrl.rmr_addr = region->start;
> +			hisi_ptt->trace_ctrl.rmr_length = region->length;
> +			break;
> +		}
> +
> +	iommu_put_resv_regions(&pdev->dev, &list);
> +	return hisi_ptt->trace_ctrl.has_rmr ? 0 : -ENOMEM;
> +}

No.

The whole point of RMRs is for devices that are already configured to 
access the given address range in a manner beyond the kernel's control. 
If you can do this, it proves that you should not have an RMR in the 
first place.

The notion of a kernel driver explicitly configuring its device to DMA 
into any random RMR that looks big enough is so egregiously wrong that 
I'm almost lost for words...

Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Yicong Yang <yangyicong@hisilicon.com>,
	gregkh@linuxfoundation.org, helgaas@kernel.org,
	alexander.shishkin@linux.intel.com, lorenzo.pieralisi@arm.com,
	will@kernel.org, mark.rutland@arm.com,
	mathieu.poirier@linaro.org, suzuki.poulose@arm.com,
	mike.leach@linaro.org, leo.yan@linaro.org,
	jonathan.cameron@huawei.com, daniel.thompson@linaro.org,
	joro@8bytes.org, john.garry@huawei.com,
	shameerali.kolothum.thodi@huawei.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org,
	linux-pci@vger.kernel.org, linux-perf-users@vger.kernel.org,
	iommu@lists.linux-foundation.org
Cc: prime.zeng@huawei.com, linuxarm@huawei.com,
	zhangshaokun@hisilicon.com, liuqi115@huawei.com
Subject: Re: [PATCH v2 2/6] hwtracing: Add trace function support for HiSilicon PCIe Tune and Trace device
Date: Tue, 16 Nov 2021 10:56:39 +0000	[thread overview]
Message-ID: <0b67745c-13dd-1fea-1b8b-d55212bad232@arm.com> (raw)
In-Reply-To: <20211116090625.53702-3-yangyicong@hisilicon.com>

On 2021-11-16 09:06, Yicong Yang via iommu wrote:
[...]
> +/*
> + * Get RMR address if provided by the firmware.
> + * Return 0 if the IOMMU doesn't present or the policy of the
> + * IOMMU domain is passthrough or we get a usable RMR region.
> + * Otherwise a negative value is returned.
> + */
> +static int hisi_ptt_get_rmr(struct hisi_ptt *hisi_ptt)
> +{
> +	struct pci_dev *pdev = hisi_ptt->pdev;
> +	struct iommu_domain *iommu_domain;
> +	struct iommu_resv_region *region;
> +	LIST_HEAD(list);
> +
> +	/*
> +	 * Use direct DMA if IOMMU does not present or the policy of the
> +	 * IOMMU domain is passthrough.
> +	 */
> +	iommu_domain = iommu_get_domain_for_dev(&pdev->dev);
> +	if (!iommu_domain || iommu_domain->type == IOMMU_DOMAIN_IDENTITY)
> +		return 0;
> +
> +	iommu_get_resv_regions(&pdev->dev, &list);
> +	list_for_each_entry(region, &list, list)
> +		if (region->type == IOMMU_RESV_DIRECT &&
> +		    region->length >= HISI_PTT_TRACE_BUFFER_SIZE) {
> +			hisi_ptt->trace_ctrl.has_rmr = true;
> +			hisi_ptt->trace_ctrl.rmr_addr = region->start;
> +			hisi_ptt->trace_ctrl.rmr_length = region->length;
> +			break;
> +		}
> +
> +	iommu_put_resv_regions(&pdev->dev, &list);
> +	return hisi_ptt->trace_ctrl.has_rmr ? 0 : -ENOMEM;
> +}

No.

The whole point of RMRs is for devices that are already configured to 
access the given address range in a manner beyond the kernel's control. 
If you can do this, it proves that you should not have an RMR in the 
first place.

The notion of a kernel driver explicitly configuring its device to DMA 
into any random RMR that looks big enough is so egregiously wrong that 
I'm almost lost for words...

Robin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-11-16 10:56 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-16  9:06 [PATCH v2 0/6] Add support for HiSilicon PCIe Tune and Trace device Yicong Yang
2021-11-16  9:06 ` Yicong Yang via iommu
2021-11-16  9:06 ` Yicong Yang
2021-11-16  9:06 ` [PATCH v2 1/6] iommu: Export iommu_{get,put}_resv_regions() Yicong Yang
2021-11-16  9:06   ` Yicong Yang via iommu
2021-11-16  9:06   ` Yicong Yang
2021-11-24 17:51   ` Mathieu Poirier
2021-11-24 17:51     ` Mathieu Poirier
2021-11-24 17:51     ` Mathieu Poirier
2021-12-06 11:56   ` Joerg Roedel
2021-12-06 11:56     ` Joerg Roedel
2021-12-06 11:56     ` Joerg Roedel
2021-12-06 12:56     ` Yicong Yang
2021-12-06 12:56       ` Yicong Yang
2021-12-06 12:56       ` Yicong Yang via iommu
2021-11-16  9:06 ` [PATCH v2 2/6] hwtracing: Add trace function support for HiSilicon PCIe Tune and Trace device Yicong Yang
2021-11-16  9:06   ` Yicong Yang via iommu
2021-11-16  9:06   ` Yicong Yang
2021-11-16 10:56   ` Robin Murphy [this message]
2021-11-16 10:56     ` Robin Murphy
2021-11-16 10:56     ` Robin Murphy
2021-11-16 11:37     ` Yicong Yang
2021-11-16 11:37       ` Yicong Yang via iommu
2021-11-16 11:37       ` Yicong Yang
2021-11-18  9:01       ` Yicong Yang
2021-11-18  9:01         ` Yicong Yang
2021-11-18  9:01         ` Yicong Yang via iommu
2021-11-25 15:49         ` Robin Murphy
2021-11-25 15:49           ` Robin Murphy
2021-11-25 15:49           ` Robin Murphy
2021-11-29  8:22           ` Yicong Yang via iommu
2021-11-29  8:22             ` Yicong Yang
2021-11-29  8:22             ` Yicong Yang
2021-12-07 16:31             ` Robin Murphy
2021-12-07 16:31               ` Robin Murphy
2021-12-07 16:31               ` Robin Murphy
2021-12-09 13:19               ` Yicong Yang
2021-12-09 13:19                 ` Yicong Yang
2021-12-09 13:19                 ` Yicong Yang via iommu
2021-11-24 18:51   ` Mathieu Poirier
2021-11-24 18:51     ` Mathieu Poirier
2021-11-24 18:51     ` Mathieu Poirier
2021-11-25  8:39     ` Yicong Yang via iommu
2021-11-25  8:39       ` Yicong Yang
2021-11-25  8:39       ` Yicong Yang
2021-11-25 18:50       ` Mathieu Poirier
2021-11-25 18:50         ` Mathieu Poirier
2021-11-25 18:50         ` Mathieu Poirier
2021-11-26 17:10         ` Mathieu Poirier
2021-11-26 17:10           ` Mathieu Poirier
2021-11-26 17:10           ` Mathieu Poirier
2021-11-29  8:59           ` Yicong Yang via iommu
2021-11-29  8:59             ` Yicong Yang
2021-11-29  8:59             ` Yicong Yang
2021-11-29  8:45         ` Yicong Yang via iommu
2021-11-29  8:45           ` Yicong Yang
2021-11-29  8:45           ` Yicong Yang
2021-11-16  9:06 ` [PATCH v2 3/6] hwtracing: Add tune " Yicong Yang
2021-11-16  9:06   ` Yicong Yang via iommu
2021-11-16  9:06   ` Yicong Yang
2021-11-16  9:06 ` [PATCH v2 4/6] perf tool: Add support for HiSilicon PCIe Tune and Trace device driver Yicong Yang
2021-11-16  9:06   ` Yicong Yang via iommu
2021-11-16  9:06   ` Yicong Yang
2021-11-16  9:06 ` [PATCH v2 5/6] docs: Add HiSilicon PTT device driver documentation Yicong Yang
2021-11-16  9:06   ` Yicong Yang via iommu
2021-11-16  9:06   ` Yicong Yang
2021-11-16  9:06 ` [PATCH v2 6/6] MAINTAINERS: Add maintainer for HiSilicon PTT driver Yicong Yang
2021-11-16  9:06   ` Yicong Yang via iommu
2021-11-16  9:06   ` Yicong Yang

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=0b67745c-13dd-1fea-1b8b-d55212bad232@arm.com \
    --to=robin.murphy@arm.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=coresight@lists.linaro.org \
    --cc=daniel.thompson@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=helgaas@kernel.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=john.garry@huawei.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=joro@8bytes.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=liuqi115@huawei.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=mike.leach@linaro.org \
    --cc=prime.zeng@huawei.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    --cc=yangyicong@hisilicon.com \
    --cc=zhangshaokun@hisilicon.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.