Hi,
On 10/29/19 12:11 PM, Jacob Pan wrote:
On Tue, 29 Oct 2019 10:54:48 +0800
Lu Baolu wrote:
Hi,
On 10/29/19 6:29 AM, Jacob Pan wrote:
Hi Baolu,
Appreciate the thorough review, comments inline.
You are welcome.
On Sat, 26 Oct 2019 10:01:19 +0800
Lu Baolu wrote:
Hi,
[...]
+
On Tue, 29 Oct 2019 10:54:48 +0800
Lu Baolu wrote:
> Hi,
>
> On 10/29/19 6:29 AM, Jacob Pan wrote:
> > Hi Baolu,
> >
> > Appreciate the thorough review, comments inline.
>
> You are welcome.
>
> >
> > On Sat, 26 Oct 2019 10:01:19 +0800
> > Lu Baolu wrote:
> >
> >> Hi,
> >>
>
> [...]
Hi,
On 10/29/19 6:29 AM, Jacob Pan wrote:
Hi Baolu,
Appreciate the thorough review, comments inline.
You are welcome.
On Sat, 26 Oct 2019 10:01:19 +0800
Lu Baolu wrote:
Hi,
[...]
+* allow multiple bind calls with the same
PASID and pdev.
+
Hi,
On 10/28/19 2:03 PM, Tian, Kevin wrote:
.dev_disable_feat = intel_iommu_dev_disable_feat,
.is_attach_deferred =
intel_iommu_is_attach_deferred, .pgsize_bitmap =
INTEL_IOMMU_PGSIZES, +#ifdef CONFIG_INTEL_IOMMU_SVM
+ .sva_bind_gpasid= intel_svm_
Hi,
On 10/29/19 6:49 AM, Jacob Pan wrote:
I'm not sure whether tying above logic to SVA is the right
approach. If vcmd interface doesn't work, the whole SM mode
doesn't make sense which is based on PASID-granular protection
(SVA is only one usage atop). If the only remaining usage of SM
is to ma
On 2019-10-28 10:38 pm, Rob Clark wrote:
On Mon, Oct 28, 2019 at 3:20 PM Will Deacon wrote:
Hi Rob,
On Mon, Oct 07, 2019 at 01:49:06PM -0700, Rob Clark wrote:
From: Rob Clark
When games, browser, or anything using a lot of GPU buffers exits, there
can be many hundreds or thousands of buffe
On Fri, 25 Oct 2019 06:31:04 +
"Tian, Kevin" wrote:
> > From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> > Sent: Friday, October 25, 2019 3:55 AM
> >
> > When VT-d driver runs in the guest, PASID allocation must be
> > performed via virtual command interface. This patch registers a
>
On Fri, 25 Oct 2019 15:52:39 +
"Tian, Kevin" wrote:
> > From: Lu Baolu [mailto:baolu...@linux.intel.com]
> > Sent: Friday, October 25, 2019 10:39 PM
> >
> > Hi,
> >
> > On 10/25/19 2:40 PM, Tian, Kevin wrote:
> > ioasid_register_allocator(&iommu->pasid_allocator);
> > +
On Fri, 25 Oct 2019 06:41:16 +
"Tian, Kevin" wrote:
> > From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> > Sent: Friday, October 25, 2019 3:55 AM
> >
> > Make use of generic IOASID code to manage PASID allocation,
> > free, and lookup. Replace Intel specific code.
> >
> > Signed-off
On Fri, 25 Oct 2019 06:42:54 +
"Tian, Kevin" wrote:
> > From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> > Sent: Friday, October 25, 2019 3:55 AM
> >
> > After each setup for PASID entry, related translation caches must be
> > flushed.
> > We can combine duplicated code into one func
On Sat, 26 Oct 2019 09:00:51 +0800
Lu Baolu wrote:
> Hi,
>
> On 10/25/19 3:55 AM, Jacob Pan wrote:
> > Use combined macros for_each_svm_dev() to simplify SVM device
> > iteration and error checking.
> >
> > Suggested-by: Andy Shevchenko
> > Signed-off-by: Jacob Pan
> > Reviewed-by: Eric Auger
Hi Baolu,
Appreciate the thorough review, comments inline.
On Sat, 26 Oct 2019 10:01:19 +0800
Lu Baolu wrote:
> Hi,
>
> On 10/25/19 3:55 AM, Jacob Pan wrote:
> > When supporting guest SVA with emulated IOMMU, the guest PASID
> > table is shadowed in VMM. Updates to guest vIOMMU PASID table
> >
Hi Rob,
On Mon, Oct 07, 2019 at 01:49:06PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> When games, browser, or anything using a lot of GPU buffers exits, there
> can be many hundreds or thousands of buffers to unmap and free. If the
> GPU is otherwise suspended, this can cause arm-smmu to res
On 28/10/2019 15:09, Steven Price wrote:
[...]
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -822,15 +822,13 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct
io_pgtable_cfg *cfg,
/* Ensure the empty pgd is visible before any actual TTBR wri
On Thu, Oct 17, 2019 at 08:57:03AM +0800, Boqun Feng wrote:
Currently hyperv-iommu is implemented in a x86 specific way, for
example, apic is used. So make the HYPERV_IOMMU Kconfig depend on X86
as a preparation for enabling HyperV on architecture other than x86.
Cc: Lan Tianyu
Cc: Michael Kell
On Fri, 25 Oct 2019 07:27:26 +
"Tian, Kevin" wrote:
> > From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> > Sent: Friday, October 25, 2019 3:55 AM
> >
> > When Shared Virtual Address (SVA) is enabled for a guest OS via
> > vIOMMU, we need to provide invalidation support at IOMMU API a
On Mon, 28 Oct 2019 06:06:33 +
"Tian, Kevin" wrote:
> > >>> + /* PASID based dev TLBs, only support all PASIDs or single
> > >>> PASID */
> > >>> + {1, 1, 0},
> > >>
> > >> I forgot previous discussion. is it necessary to pass down dev
> > >> TLB invalidation
> > >> requests? Can it b
On Mon, 28 Oct 2019 06:03:36 +
"Tian, Kevin" wrote:
> > > > + .sva_bind_gpasid= intel_svm_bind_gpasid,
> > > > + .sva_unbind_gpasid = intel_svm_unbind_gpasid,
> > > > +#endif
> > >
> > > again, pure PASID management logic should be separated from SVM.
> > >
> > I
On Mon, Oct 28, 2019 at 12:37:28PM +0100, Christoph Hellwig wrote:
> On Mon, Oct 28, 2019 at 11:24:58AM +, Will Deacon wrote:
> > Agreed. The way I /think/ it works is that on many SoCs there is a
> > system/last-level cache (LLC) which effectively sits in front of memory for
> > all masters. E
On Mon, Oct 28, 2019 at 11:59:04AM +, Robin Murphy wrote:
> On 28/10/2019 11:24, Will Deacon wrote:
> >Hi Christoph,
> >
> >On Mon, Oct 28, 2019 at 08:41:56AM +0100, Christoph Hellwig wrote:
> >>On Sat, Oct 26, 2019 at 03:12:57AM -0700, isa...@codeaurora.org wrote:
> >>>On 2019-10-25 22:30, Chr
On 25/10/2019 19:08, Robin Murphy wrote:
> TTBR1 values have so far been redundant since no users implement any
> support for split address spaces. Crucially, though, one of the main
> reasons for wanting to do so is to be able to manage each half entirely
> independently, e.g. context-switching on
Hi Chris,
Just a quick scan of the dmesg attached in the bugzilla.
There are 6 devices reported in ANDD.
[0.458662] DMAR: ANDD device: 1 name: \_SB.PCI0.I2C0
[0.458683] DMAR: ANDD device: 2 name: \_SB.PCI0.I2C1
[0.458704] DMAR: ANDD device: 3 name: \_SB.PCI0.SPI0
[0.458724] DMAR
On 24/10/2019 13:41, Laurentiu Tudor wrote:
From: Laurentiu Tudor
Add an implementation of the newly introduced dma map op in the
generic DMA IOMMU generic glue layer and wire it up.
Signed-off-by: Laurentiu Tudor
---
drivers/iommu/dma-iommu.c | 16
1 file changed, 16 inse
On 24/10/2019 13:41, Laurentiu Tudor wrote:
From: Laurentiu Tudor
Introduce a few new dma unmap and sync variants that, on top of the
original variants, return the virtual address corresponding to the
input dma address.
In order to implement this a new dma map op is added and used:
void *g
On Thu, Oct 24, 2019 at 12:41:41PM +, Laurentiu Tudor wrote:
> From: Laurentiu Tudor
>
> Introduce a few new dma unmap and sync variants that, on top of the
> original variants, return the virtual address corresponding to the
> input dma address.
> In order to implement this a new dma map op
On 28/10/2019 11:24, Will Deacon wrote:
Hi Christoph,
On Mon, Oct 28, 2019 at 08:41:56AM +0100, Christoph Hellwig wrote:
On Sat, Oct 26, 2019 at 03:12:57AM -0700, isa...@codeaurora.org wrote:
On 2019-10-25 22:30, Christoph Hellwig wrote:
The definition makes very little sense.
Can you please
On Mon, Oct 28, 2019 at 11:24:58AM +, Will Deacon wrote:
> Agreed. The way I /think/ it works is that on many SoCs there is a
> system/last-level cache (LLC) which effectively sits in front of memory for
> all masters. Even if a device isn't coherent with the CPU caches, we still
> want to be a
On Mon, Oct 28, 2019 at 10:55:05AM +, Laurentiu Tudor wrote:
> >> @@ -85,9 +75,10 @@ static void free_rx_fd(struct dpaa2_eth_priv *priv,
> >> sgt = vaddr + dpaa2_fd_get_offset(fd);
> >> for (i = 1; i < DPAA2_ETH_MAX_SG_ENTRIES; i++) {
> >> addr = dpaa2_sg_get_addr(&sgt[i]);
>
Hi Christoph,
On Mon, Oct 28, 2019 at 08:41:56AM +0100, Christoph Hellwig wrote:
> On Sat, Oct 26, 2019 at 03:12:57AM -0700, isa...@codeaurora.org wrote:
> > On 2019-10-25 22:30, Christoph Hellwig wrote:
> >> The definition makes very little sense.
> > Can you please clarify what part doesn’t make
Based on previous modifications in the patchset, A mtk_iommu_data
structure represent a iommu, we will add mtk_iommu_data to mtk_iommu_domain
to show the iommu which mtk_iommu_domain belongs to, so we can get
mtk_iommu_data by mtk_iommu_domain, don't use to "mtk_iommu_get_m4u_data"
any more.
Besid
For multiple iommu_domains, we need to reserve some iova
regions, so we will add mtk_iommu_resv_iova_region structure.
It includes the start address and size of iova and iommu_resv_type.
Based on the function, we will realize multiple mtk_iommu_domains
Signed-off-by: Anan Sun
Signed-off-by: Chao
1. Redefine mtk_iommu_domain structure, it will include iommu_group
and iommu_domain. Different mtk_iommu_domains can be distinguished by
ID. When we realize multiple mtk_iommu_domains, every mtk_iommu_domain
can describe one iova region.
2. In theory, every device has one iommu_group, so this patc
Add mtk_domain_data structure to describe how many iova regions
there are and the relevant the start and end address of each
iova region. The number of iova region is equal to the number
of mtk_iommu_domain. So we will use mtk_domain_data to initialize
the start and end iova of mtk_iommu_domain.
S
Based on one mtk_iommu_domain, this patch supports multiple
mtk_iommu_domains to realize different iova regions.
Every module has one smi_larb port, so we can create different
mtk_iommu_domains by smi_larb port define. So we will add port_mask
variable to mtk_domain_data, if some modules need spec
This patch will remove the usage of the m4u_dom variable.
We have already redefined mtk_iommu_domain structure and it
includes iommu_domain, so m4u_dom variable will not be used.
Signed-off-by: Chao Hao
---
drivers/iommu/mtk_iommu.c | 27 ---
1 file changed, 20 insertion
For mt6779, it needs to support three mtk_iommu_domains, every
mtk_iommu_domain's iova space is different.
Three mtk_iommu_domains is as below:
1. Normal mtk_iommu_domain exclude 0x4000_~0x47ff_ and
0x7da0_~7fbf_.
2. CCU mtk_iommu_domain include 0x4000_~0x47ff_.
3. VPU mt
Start with this patch, we will change the SW architecture
to support multiple domains. SW architecture will has a big change,
so we need to modify a little bit by more than one patch.
The new SW overall architecture is as below:
iommu0 iommu1
All the devices which used iommu are connected to SMI_larb port,
so when different devices driver execute initialization, iommu
can check larb_id and port_id to distinguish them and make
them match to iommu_group accordingly. We also add dom_cnt variable
to describe the number of mtk_iommu_domain.
We already have global mtk_iommu_pgtable structure to describe
page table and create it in group_device, "mtk_iommu_domain_finalise"
is as the same as that, so so we will remove mtk_iommu_domain_finalise.
Signed-off-by: Chao Hao
---
drivers/iommu/mtk_iommu.c | 48
This patch adds description for MT6779 IOMMU.
MT6779 has two iommus, they are MM_IOMMU and APU_IOMMU which
use ARM Short-Descriptor translation format.
The MT6779 IOMMU hardware diagram is as below, it is only a brief
diagram about iommu, it don't focus on the part of smi_larb, so
I don't describ
This patchset adds mt6779 iommu support and adjusts mtk iommu software
architecture mainly.
1. Add mt6779 basic function, such as smi larb port define, registers define
and so on.
2. In addition, this patchset will adjust current mtk iommu SW architecture
mainly to adapt all the mtk platforms:
This patch will use mtk_iommu_pgtable to replace the part
of pgtable in mtk_iommu_domain, so we can remove the information
of pgtable in mtk_iommu_domain.
Signed-off-by: Chao Hao
---
drivers/iommu/mtk_iommu.c | 37 +
1 file changed, 17 insertions(+), 20 deleti
1. Add mt6779 registers define for iommu.
2. Add mt6779_data define to support mt6779 iommu HW init.
3. There are two iommus, one is mm_iommu, the other is vpu_iommu.
MM_IOMMU is connected smi_larb to support multimedia engine to
access DRAM, and VPU_IOMMU is connected to APU_bus to support
VPU,MDL
On 10/28/19 10:55 AM, Alexandre Torgue wrote:
> Hi Vlad,
>
> On 10/24/19 5:27 PM, Vladimir Murzin wrote:
>> Hi Alex,
>>
>> On 10/24/19 4:20 PM, Alexandre Torgue wrote:
>>> Hi Vlad,
>>>
>>> On 10/24/19 2:43 PM, Vladimir Murzin wrote:
On 10/17/19 10:46 AM, Vladimir Murzin wrote:
> I'm wonde
Hi Vlad,
On 10/24/19 5:27 PM, Vladimir Murzin wrote:
Hi Alex,
On 10/24/19 4:20 PM, Alexandre Torgue wrote:
Hi Vlad,
On 10/24/19 2:43 PM, Vladimir Murzin wrote:
On 10/17/19 10:46 AM, Vladimir Murzin wrote:
I'm wondering if I've missed something with diff bellow (it was a long time ago
when
Hi Jonathan,
On 25.10.2019 19:12, Jonathan Lemon wrote:
>
>
> On 24 Oct 2019, at 5:41, Laurentiu Tudor wrote:
>
>> From: Laurentiu Tudor
>>
>> Convert this driver to usage of the newly introduced dma unmap and
>> sync DMA APIs. This will get rid of the unsupported direct usage of
>> iommu_iova
On Sat, Oct 26, 2019 at 03:12:57AM -0700, isa...@codeaurora.org wrote:
> On 2019-10-25 22:30, Christoph Hellwig wrote:
>> The definition makes very little sense.
> Can you please clarify what part doesn’t make sense, and why?
It looks like complete garbage to me. That might just be because it
use
47 matches
Mail list logo
