Convert Renesas VMSA-Compatible IOMMU bindings documentation
to json-schema.
Note that original documentation doesn't mention renesas,ipmmu-vmsa
for R-Mobile APE6. But, R-Mobile APE6 is similar to the R-Car
Gen2. So, renesas,ipmmu-r8a73a4 belongs the renesas,ipmmu-vmsa
section.
Signed-off-by:
Hi Kevin,
On 2020/4/16 9:46, Lu Baolu wrote:
On 2020/4/15 17:30, Tian, Kevin wrote:
From: Lu Baolu
Sent: Wednesday, April 15, 2020 1:26 PM
Currently, the page request interrupt thread handles the page
requests in the queue in this way:
- Clear PPR bit to ensure new interrupt could come in;
-
> From: Auger Eric
> Sent: Thursday, April 16, 2020 6:43 PM
>
[...]
> >>> + if (svm) {
> >>> + /*
> >>> + * If we found svm for the PASID, there must be at
> >>> + * least one device bond, otherwise svm should be
> >>> freed.
> >>> + */
> >>> + if
> From: Lu Baolu
> Sent: Thursday, April 16, 2020 4:38 PM
>
> Hi Kevin,
>
> On 2020/4/15 19:10, Tian, Kevin wrote:
> > the completion of above sequence ensures that previous queued
> > page group responses are sent out and received by the endpoint
> > and vice versa all in-fly page requests
> On Apr 13, 2020, at 9:36 PM, Qian Cai wrote:
>
>
>
>> On Apr 8, 2020, at 10:19 AM, Joerg Roedel wrote:
>>
>> Hi Qian,
>>
>> On Tue, Apr 07, 2020 at 11:36:05AM -0400, Qian Cai wrote:
>>> After further testing, the change along is insufficient. What I am chasing
>>> right
>>> now is the
On Fri, Apr 17, 2020 at 06:33:54AM +0800, Raj, Ashok wrote:
> Hi Zhao
>
>
> On Thu, Apr 16, 2020 at 06:12:26PM -0400, Yan Zhao wrote:
> > On Tue, Mar 31, 2020 at 03:08:25PM +0800, Lu, Baolu wrote:
> > > On 2020/3/31 14:35, Tian, Kevin wrote:
> > > >> From: Liu, Yi L
> > > >> Sent: Sunday, March
Hi Daniel,
On Fri, 2020-04-17 at 09:03 +0800, Daniel Drake wrote:
> Hi Joerg,
>
> > Hi,
> >
> > here is the second version of this patch-set. The first version with
> > some more introductory text can be found here:
> >
> >
Hi Joerg,
> Hi,
>
> here is the second version of this patch-set. The first version with
> some more introductory text can be found here:
>
> https://lore.kernel.org/lkml/20200407183742.4344-1-j...@8bytes.org/
Thanks for the continued improvements in this area!
I may have spotted a
On Tue, Mar 31, 2020 at 03:08:25PM +0800, Lu, Baolu wrote:
> On 2020/3/31 14:35, Tian, Kevin wrote:
> >> From: Liu, Yi L
> >> Sent: Sunday, March 22, 2020 8:33 PM
> >>
> >> From: Liu Yi L
> >>
> >> Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
> >> Intel platforms allows
Hi Zhao
On Thu, Apr 16, 2020 at 06:12:26PM -0400, Yan Zhao wrote:
> On Tue, Mar 31, 2020 at 03:08:25PM +0800, Lu, Baolu wrote:
> > On 2020/3/31 14:35, Tian, Kevin wrote:
> > >> From: Liu, Yi L
> > >> Sent: Sunday, March 22, 2020 8:33 PM
> > >>
> > >> From: Liu Yi L
> > >>
> > >> Shared Virtual
On Wed, 15 Apr 2020 09:47:36 +0200
Jean-Philippe Brucker wrote:
> On Fri, Apr 10, 2020 at 08:52:49AM -0700, Jacob Pan wrote:
> > On Thu, 9 Apr 2020 16:50:58 +0200
> > Jean-Philippe Brucker wrote:
> >
> > > > So unbind is coming anyway, the difference in handling in mmu
> > > > release
On Tue, Apr 14, 2020 at 03:13:30PM +0200, Christoph Hellwig wrote:
> This allows to unexport map_vm_area and unmap_kernel_range, which are
> rather deep internal and should not be available to modules, as they for
> example allow fine grained control of mapping permissions, and also
> allow
Hi Christoph,
Sorry for the late.
On Sat, Apr 11, 2020 at 09:20:52AM +0200, Christoph Hellwig wrote:
> Hi Minchan,
>
> On Fri, Apr 10, 2020 at 04:11:36PM -0700, Minchan Kim wrote:
> > It doesn't mean we couldn't use zsmalloc as module any longer. It means
> > we couldn't use zsmalloc as module
Hi Robin,
On 2020-04-16 22:47, Robin Murphy wrote:
On 2020-04-16 5:23 pm, Sai Prakash Ranjan wrote:
Hi Robin,
On 2020-04-16 19:28, Robin Murphy wrote:
On 2020-01-22 11:48 am, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves
On 2020-04-16 5:23 pm, Sai Prakash Ranjan wrote:
Hi Robin,
On 2020-04-16 19:28, Robin Murphy wrote:
On 2020-01-22 11:48 am, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt
Hi Robin,
On 2020-04-16 19:28, Robin Murphy wrote:
On 2020-01-22 11:48 am, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of
Hi Kevin,
On 4/16/20 3:28 PM, Tian, Kevin wrote:
>> From: Auger Eric
>> Sent: Thursday, April 16, 2020 8:43 PM
>>
>> Hi Kevin,
>> On 4/16/20 2:09 PM, Tian, Kevin wrote:
From: Liu, Yi L
Sent: Thursday, April 16, 2020 6:40 PM
Hi Alex,
Still have a direction question with
On Thu, 16 Apr 2020 08:40:31 -0600
Alex Williamson wrote:
> On Thu, 16 Apr 2020 10:40:03 +
> "Liu, Yi L" wrote:
>
> > Hi Alex,
> > Still have a direction question with you. Better get agreement with you
> > before heading forward.
> >
> > > From: Alex Williamson
> > > Sent: Friday,
On Thu, 16 Apr 2020 10:40:03 +
"Liu, Yi L" wrote:
> Hi Alex,
> Still have a direction question with you. Better get agreement with you
> before heading forward.
>
> > From: Alex Williamson
> > Sent: Friday, April 3, 2020 11:35 PM
> [...]
> > > > > + *
> > > > > + * returns: 0 on success,
On 4/15/2020 7:04 PM, Lorenzo Pieralisi wrote:
> On Wed, Apr 15, 2020 at 06:44:37PM +0300, Laurentiu Tudor wrote:
>>
>>
>> On 4/14/2020 5:32 PM, Lorenzo Pieralisi wrote:
>>> On Wed, Mar 25, 2020 at 06:48:55PM +0200, Laurentiu Tudor wrote:
Hi Lorenzo,
On 3/25/2020 2:51 PM, Lorenzo
On 2020-01-22 11:48 am, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Signed-off-by: Jordan Crouse
On 2020-01-22 11:48 am, Sai Prakash Ranjan wrote:
Currently the QCOM specific smmu reset implementation is very
specific to SDM845 SoC and has a wait-for-safe logic which
may not be required for other SoCs. So move the SDM845 specific
logic to its specific reset function. Also add SC7180 SMMU
> From: Auger Eric
> Sent: Thursday, April 16, 2020 8:43 PM
>
> Hi Kevin,
> On 4/16/20 2:09 PM, Tian, Kevin wrote:
> >> From: Liu, Yi L
> >> Sent: Thursday, April 16, 2020 6:40 PM
> >>
> >> Hi Alex,
> >> Still have a direction question with you. Better get agreement with you
> >> before heading
Hi Kevin,
On 4/16/20 2:09 PM, Tian, Kevin wrote:
>> From: Liu, Yi L
>> Sent: Thursday, April 16, 2020 6:40 PM
>>
>> Hi Alex,
>> Still have a direction question with you. Better get agreement with you
>> before heading forward.
>>
>>> From: Alex Williamson
>>> Sent: Friday, April 3, 2020 11:35 PM
On Thu, Apr 16, 2020 at 10:54:02AM +0200, Jean-Philippe Brucker wrote:
> On Thu, Apr 16, 2020 at 12:28:52AM -0700, Christoph Hellwig wrote:
> > > + rcu_read_lock();
> > > + hlist_for_each_entry_rcu(bond, _mm->devices, mm_node)
> > > + io_mm->ops->invalidate(bond->sva.dev, io_mm->pasid,
> From: Liu, Yi L
> Sent: Thursday, April 16, 2020 6:40 PM
>
> Hi Alex,
> Still have a direction question with you. Better get agreement with you
> before heading forward.
>
> > From: Alex Williamson
> > Sent: Friday, April 3, 2020 11:35 PM
> [...]
> > > > > + *
> > > > > + * returns: 0 on
Hi Joerg,
On 14.04.2020 15:15, Joerg Roedel wrote:
> here is the second version of this patch-set. The first version with
> some more introductory text can be found here:
>
> https://lore.kernel.org/lkml/20200407183742.4344-1-j...@8bytes.org/
>
> Changes v1->v2:
>
> * Rebased to
Hi Jacob,
On 4/10/20 11:56 PM, Jacob Pan wrote:
> On Thu, 9 Apr 2020 10:50:34 +0200
> Auger Eric wrote:
>
>> Hi Jacob,
>>
>> On 4/3/20 8:42 PM, Jacob Pan wrote:
>>> When Shared Virtual Address (SVA) is enabled for a guest OS via
>>> vIOMMU, we need to provide invalidation support at IOMMU API
Hi Jacob,
On 4/10/20 11:06 PM, Jacob Pan wrote:
> Hi Eric,
>
> Missed a few things in the last reply.
>
> On Thu, 9 Apr 2020 09:41:32 +0200
> Auger Eric wrote:
>
>>> + intel_pasid_tear_down_entry(iommu, dev,
>>> svm->pasid);
>> intel_svm_unbind_mm() calls
Hi Jacob,
On 4/10/20 9:45 PM, Jacob Pan wrote:
> Hi Eric,
>
> On Thu, 9 Apr 2020 09:41:32 +0200
> Auger Eric wrote:
>
>> Hi Jacob,
>>
>> On 4/3/20 8:42 PM, Jacob Pan wrote:
>>> When supporting guest SVA with emulated IOMMU, the guest PASID
>>> table is shadowed in VMM. Updates to guest vIOMMU
Hi Alex,
Still have a direction question with you. Better get agreement with you
before heading forward.
> From: Alex Williamson
> Sent: Friday, April 3, 2020 11:35 PM
[...]
> > > > + *
> > > > + * returns: 0 on success, -errno on failure.
> > > > + */
> > > > +struct
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Thursday, April 16, 2020 7:06 PM
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
>
> > > > + renesas,ipmmu-main:
> > > > +$ref: /schemas/types.yaml#/definitions/phandle-array
> > > > +
On 2020/4/16 18:05, Robin Murphy wrote:
On 2020-04-02 7:33 am, Tang Bin wrote:
Release resources when exiting on error.
Signed-off-by: Tang Bin
---
drivers/iommu/qcom_iommu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/qcom_iommu.c
Hi Shimoda-san,
On Thu, Apr 16, 2020 at 11:56 AM Yoshihiro Shimoda
wrote:
> > From: Geert Uytterhoeven, Sent: Wednesday, April 15, 2020 11:21 PM
> > On Tue, Apr 14, 2020 at 2:26 AM Yoshihiro Shimoda
> > wrote:
> > > Convert Renesas VMSA-Compatible IOMMU bindings documentation
> > > to
On 2020-04-02 7:33 am, Tang Bin wrote:
Release resources when exiting on error.
Signed-off-by: Tang Bin
---
drivers/iommu/qcom_iommu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
index 4328da0b0..c08aa9651
Hi Geert-san,
Thank you for your review!
> From: Geert Uytterhoeven, Sent: Wednesday, April 15, 2020 11:21 PM
>
> Hi Shimoda-san,
>
> On Tue, Apr 14, 2020 at 2:26 AM Yoshihiro Shimoda
> wrote:
> > Convert Renesas VMSA-Compatible IOMMU bindings documentation
> > to json-schema.
> >
> >
Both of_platform.h and of_device.h were included each other.
In of_device.h, removed unneeded #include to of_platform.h
and added include to of_platform.h in the files that needs it.
Signed-off-by: Hadar Gat
---
v2: add include to of_platform.h in more files. (reported due other builds)
On Thu, Apr 16, 2020 at 12:28:52AM -0700, Christoph Hellwig wrote:
> > + rcu_read_lock();
> > + hlist_for_each_entry_rcu(bond, _mm->devices, mm_node)
> > + io_mm->ops->invalidate(bond->sva.dev, io_mm->pasid, io_mm->ctx,
> > + start, end - start);
> >
Hi Kevin,
On 2020/4/15 19:10, Tian, Kevin wrote:
the completion of above sequence ensures that previous queued
page group responses are sent out and received by the endpoint
and vice versa all in-fly page requests from the endpoint are queued
in iommu page request queue. Then comes a problem -
Hi Zhangfei,
On 4/16/20 6:25 AM, Zhangfei Gao wrote:
>
>
> On 2020/4/14 下午11:05, Eric Auger wrote:
>> This version fixes an issue observed by Shameer on an SMMU 3.2,
>> when moving from dual stage config to stage 1 only config.
>> The 2 high 64b of the STE now get reset. Otherwise, leaving the
Hi Christoph,
On 2020/4/16 15:01, Christoph Hellwig wrote:
On Thu, Apr 16, 2020 at 02:23:52PM +0800, Lu Baolu wrote:
Currently, if a 32bit device initially uses an identity domain,
Intel IOMMU driver will convert it forcibly to a DMA one if its
address capability is not enough for the whole
> + rcu_read_lock();
> + hlist_for_each_entry_rcu(bond, _mm->devices, mm_node)
> + io_mm->ops->invalidate(bond->sva.dev, io_mm->pasid, io_mm->ctx,
> +start, end - start);
> + rcu_read_unlock();
> +}
What is the reason that the devices
On Thu, Apr 16, 2020 at 02:23:52PM +0800, Lu Baolu wrote:
> Currently, if a 32bit device initially uses an identity domain,
> Intel IOMMU driver will convert it forcibly to a DMA one if its
> address capability is not enough for the whole system memory.
> The motivation was to overcome the
Hi Bjorn:
On 2020/4/2 14:45, Bjorn Andersson wrote:
On Wed 01 Apr 23:33 PDT 2020, Tang Bin wrote:
Release resources when exiting on error.
Reviewed-by: Bjorn Andersson
Thanks for your positive feedback.
I don't know whether the commit message affect this patch's result. If
so, I think
Currently, if a 32bit device initially uses an identity domain,
Intel IOMMU driver will convert it forcibly to a DMA one if its
address capability is not enough for the whole system memory.
The motivation was to overcome the overhead caused by possible
bounced buffer.
Unfortunately, this
Some devices are required to use a specific type (identity or dma)
of default domain when they are used with a vendor iommu. When the
system level default domain type is different from it, the vendor
iommu driver has to request a new default domain with either
iommu_request_dma_domain_for_dev() or
Before commit fa954e6831789 ("iommu/vt-d: Delegate the dma domain
to upper layer"), Intel IOMMU started off with all devices in the
identity domain, and took them out later if it found they couldn't
access all of memory. This required devices behind a PCI bridge to
use a DMA domain at the
Current Intel IOMMU driver sets the system level dma_ops. This
causes each dma API to go through the IOMMU driver even the
devices are using identity mapped domains. This sets per-device
dma_ops only if a device is using a DMA domain. Otherwise, use
the default system level dma_ops for direct dma.
48 matches
Mail list logo
