Hi Christoph,
On 10/05/2021 09:40, Christoph Hellwig wrote:
On Sat, May 08, 2021 at 12:32:37AM +0100, Julien Grall wrote:
The pointer dereferenced seems to suggest that the swiotlb hasn't been
allocated. From what I can tell, this may be because swiotlb_force is set
to SWIOTLB_NO_FORC
25261 lines long.)
--
Julien Grall
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
at it does not need to be atomic anymore.
Cheers,
--
Julien Grall
Hellwig
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
trs);
+ else
+ __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir,
attrs);
+}
+
Cheers,
--
Julien Grall
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Christoph,
On 8/16/19 2:00 PM, Christoph Hellwig wrote:
arm and arm64 can just use xen_swiotlb_dma_ops directly like x86, no
need for a pointer indirection.
Signed-off-by: Christoph Hellwig
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
u mind it mention it in the commit message?
Other than that:
Reviewed-by: Julien Grall
Signed-off-by: Christoph Hellwig
Cheers,
--
Julien Grall
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/li
Hi Christoph,
On 8/17/19 7:50 AM, Christoph Hellwig wrote:
On Fri, Aug 16, 2019 at 11:40:43PM +0100, Julien Grall wrote:
I am not sure I agree with this rename. The implementation of the helpers
are very Arm specific as this is assuming Dom0 is 1:1 mapped.
This was necessary due to the lack
ary due to the lack of IOMMU on Arm platforms back then.
But this is now a pain to get rid of it on newer platform...
Cheers,
--
Julien Grall
A recent change split iommu_dma_map_msi_msg() in two new functions. The
function was still implemented to avoid modifying all the callers at
once.
Now that all the callers have been reworked, iommu_dma_map_msi_msg() can
be removed.
Signed-off-by: Julien Grall
Reviewed-by: Robin Murphy
Reviewed
does
not have any requirement.
The GICv3 MSI driver is reworked to avoid executing preemptible code in
non-preemptible context. This can be achieved by preparing the two MSI
mappings when allocating the MSI interrupt.
Signed-off-by: Julien Grall
---
Changes in v2:
- Rework the
have any requirement.
The FreeScale SCFG MSI driver is reworked to avoid executing preemptible
code in non-preemptible context. This can be achieved by preparing the
MSI maping when allocating the MSI interrupt.
Signed-off-by: Julien Grall
---
Changes in v2:
- Rework the commit
have any requirement.
The GICv3 ITS driver is reworked to avoid executing preemptible code in
non-preemptible context. This can be achieved by preparing the MSI
mapping when allocating the MSI interrupt.
Signed-off-by: Julien Grall
Reviewed-by: Eric Auger
---
Changes in v3:
- Fix typo
have any requirement.
The GICv2m driver is reworked to avoid executing preemptible code in
non-preemptible context. This can be achieved by preparing the MSI
mapping when allocating the MSI interrupt.
Signed-off-by: Julien Grall
Reviewed-by: Eric Auger
---
Changes in v3:
- Add Eric&#
-off-by: Julien Grall
Reviewed-by: Robin Murphy
Reviewed-by: Eric Auguer
---
Changes in v3:
- Update the comment to use kerneldoc format
- Fix typoes in the comments
- More use of msi_desc_set_iommu_cookie
- Add Robin's and Eric's reviewed-by
Cha
not be required in some configuration, the field is protected
under a new config CONFIG_IRQ_MSI_IOMMU.
A pair of helpers has also been introduced to access the field.
Signed-off-by: Julien Grall
Reviewed-by: Robin Murphy
Reviewed-by: Eric Auger
---
Changes in v3:
- Add Robin'
v3 ITS. I don't have
hardware for the other interrupt controllers.
Cheers,
Julien Grall (7):
genirq/msi: Add a new field in msi_desc to store an IOMMU cookie
iommu/dma-iommu: Split iommu_dma_map_msi_msg() in two parts
irqchip/gicv2m: Don't map the MSI page in gicv2m_compose_msi_msg
On 30/04/2019 13:34, Auger Eric wrote:
Hi Julien,
Hi Eric,
Thank you for the review!
On 4/29/19 4:44 PM, Julien Grall wrote:
its_irq_compose_msi_msg() may be called from non-preemptible context.
However, on RT, iommu_dma_map_msi_msg requires to be called from a
preemptible context.
A
A recent change split iommu_dma_map_msi_msg() in two new functions. The
function was still implemented to avoid modifying all the callers at
once.
Now that all the callers have been reworked, iommu_dma_map_msi_msg() can
be removed.
Signed-off-by: Julien Grall
---
Changes in v2
have any requirement.
The FreeScale SCFG MSI driver is reworked to avoid executing preemptible
code in non-preemptible context. This can be achieved by preparing the
MSI maping when allocating the MSI interrupt.
Signed-off-by: Julien Grall
---
Changes in v2:
- Rework the commit
have any requirement.
The GICv3 ITS driver is reworked to avoid executing preemptible code in
non-preemptible context. This can be achieved by preparing the MSI
maping when allocating the MSI interrupt.
Signed-off-by: Julien Grall
---
Changes in v2:
- Rework the commit message to use
-off-by: Julien Grall
---
Changes in v2:
- Rework the commit message to use imperative mood
- Use the MSI accessor to get/set the iommu cookie
- Don't use ternary on return
- Select CONFIG_IRQ_MSI_IOMMU
- Pass an msi_desc rather than the irq n
ges in GICv2m and GICv3 ITS. I don't have
hardware for the other interrupt controllers.
Cheers,
Julien Grall (7):
genirq/msi: Add a new field in msi_desc to store an IOMMU cookie
iommu/dma-iommu: Split iommu_dma_map_msi_msg() in two parts
irqchip/gicv2m: Don't map
does
not have any requirement.
The GICv3 MSI driver is reworked to avoid executing preemptible code in
non-preemptible context. This can be achieved by preparing the two MSI
mappings when allocating the MSI interrupt.
Signed-off-by: Julien Grall
---
Changes in v2:
- Rework the
have any requirement.
The GICv2m driver is reworked to avoid executing preemptible code in
non-preemptible context. This can be achieved by preparing the MSI
mapping when allocating the MSI interrupt.
Signed-off-by: Julien Grall
---
Changes in v2:
- Rework the commit message to use
not be required in some configuration, the field is protected
under a new config CONFIG_IRQ_MSI_IOMMU.
A pair of helpers has also been introduced to access the field.
Signed-off-by: Julien Grall
---
Changes in v2:
- Update the commit message to use imperative mood
- Protect
Hi Marc,
On 23/04/2019 11:54, Marc Zyngier wrote:
On 18/04/2019 18:26, Julien Grall wrote:
On RT, the function iommu_dma_map_msi_msg may be called from
non-preemptible context. This will lead to a splat with
CONFIG_DEBUG_ATOMIC_SLEEP as the function is using spin_lock
(they can sleep on RT
Hi,
On 4/23/19 8:08 AM, Christoph Hellwig wrote:
On Thu, Apr 18, 2019 at 06:26:06PM +0100, Julien Grall wrote:
+int iommu_dma_prepare_msi(struct msi_desc *desc, phys_addr_t msi_addr)
{
+ struct device *dev = msi_desc_to_dev(desc);
struct iommu_domain *domain
On 4/23/19 11:23 AM, Marc Zyngier wrote:
Hi Julien,
Hi Marc,
On 18/04/2019 18:26, Julien Grall wrote:
When an MSI doorbell is located downstream of an IOMMU, it is required
to swizzle the physical address with an appropriately-mapped IOVA for any
device attached to one of our DMA ops domain
Hi Thomas,
On 4/18/19 8:28 PM, Thomas Gleixner wrote:
On Thu, 18 Apr 2019, Julien Grall wrote:
When an MSI doorbell is located downstream of an IOMMU, it is required
to swizzle the physical address with an appropriately-mapped IOVA for any
device attached to one of our DMA ops domain.
At the
other does
not have any requirement.
This patch reworks the GICv3 MBI driver to avoid executing preemptible
code in non-preemptible context by preparing the MSI mappings when
allocating the MSI interrupt.
Signed-off-by: Julien Grall
---
drivers/irqchip/irq-gic-v3-mbi.c | 15 +--
1
A recent patch introduced two new functions to replace
iommu_dma_map_msi_msg() to avoid executing preemptible code in
non-preemptible context.
All the existings callers are now using the two new functions, so
iommu_dma_map_msi_msg() can be removed.
Signed-off-by: Julien Grall
---
drivers/iommu
other does
not have any requirement.
This patch reworks the gicv2m driver to avoid executing preemptible code
in non-preemptible context by preparing the MSI mapping when allocating
the MSI interrupt.
Signed-off-by: Julien Grall
---
drivers/irqchip/irq-gic-v2m.c | 8 +++-
1 file changed, 7
device is behind an IOMMU.
Signed-off-by: Julien Grall
---
drivers/iommu/dma-iommu.c | 43 ---
include/linux/dma-iommu.h | 21 +
2 files changed, 53 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu
other does
not have any requirement.
This patch reworks the GICv3 ITS driver to avoid executing preemptible
code in non-preemptible context by preparing the MSI mapping when
allocating the MSI interrupt.
Signed-off-by: Julien Grall
---
drivers/irqchip/irq-gic-v3-its.c | 5 -
1 file changed, 4
other does
not have any requirement.
This patch reworks the FreeScale SCFG MSI driver to avoid executing
preemptible code in non-preemptible context by preparing the MSI mapping
when allocating the MSI interrupt.
Signed-off-by: Julien Grall
---
drivers/irqchip/irq-ls-scfg-msi.c | 7 ++-
1 file
ges in GICv2m and GICv3 ITS. I don't have
hardware for the other interrupt controllers.
Cheers,
Julien Grall (7):
genirq/msi: Add a new field in msi_desc to store an IOMMU cookie
iommu/dma-iommu: Split iommu_dma_map_msi_msg in two parts
irqchip/gicv2m: Don't map
CONFIG_IOMMU_DMA is selected.
Signed-off-by: Julien Grall
---
include/linux/msi.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 7e9b81c3b50d..d7907feef1bb 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -77,6 +77,9 @@ struct
Hi Christoph,
On 08/03/2019 15:23, Christoph Hellwig wrote:
On Tue, Mar 05, 2019 at 09:41:46AM +, Julien Grall wrote:
On Xen, dma_addr_t will always be 64-bit while the phys_addr_t will depend
on the MMU type. So we may have phys_addr_t smaller than dma_addr_t from
the kernel point of view
chine with a larger phys_addr_t
than dma_addr_t but wouldn't need to bother.
On Xen, dma_addr_t will always be 64-bit while the phys_addr_t will
depend on the MMU type. So we may have phys_addr_t smaller than
dma_addr_t from the kernel point of view.
Cheers,
--
Julien Grall
___
est. So the returned DMA address may
be 64-bit. Hence why we select DMA_ADDR_T_64BIT above.
Cheers,
--
Julien Grall
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Cheers,
--
Julien Grall
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
device. They are unable to cope with NULL (aka direct-mapping), hence
the NULL dereference crash.
Do you have any suggestion how this should be fixed?
Best regards,
--
Julien Grall
___
iommu mailing list
iommu@lists.linux-foundation.org
https
,
domain->ops = bus->iommu_ops;
domain->type = type;
+ mutex_init(&domain->reserved_mutex);
For consistency, the RB-tree reserved_binding_list should be initialized
too:
domain->reserved_binding_list = RB_ROOT;
Cheer
44 matches
Mail list logo
