From: Lu Baolu <baolu.lu@linux.intel.com>
To: Tom Murphy <tmurphy@arista.com>
Cc: baolu.lu@linux.intel.com, iommu@lists.linux-foundation.org,
Tom Murphy <murphyt7@tcd.ie>, Joerg Roedel <joro@8bytes.org>,
Will Deacon <will.deacon@arm.com>,
Robin Murphy <robin.murphy@arm.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Kukjin Kim <kgene@kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
David Woodhouse <dwmw2@infradead.org>,
Andy Gross <andy.gross@linaro.org>,
David Brown <david.brown@linaro.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Rob Clark <robdclark@gmail.com>, Heiko Stuebner <heiko@sntech.de>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Thierry Reding <thierry.reding@gmail.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
Alex Williamson <alex.williamson@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Marc
Subject: Re: [RFC 6/7] iommu/vt-d: convert the intel iommu driver to the dma-iommu ops api
Date: Mon, 6 May 2019 09:34:59 +0800 [thread overview]
Message-ID: <2419e94d-bfdb-e70d-bbfd-425671886e99@linux.intel.com> (raw)
In-Reply-To: <CAPL0++57nyLYP1fq=-6zvNS0z_iCqjWLbQ1MsG5F60ODkmRCQQ@mail.gmail.com>
Hi,
On 5/6/19 1:03 AM, Tom Murphy wrote:
> On Sun, May 5, 2019 at 3:44 AM Lu Baolu<baolu.lu@linux.intel.com> wrote:
>> Hi,
>>
>> On 5/4/19 9:23 PM, Tom Murphy wrote:
>>> static int intel_iommu_add_device(struct device *dev)
>>> {
>>> + struct dmar_domain *dmar_domain;
>>> + struct iommu_domain *domain;
>>> struct intel_iommu *iommu;
>>> struct iommu_group *group;
>>> - struct iommu_domain *domain;
>>> + dma_addr_t base;
>>> u8 bus, devfn;
>>>
>>> iommu = device_to_iommu(dev, &bus, &devfn);
>>> @@ -4871,9 +4514,12 @@ static int intel_iommu_add_device(struct device *dev)
>>> if (IS_ERR(group))
>>> return PTR_ERR(group);
>>>
>>> + base = IOVA_START_PFN << VTD_PAGE_SHIFT;
>>> domain = iommu_get_domain_for_dev(dev);
>>> + dmar_domain = to_dmar_domain(domain);
>>> if (domain->type == IOMMU_DOMAIN_DMA)
>>> - dev->dma_ops = &intel_dma_ops;
>>> + iommu_setup_dma_ops(dev, base,
>>> + __DOMAIN_MAX_ADDR(dmar_domain->gaw) - base);
>> I didn't find the implementation of iommu_setup_dma_ops() in this
>> series. Will the iova resource be initialized in this function?
> Ah sorry, I should've mentioned this is based on the
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-iommu-ops.3
> branch with the "iommu/vt-d: Delegate DMA domain to generic iommu" and
> "iommu/amd: Convert the AMD iommu driver to the dma-iommu api" patch
> sets applied.
>
>> If so, will this block iommu_group_create_direct_mappings() which
>> reserves and maps the reserved iova ranges.
> The reserved regions will be reserved by the
> iova_reserve_iommu_regions function instead:
> (https://github.com/torvalds/linux/blob/6203838dec05352bc357625b1e9ba0a10d3bca35/drivers/iommu/dma-iommu.c#L238
> )
> iommu_setup_dma_ops calls iommu_dma_init_domain which calls
> iova_reserve_iommu_regions.
> iommu_group_create_direct_mappings will still execute normally but it
> won't be able to call the intel_iommu_apply_resv_region function
> because it's been removed in this patchset.
> This shouldn't change any behavior and the same regions should be reserved.
>
Okay, I understand it now. Thanks for the explanation.
Best regards,
Lu Baolu
WARNING: multiple messages have this Message-ID (diff)
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Tom Murphy <tmurphy@arista.com>
Cc: baolu.lu@linux.intel.com, iommu@lists.linux-foundation.org,
Tom Murphy <murphyt7@tcd.ie>, Joerg Roedel <joro@8bytes.org>,
Will Deacon <will.deacon@arm.com>,
Robin Murphy <robin.murphy@arm.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Kukjin Kim <kgene@kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
David Woodhouse <dwmw2@infradead.org>,
Andy Gross <andy.gross@linaro.org>,
David Brown <david.brown@linaro.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Rob Clark <robdclark@gmail.com>, Heiko Stuebner <heiko@sntech.de>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Thierry Reding <thierry.reding@gmail.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
Alex Williamson <alex.williamson@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <marc.zyngier@arm.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-mediatek@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-tegra@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [RFC 6/7] iommu/vt-d: convert the intel iommu driver to the dma-iommu ops api
Date: Mon, 6 May 2019 09:34:59 +0800 [thread overview]
Message-ID: <2419e94d-bfdb-e70d-bbfd-425671886e99@linux.intel.com> (raw)
Message-ID: <20190506013459.x5cBuHBKWR7_T6oXEtsEwa7oaHe7m5ijfeigADgCqso@z> (raw)
In-Reply-To: <CAPL0++57nyLYP1fq=-6zvNS0z_iCqjWLbQ1MsG5F60ODkmRCQQ@mail.gmail.com>
Hi,
On 5/6/19 1:03 AM, Tom Murphy wrote:
> On Sun, May 5, 2019 at 3:44 AM Lu Baolu<baolu.lu@linux.intel.com> wrote:
>> Hi,
>>
>> On 5/4/19 9:23 PM, Tom Murphy wrote:
>>> static int intel_iommu_add_device(struct device *dev)
>>> {
>>> + struct dmar_domain *dmar_domain;
>>> + struct iommu_domain *domain;
>>> struct intel_iommu *iommu;
>>> struct iommu_group *group;
>>> - struct iommu_domain *domain;
>>> + dma_addr_t base;
>>> u8 bus, devfn;
>>>
>>> iommu = device_to_iommu(dev, &bus, &devfn);
>>> @@ -4871,9 +4514,12 @@ static int intel_iommu_add_device(struct device *dev)
>>> if (IS_ERR(group))
>>> return PTR_ERR(group);
>>>
>>> + base = IOVA_START_PFN << VTD_PAGE_SHIFT;
>>> domain = iommu_get_domain_for_dev(dev);
>>> + dmar_domain = to_dmar_domain(domain);
>>> if (domain->type == IOMMU_DOMAIN_DMA)
>>> - dev->dma_ops = &intel_dma_ops;
>>> + iommu_setup_dma_ops(dev, base,
>>> + __DOMAIN_MAX_ADDR(dmar_domain->gaw) - base);
>> I didn't find the implementation of iommu_setup_dma_ops() in this
>> series. Will the iova resource be initialized in this function?
> Ah sorry, I should've mentioned this is based on the
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-iommu-ops.3
> branch with the "iommu/vt-d: Delegate DMA domain to generic iommu" and
> "iommu/amd: Convert the AMD iommu driver to the dma-iommu api" patch
> sets applied.
>
>> If so, will this block iommu_group_create_direct_mappings() which
>> reserves and maps the reserved iova ranges.
> The reserved regions will be reserved by the
> iova_reserve_iommu_regions function instead:
> (https://github.com/torvalds/linux/blob/6203838dec05352bc357625b1e9ba0a10d3bca35/drivers/iommu/dma-iommu.c#L238
> )
> iommu_setup_dma_ops calls iommu_dma_init_domain which calls
> iova_reserve_iommu_regions.
> iommu_group_create_direct_mappings will still execute normally but it
> won't be able to call the intel_iommu_apply_resv_region function
> because it's been removed in this patchset.
> This shouldn't change any behavior and the same regions should be reserved.
>
Okay, I understand it now. Thanks for the explanation.
Best regards,
Lu Baolu
WARNING: multiple messages have this Message-ID (diff)
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Tom Murphy <tmurphy@arista.com>
Cc: Heiko Stuebner <heiko@sntech.de>,
kvm@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
David Brown <david.brown@linaro.org>,
Thierry Reding <thierry.reding@gmail.com>,
linux-s390@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
iommu@lists.linux-foundation.org,
Krzysztof Kozlowski <krzk@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
linux-rockchip@lists.infradead.org, Kukjin Kim <kgene@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Andy Gross <andy.gross@linaro.org>,
linux-tegra@vger.kernel.org, Marc Zyngier <marc.zyngier@arm.com>,
linux-arm-msm@vger.kernel.org,
Alex Williamson <alex.williamson@redhat.com>,
linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Robin Murphy <robin.murphy@arm.com>,
linux-kernel@vger.kernel.org, Tom Murphy <murphyt7@tcd.ie>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [RFC 6/7] iommu/vt-d: convert the intel iommu driver to the dma-iommu ops api
Date: Mon, 6 May 2019 09:34:59 +0800 [thread overview]
Message-ID: <2419e94d-bfdb-e70d-bbfd-425671886e99@linux.intel.com> (raw)
In-Reply-To: <CAPL0++57nyLYP1fq=-6zvNS0z_iCqjWLbQ1MsG5F60ODkmRCQQ@mail.gmail.com>
Hi,
On 5/6/19 1:03 AM, Tom Murphy wrote:
> On Sun, May 5, 2019 at 3:44 AM Lu Baolu<baolu.lu@linux.intel.com> wrote:
>> Hi,
>>
>> On 5/4/19 9:23 PM, Tom Murphy wrote:
>>> static int intel_iommu_add_device(struct device *dev)
>>> {
>>> + struct dmar_domain *dmar_domain;
>>> + struct iommu_domain *domain;
>>> struct intel_iommu *iommu;
>>> struct iommu_group *group;
>>> - struct iommu_domain *domain;
>>> + dma_addr_t base;
>>> u8 bus, devfn;
>>>
>>> iommu = device_to_iommu(dev, &bus, &devfn);
>>> @@ -4871,9 +4514,12 @@ static int intel_iommu_add_device(struct device *dev)
>>> if (IS_ERR(group))
>>> return PTR_ERR(group);
>>>
>>> + base = IOVA_START_PFN << VTD_PAGE_SHIFT;
>>> domain = iommu_get_domain_for_dev(dev);
>>> + dmar_domain = to_dmar_domain(domain);
>>> if (domain->type == IOMMU_DOMAIN_DMA)
>>> - dev->dma_ops = &intel_dma_ops;
>>> + iommu_setup_dma_ops(dev, base,
>>> + __DOMAIN_MAX_ADDR(dmar_domain->gaw) - base);
>> I didn't find the implementation of iommu_setup_dma_ops() in this
>> series. Will the iova resource be initialized in this function?
> Ah sorry, I should've mentioned this is based on the
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-iommu-ops.3
> branch with the "iommu/vt-d: Delegate DMA domain to generic iommu" and
> "iommu/amd: Convert the AMD iommu driver to the dma-iommu api" patch
> sets applied.
>
>> If so, will this block iommu_group_create_direct_mappings() which
>> reserves and maps the reserved iova ranges.
> The reserved regions will be reserved by the
> iova_reserve_iommu_regions function instead:
> (https://github.com/torvalds/linux/blob/6203838dec05352bc357625b1e9ba0a10d3bca35/drivers/iommu/dma-iommu.c#L238
> )
> iommu_setup_dma_ops calls iommu_dma_init_domain which calls
> iova_reserve_iommu_regions.
> iommu_group_create_direct_mappings will still execute normally but it
> won't be able to call the intel_iommu_apply_resv_region function
> because it's been removed in this patchset.
> This shouldn't change any behavior and the same regions should be reserved.
>
Okay, I understand it now. Thanks for the explanation.
Best regards,
Lu Baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Tom Murphy <tmurphy@arista.com>
Cc: Heiko Stuebner <heiko@sntech.de>,
kvm@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
David Brown <david.brown@linaro.org>,
Thierry Reding <thierry.reding@gmail.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
linux-s390@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
Joerg Roedel <joro@8bytes.org>,
iommu@lists.linux-foundation.org,
Krzysztof Kozlowski <krzk@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
linux-rockchip@lists.infradead.org, Kukjin Kim <kgene@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Andy Gross <andy.gross@linaro.org>,
linux-tegra@vger.kernel.org, Marc Zyngier <marc.zyngier@arm.com>,
linux-arm-msm@vger.kernel.org,
Alex Williamson <alex.williamson@redhat.com>,
linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Robin Murphy <robin.murphy@arm.com>,
linux-kernel@vger.kernel.org, Tom Murphy <murphyt7@tcd.ie>,
Rob Clark <robdclark@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
baolu.lu@linux.intel.com
Subject: Re: [RFC 6/7] iommu/vt-d: convert the intel iommu driver to the dma-iommu ops api
Date: Mon, 6 May 2019 09:34:59 +0800 [thread overview]
Message-ID: <2419e94d-bfdb-e70d-bbfd-425671886e99@linux.intel.com> (raw)
In-Reply-To: <CAPL0++57nyLYP1fq=-6zvNS0z_iCqjWLbQ1MsG5F60ODkmRCQQ@mail.gmail.com>
Hi,
On 5/6/19 1:03 AM, Tom Murphy wrote:
> On Sun, May 5, 2019 at 3:44 AM Lu Baolu<baolu.lu@linux.intel.com> wrote:
>> Hi,
>>
>> On 5/4/19 9:23 PM, Tom Murphy wrote:
>>> static int intel_iommu_add_device(struct device *dev)
>>> {
>>> + struct dmar_domain *dmar_domain;
>>> + struct iommu_domain *domain;
>>> struct intel_iommu *iommu;
>>> struct iommu_group *group;
>>> - struct iommu_domain *domain;
>>> + dma_addr_t base;
>>> u8 bus, devfn;
>>>
>>> iommu = device_to_iommu(dev, &bus, &devfn);
>>> @@ -4871,9 +4514,12 @@ static int intel_iommu_add_device(struct device *dev)
>>> if (IS_ERR(group))
>>> return PTR_ERR(group);
>>>
>>> + base = IOVA_START_PFN << VTD_PAGE_SHIFT;
>>> domain = iommu_get_domain_for_dev(dev);
>>> + dmar_domain = to_dmar_domain(domain);
>>> if (domain->type == IOMMU_DOMAIN_DMA)
>>> - dev->dma_ops = &intel_dma_ops;
>>> + iommu_setup_dma_ops(dev, base,
>>> + __DOMAIN_MAX_ADDR(dmar_domain->gaw) - base);
>> I didn't find the implementation of iommu_setup_dma_ops() in this
>> series. Will the iova resource be initialized in this function?
> Ah sorry, I should've mentioned this is based on the
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-iommu-ops.3
> branch with the "iommu/vt-d: Delegate DMA domain to generic iommu" and
> "iommu/amd: Convert the AMD iommu driver to the dma-iommu api" patch
> sets applied.
>
>> If so, will this block iommu_group_create_direct_mappings() which
>> reserves and maps the reserved iova ranges.
> The reserved regions will be reserved by the
> iova_reserve_iommu_regions function instead:
> (https://github.com/torvalds/linux/blob/6203838dec05352bc357625b1e9ba0a10d3bca35/drivers/iommu/dma-iommu.c#L238
> )
> iommu_setup_dma_ops calls iommu_dma_init_domain which calls
> iova_reserve_iommu_regions.
> iommu_group_create_direct_mappings will still execute normally but it
> won't be able to call the intel_iommu_apply_resv_region function
> because it's been removed in this patchset.
> This shouldn't change any behavior and the same regions should be reserved.
>
Okay, I understand it now. Thanks for the explanation.
Best regards,
Lu Baolu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-05-06 1:34 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-04 13:23 [RFC 0/7] Convert the Intel iommu driver to the dma-ops api Tom Murphy
2019-05-04 13:23 ` Tom Murphy
2019-05-04 13:23 ` Tom Murphy via iommu
2019-05-04 13:23 ` Tom Murphy
2019-05-04 13:23 ` [RFC 1/7] iommu/vt-d: Set the dma_ops per device so we can remove the iommu_no_mapping code Tom Murphy
2019-05-04 13:23 ` Tom Murphy
2019-05-04 13:23 ` Tom Murphy via iommu
2019-05-04 13:23 ` Tom Murphy
2019-05-06 1:42 ` Lu Baolu
2019-05-06 1:42 ` Lu Baolu
2019-05-06 1:42 ` Lu Baolu
2019-05-06 1:42 ` Lu Baolu
2019-05-06 15:27 ` Tom Murphy
2019-05-06 15:27 ` Tom Murphy
2019-05-06 15:27 ` Tom Murphy via iommu
2019-05-06 15:27 ` Tom Murphy
2019-05-04 13:23 ` [RFC 2/7] iommu/vt-d: Remove iova handling code from non-dma ops path Tom Murphy
2019-05-04 13:23 ` Tom Murphy
2019-05-04 13:23 ` Tom Murphy via iommu
2019-05-04 13:23 ` Tom Murphy
2019-05-05 1:19 ` Lu Baolu
2019-05-05 1:19 ` Lu Baolu
2019-05-05 1:19 ` Lu Baolu
2019-05-05 1:19 ` Lu Baolu
2019-05-05 1:22 ` Lu Baolu
2019-05-05 1:22 ` Lu Baolu
2019-05-05 1:22 ` Lu Baolu
2019-05-05 1:22 ` Lu Baolu
2019-05-04 13:23 ` [RFC 3/7] iommu: improve iommu iotlb flushing Tom Murphy
2019-05-04 13:23 ` Tom Murphy
2019-05-04 13:23 ` Tom Murphy via iommu
2019-05-04 13:23 ` Tom Murphy
2019-05-04 13:23 ` [RFC 4/7] iommu/dma-iommu: Handle freelists in the dma-iommu api path Tom Murphy
2019-05-04 13:23 ` Tom Murphy
2019-05-04 13:23 ` Tom Murphy via iommu
2019-05-04 13:23 ` Tom Murphy
2019-05-04 13:23 ` [RFC 5/7] iommu/dma-iommu: add wrapper for iommu_dma_free_cpu_cached_iovas Tom Murphy
2019-05-04 13:23 ` Tom Murphy
2019-05-04 13:23 ` Tom Murphy via iommu
2019-05-04 13:23 ` Tom Murphy
2019-05-04 13:23 ` [RFC 6/7] iommu/vt-d: convert the intel iommu driver to the dma-iommu ops api Tom Murphy
2019-05-04 13:23 ` Tom Murphy
2019-05-04 13:23 ` Tom Murphy via iommu
2019-05-04 13:23 ` Tom Murphy
2019-05-05 2:37 ` Lu Baolu
2019-05-05 2:37 ` Lu Baolu
2019-05-05 2:37 ` Lu Baolu
2019-05-05 2:37 ` Lu Baolu
2019-05-05 17:03 ` Tom Murphy
2019-05-05 17:03 ` Tom Murphy
2019-05-05 17:03 ` Tom Murphy via iommu
2019-05-05 17:03 ` Tom Murphy
2019-05-06 1:34 ` Lu Baolu [this message]
2019-05-06 1:34 ` Lu Baolu
2019-05-06 1:34 ` Lu Baolu
2019-05-06 1:34 ` Lu Baolu
2019-05-04 13:23 ` [RFC 7/7] iommu/vt-d: Always set DMA_PTE_READ if the iommu doens't support zero length reads Tom Murphy
2019-05-04 13:23 ` Tom Murphy
2019-05-04 13:23 ` Tom Murphy via iommu
2019-05-04 13:23 ` Tom 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=2419e94d-bfdb-e70d-bbfd-425671886e99@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=andy.gross@linaro.org \
--cc=david.brown@linaro.org \
--cc=dwmw2@infradead.org \
--cc=gerald.schaefer@de.ibm.com \
--cc=heiko@sntech.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jonathanh@nvidia.com \
--cc=joro@8bytes.org \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=matthias.bgg@gmail.com \
--cc=murphyt7@tcd.ie \
--cc=robdclark@gmail.com \
--cc=robin.murphy@arm.com \
--cc=tglx@linutronix.de \
--cc=thierry.reding@gmail.com \
--cc=tmurphy@arista.com \
--cc=will.deacon@arm.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.