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 b/drivers/iommu/intel
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 iova
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
0x8ce
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 b/drivers/iommu/int
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 PASI
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 b/
Intel VT-d in scalable mode supports two types of page tables
for DMA translation: the first level page table and the second
level page table. The first level page table uses the same
format as the CPU page table, while the second level page table
keeps compatible with previous formats. The softwar
This adds the Intel VT-d specific callback of setting
DOMAIN_ATTR_NESTING domain attribution. It is necessary
to let the VT-d driver know that the domain represents
a virtual machine which requires the IOMMU hardware to
support nested translation mode. Return success if the
IOMMU hardware suports n
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 +++
drivers/iomm
Hi,
On 12/17/19 3:24 AM, Jacob Pan wrote:
When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable
IOTLB invalidation may be passed down from outside IOMMU subsystems.
This patch adds invalidation functions that can be used for additional
translation cache types.
Signed-off-by: Jac
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 R
> 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 wh
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 th
Hi Jean,
On 12/18/19 5:08 PM, Jean-Philippe Brucker wrote:
> 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
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 arm_smmu_write_ctx_desc(s
On Wed, Dec 18, 2019 at 11:17:55AM +0100, Auger Eric wrote:
> > +static int arm_smmu_enable_pasid(struct arm_smmu_master *master)
> > +{
> > + int ret;
> > + int features;
> > + int num_pasids;
> > + struct pci_dev *pdev;
> > +
> > + if (!dev_is_pci(master->dev))
> > + return -E
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 add
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 into
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 translation.
From: Thierry Reding
Use the new standard function instead of open-coding it.
Cc: David Woodhouse
Signed-off-by: Thierry Reding
---
drivers/iommu/intel-iommu.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iom
From: Thierry Reding
Implement a generic function for removing reserved regions. This can be
used by drivers that don't do anything fancy with these regions other
than allocating memory for them.
Signed-off-by: Thierry Reding
---
drivers/iommu/iommu.c | 19 +++
include/linux/io
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 insertions(+)
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 7a6c056b9b9c..9e
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 B
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 inser
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 domai
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.
>
> Signed
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 #ifd
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 (
33 matches
Mail list logo
