Currently if flush queue initialization fails, we return error
or enforce the system-wide strict mode. These are unnecessary
because we always check the existence of a flush queue before
queuing any iova's for lazy flushing. Printing a informational
message is enough.
Signed-off-by: Lu Baolu
---
If Intel IOMMU strict mode is enabled by users, it's unnecessary
to create the iova flush queue.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c
Intel VT-d in scalable mode supports two types of page tables for
IOVA translation: first level and second level. The IOMMU driver
can choose one from both for IOVA translation according to the use
case. This sets up the pasid entry if a domain is selected to use
the first-level page table for
Export page table internals of the domain attached to each device.
Example of such dump on a Skylake machine:
$ sudo cat /sys/kernel/debug/iommu/intel/domain_translation_struct
[ ... ]
Device :00:14.0 with pasid 0 @0x15f3d9000
IOVA_PFNPML5E PML4E
After we make all map/unmap paths support first level page table.
Let's turn it on if hardware supports scalable mode.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c
Current intel_pasid_setup_first_level() use 5-level paging for
first level translation if CPUs use 5-level paging mode too.
This makes sense for SVA usages since the page table is shared
between CPUs and IOMMUs. But it makes no sense if we only want
to use first level for IOVA translation. Add
This checks whether a domain should use the first level page
table for map/unmap and marks it in the domain structure.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c
When software has changed first-level tables, it should invalidate
the affected IOTLB and the paging-structure-caches using the PASID-
based-IOTLB Invalidate Descriptor defined in spec 6.5.2.4.
Signed-off-by: Lu Baolu
---
drivers/iommu/dmar.c| 41 +++
Please tweak the title to
"iommu/vt-d: Use generic_iommu_put_resv_regions()"
then,
Acked-by: Lu Baolu
Best regards,
baolu
On 12/18/19 9:42 PM, Thierry Reding wrote:
From: Thierry Reding
Use the new standard function instead of open-coding it.
Cc: David Woodhouse
Signed-off-by: Thierry
> On Dec 17, 2019, at 17:53, Joerg Roedel wrote:
>
> On Fri, Dec 06, 2019 at 01:57:41PM +0800, Kai-Heng Feng wrote:
>> Hi Joerg,
>>
>>> On Dec 3, 2019, at 01:00, Christoph Hellwig wrote:
>>>
>>> On Fri, Nov 29, 2019 at 10:21:54PM +0800, Kai-Heng Feng wrote:
Serious screen flickering
Hi jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> At the moment, the SMMUv3 driver implements only one stage-1 or stage-2
> page directory per device. However SMMUv3 allows more than one address
> space for some devices, by providing multiple stage-1 page directories. In
> addition to
Hi Jean,
On 12/18/19 5:07 PM, Jean-Philippe Brucker wrote:
> On Tue, Dec 17, 2019 at 05:43:59PM +0100, Auger Eric wrote:
>>> -static void arm_smmu_write_ctx_desc(struct arm_smmu_device *smmu,
>>> - struct arm_smmu_s1_cfg *cfg)
>>> +static int
On Wed, Dec 18, 2019 at 10:59:36AM +0100, Auger Eric wrote:
> > struct arm_smmu_s1_cfg {
> > - struct arm_smmu_cd_tabletable;
> > + struct arm_smmu_cd_table*tables;
> > + size_t num_tables;
> > + __le64 *l1ptr;
> you may
On Tue, Dec 17, 2019 at 06:07:26PM +0100, Auger Eric wrote:
> Hi Jean,
>
> On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
>
> s/Propate/Propagate in the commit title.
> > Now that we support substream IDs, initialize s1cdmax with the number of
> > SSID bits supported by a master and the SMMU.
On Tue, Dec 17, 2019 at 05:43:59PM +0100, Auger Eric wrote:
> > -static void arm_smmu_write_ctx_desc(struct arm_smmu_device *smmu,
> > - struct arm_smmu_s1_cfg *cfg)
> > +static int arm_smmu_write_ctx_desc(struct arm_smmu_domain *smmu_domain,
> > +
On Wed, Dec 18, 2019 at 11:17:40AM +0100, Auger Eric wrote:
> Hi Jean,
>
> On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> > For platform devices that support SubstreamID (SSID), firmware provides
> > the number of supported SSID bits. Restrict it to what the SMMU supports
> > and cache it
On Wed, Nov 20, 2019 at 02:10:16PM +0800, Lu Baolu wrote:
> The PSI (Page Selective Invalidation) bit in the capability register
> is only valid for second-level translation. Intel IOMMU supporting
> scalable mode must support page/address selective IOTLB invalidation
> for first-level
From: Thierry Reding
Use the new standard function instead of open-coding it.
Cc: Will Deacon
Cc: Robin Murphy
Acked-by: Will Deacon
Signed-off-by: Thierry Reding
---
drivers/iommu/arm-smmu-v3.c | 11 +--
drivers/iommu/arm-smmu.c| 11 +--
2 files changed, 2
From: Thierry Reding
Use the new standard function instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/iommu/amd_iommu.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index
From: Thierry Reding
Use the new standard function instead of open-coding it.
Cc: Jean-Philippe Brucker
Cc: virtualizat...@lists.linux-foundation.org
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Thierry Reding
---
drivers/iommu/virtio-iommu.c | 14 +++---
1 file changed, 3
From: Thierry Reding
Most IOMMU drivers only need to free the memory allocated for each
reserved region. Instead of open-coding the loop to do this in each
driver, extract the code into a common function that can be used by
all these drivers.
Changes in v3:
- add Reviewed-by from Jean-Philippe
On Tue, Dec 03, 2019 at 07:01:36PM -0800, Jacob Pan (Jun) wrote:
> Hi Jean,
>
> Sorry for the delay, I was out last week. Comments inline below.
>
> On Mon, 25 Nov 2019 19:02:47 +0100
> Jean-Philippe Brucker wrote:
>
> > On Fri, Nov 22, 2019 at 04:01:02PM -0800, Jacob Pan (Jun) wrote:
> > > >
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> Enable PASID for PCI devices that support it. Since the SSID tables are
> allocated by arm_smmu_attach_dev(), PASID has to be enabled early enough.
> arm_smmu_dev_feature_enable() would be too late, since by that time the
> main DMA
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> For platform devices that support SubstreamID (SSID), firmware provides
> the number of supported SSID bits. Restrict it to what the SMMU supports
> and cache it into master->ssid_bits, which will also be used for PCI
> PASID.
>
>
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> The SMMUv3 driver, which may be built without CONFIG_PCI, will soon gain
> PASID support. Partially revert commit c6e9aefbf9db ("PCI/ATS: Remove
> unused PRI and PASID stubs") to re-introduce the PASID stubs, and avoid
> adding more
Hi Jean,
On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> The SMMU can support up to 20 bits of SSID. Add a second level of page
> tables to accommodate this. Devices that support more than 1024 SSIDs now
> have a table of 1024 L1 entries (8kB), pointing to tables of 1024 context
> descriptors
26 matches
Mail list logo
