On 18/04/2019 14:57, Zhen Lei wrote:
First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
opportunity to set {lazy|strict} mode as default at build time. Then put
the three config options in an choice, make people can only choose one of
the three at a time.
The default IOMMU
Hi Nicolin,
modulo a trivial comment typo I found this looks fine to me. I plan
to apply it with that fixed up around -rc2 time when I open the
dma mapping tree opens for the the 5.3 merge window, unless someone
finds an issue until then.
___
iommu mail
On 08/04/2019 13:18, Eric Auger wrote:
On ARM, MSI are translated by the SMMU. An IOVA is allocated
for each MSI doorbell. If both the host and the guest are exposed
with SMMUs, we end up with 2 different IOVAs allocated by each.
guest allocates an IOVA (gIOVA) to map onto the guest MSI
doorbell
On 08/04/2019 13:18, Eric Auger wrote:
From: Jean-Philippe Brucker
When handling faults from the event or PRI queue, we need to find the
struct device associated to a SID. Add a rb_tree to keep track of SIDs.
Out of curiosity, have you looked at whether an xarray might now be a
more efficien
On 08/04/2019 13:19, Eric Auger wrote:
To allow nested stage support, we need to store both
stage 1 and stage 2 configurations (and remove the former
union).
A nested setup is characterized by both s1_cfg and s2_cfg
set.
We introduce a new ste.abort field that will be set upon
guest stage1 conf
On 08/04/2019 13:19, Eric Auger wrote:
On attach_pasid_table() we program STE S1 related info set
by the guest into the actual physical STEs. At minimum
we need to program the context descriptor GPA and compute
whether the stage1 is translated/bypassed or aborted.
Signed-off-by: Eric Auger
---
On 08/04/2019 13:19, Eric Auger wrote:
Implement domain-selective and page-selective IOTLB invalidations.
Signed-off-by: Eric Auger
---
v6 -> v7
- check the uapi version
v3 -> v4:
- adapt to changes in the uapi
- add support for leaf parameter
- do not use arm_smmu_tlb_inv_range_nosync or arm
On 08/04/2019 13:19, Eric Auger wrote:
Up to now, when the type was UNMANAGED, we used to
allocate IOVA pages within a reserved IOVA MSI range.
If both the host and the guest are exposed with SMMUs, each
would allocate an IOVA. The guest allocates an IOVA (gIOVA)
to map onto the guest MSI doorbe
On 08/04/2019 13:19, Eric Auger wrote:
When a stage 1 related fault event is read from the event queue,
let's propagate it to potential external fault listeners, ie. users
who registered a fault handler.
Signed-off-by: Eric Auger
---
v4 -> v5:
- s/IOMMU_FAULT_PERM_INST/IOMMU_FAULT_PERM_EXEC
--
On Tue, Apr 9, 2019 at 3:03 PM Christoph Hellwig wrote:
>
> Hi Muli and Jon,
>
> do you know if there are user of systems with the Calgary iommu
> around still? It seems like the last non-drive by changes to it
> are from 2010 and I'm not sure how common these systems were.
These systems were pl
On Wed, May 08, 2019 at 06:42:39PM +0100, Jon Mason wrote:
> These systems were plentiful for 2-4 years after the original series
> made it in. After that, the Intel and AMD IOMMUs should were shipped
> and were superior to this chip. So, even in systems where these might
> be present, the AMD/In
On Wed, May 8, 2019 at 6:52 PM Christoph Hellwig wrote:
>
> On Wed, May 08, 2019 at 06:42:39PM +0100, Jon Mason wrote:
> > These systems were plentiful for 2-4 years after the original series
> > made it in. After that, the Intel and AMD IOMMUs should were shipped
> > and were superior to this ch
On Wed, May 08, 2019 at 06:56:46PM +0100, Jon Mason wrote:
> I do have a system. So, it could be tested. However given the age of
> the HW, I would say it is not worth the effort to update and it would
> be best to remove it from the kernel.
>
> I can send a patch to do this, unless you would pr
On Wed, May 08, 2019 at 02:52:54PM +0200, Christoph Hellwig wrote:
> modulo a trivial comment typo I found this looks fine to me. I plan
> to apply it with that fixed up around -rc2 time when I open the
> dma mapping tree opens for the the 5.3 merge window, unless someone
> finds an issue until th
On 08/05/2019 15:05, Robin Murphy wrote:
> On 08/04/2019 13:18, Eric Auger wrote:
>> From: Jean-Philippe Brucker
>>
>> When handling faults from the event or PRI queue, we need to find the
>> struct device associated to a SID. Add a rb_tree to keep track of SIDs.
>
> Out of curiosity, have you lo
If multiple devices try to bind to the same mm/PASID, we need to
set up first level PASID entries for all the devices. The current
code does not consider this case which results in failed DMA for
devices after the first bind.
Signed-off-by: Jacob Pan
Reported-by: Mike Campin
---
drivers/iommu/i
Hi Tom,
On 5/6/19 11:32 PM, Tom Murphy wrote:
The AMD driver already solves this problem and uses the generic
iommu_request_dm_for_dev function. It seems like both drivers have the
same problem and could use the same solution. Is there any reason we
can't have use the same solution for the intel
Hi Robin,
On 5/7/19 6:28 PM, Robin Murphy wrote:
On 06/05/2019 16:32, Tom Murphy via iommu wrote:
The AMD driver already solves this problem and uses the generic
iommu_request_dm_for_dev function. It seems like both drivers have the
same problem and could use the same solution. Is there any rea
Hi,
On 5/6/19 11:25 PM, Tom Murphy wrote:
It looks like there is a bug in this code.
The behavior before this patch in __intel_map_single was that
iommu_no_mapping would call remove the attached si_domain for 32 bit
devices (in the dmar_remove_one_dev_info(dev) call in
iommu_no_mapping) and t
19 matches
Mail list logo
