t; [for the IPMMU H/W bits]
I got it. When you submit v4 patch, I'll review and send such a tag.
Best regards,
Yoshihiro Shimoda
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
main. So, all devices being pass throughed to the
> same Xen domain share the same context bank.
>
> 4. IPMMU device tracking. In Xen, all IOMMU devices are managed
> by single driver instance. So, driver uses global list to keep track
> of registered IPMMU devices.
>
> Signed-
+ * We assume that all master devices have already been detached from
> + * this Xen domain and there must be no associated Cache IPMMU domains
> + * in use.
> + */
> +ASSERT(list_empty(&xen_domain->cache_domains));
I think this should be in the spin lock held by &xen_domain->lock.
> +xfree(xen_domain);
> +dom_iommu(d)->arch.priv = NULL;
> +}
> +
> +static const struct iommu_ops ipmmu_iommu_ops =
> +{
> +.init= ipmmu_iommu_domain_init,
> +.hwdom_init = ipmmu_iommu_hwdom_init,
> +.teardown= ipmmu_iommu_domain_teardown,
> +.iotlb_flush = ipmmu_iotlb_flush,
> +.iotlb_flush_all = ipmmu_iotlb_flush_all,
> +.assign_device = ipmmu_assign_device,
> +.reassign_device = ipmmu_reassign_device,
> +.map_page= arm_iommu_map_page,
> +.unmap_page = arm_iommu_unmap_page,
> +.add_device = ipmmu_add_device,
> +};
> +
> +/* RCAR GEN3 product and cut information. */
"R-Car Gen3 SoCs" is better than "RCAR GEN3".
> +#define RCAR_PRODUCT_MASK0x7F00
> +#define RCAR_PRODUCT_H3 0x4F00
> +#define RCAR_PRODUCT_M3 0x5200
At least, I think we should be M3W, instead of M3.
# FYI, M3-W and M3-W+ are the same value.
Best regards,
Yoshihiro Shimoda
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
h to resume address
> translation), I could use a tasklet to schedule ipmmu_tlb_invalidate()
> from the irq handler then. This way we would get this serialized. What
> do you think?
I just concerned about a dead-lock issue by recursive spin locks.
So, calling ipmmu_tlb_invalidate() here
ses global list to keep track
> of registered IPMMU devices.
>
> Signed-off-by: Oleksandr Tyshchenko
> CC: Julien Grall
> CC: Yoshihiro Shimoda
About this hardware handling, this patch seems good to me. But, since
I'm not fam
different
> context bank from being set.
>
> Signed-off-by: Oleksandr Tyshchenko
>
> ---
>
> CC: Julien Grall
> CC: Stefano Stabellini
> CC: Volodymyr Babchuk
> CC: Yoshihiro Shimoda
Thank you for the patch!
Revi
ommit message:
> commit 77cf983892b2e0d40dc256b784930a9ffaad4fc8
> Author: Yoshihiro Shimoda
> Date: Wed Nov 6 11:35:45 2019 +0900
>
> iommu/ipmmu-vmsa: Remove all unused register definitions
>
> To support different registers memory mapping hardware easily
> in the future, this p
ommit message:
> commit 16d9454f5e0447f9c19cbf350b35ed377b9f64eb
> Author: Yoshihiro Shimoda
> Date: Wed Nov 6 11:35:47 2019 +0900
>
> iommu/ipmmu-vmsa: Add helper functions for MMU "context" registers
>
> Since we will have changed memory mapping of the IPMMU in the futu
ommit message:
> commit 3667c9978b2911dc1ded77f5971df477885409c4
> Author: Yoshihiro Shimoda
> Date: Wed Nov 6 11:35:49 2019 +0900
>
> iommu/ipmmu-vmsa: Add helper functions for "uTLB" registers
>
> Since we will have changed memory mapping of the IPMMU in the future,
&g
ds (number_of_contexts and
> num_utlbs) for now, the subsequent patches will add remaining bits.
>
> No change in behavior.
>
> Signed-off-by: Oleksandr Tyshchenko
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
ommit message:
> commit 3dc28d9f59eaae41461542b27afe70339347ebb3
> Author: Yoshihiro Shimoda
> Date: Wed Nov 6 11:35:48 2019 +0900
>
> iommu/ipmmu-vmsa: Calculate context registers' offset instead of a macro
>
> Since we will have changed memory mapping of the IPMMU in the future,
ommit message:
> commit 1289f7f15001c7ed36be6d23cb145c1d5feacdc8
> Author: Yoshihiro Shimoda
> Date: Wed Nov 6 11:35:50 2019 +0900
>
> iommu/ipmmu-vmsa: Add utlb_offset_base
>
> Since we will have changed memory mapping of the IPMMU in the future,
> this patch adds a utlb_offse
l review further patches (8/10 through 10/10) tomorrow or later.
Best regards,
Yoshihiro Shimoda
000) somehow.
> @@ -979,6 +982,10 @@ static int ipmmu_probe(struct dt_device_node *node)
> set_bit(0, mmu->ctx);
> }
>
> +/* Do not use security group function. */
> +reg = IMSCTLR + mmu->features->ctx_offset_stride_adj;
> +ipmmu_write(mmu, reg, ipmmu_read(mmu, reg) & ~IMSCTLR_USE_SECGRP);
If we modify the 07/10 patch, we cannot use ctx_offset_stride_adj.
# But, using "ctx_offset" here seems to be abused though because
# the register is not context.
Best regards,
Yoshihiro Shimoda
}
>
> return 0;
> }
> @@ -494,7 +494,8 @@ static void ipmmu_utlb_disable(struct ipmmu_vmsa_domain
> *domain,
> {
> struct ipmmu_vmsa_device *mmu = domain->mmu;
>
> -ipmmu_imuctr_write(mmu, utlb, 0);
As Volodymyr-san mentioned before, after we added ASSERT(),
Reviewed-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
n order to get rid of code duplication.
>
> Signed-off-by: Oleksandr Tyshchenko
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
ommit message:
> commit 7a62ced8ebd0e1b692c9dc4781a8d4ddb0f74792
> Author: Yoshihiro Shimoda
> Date: Tue Sep 7 17:30:20 2021 +0900
>
> iommu/ipmmu-vmsa: Add support for r8a779a0
>
> Add support for r8a779a0 (R-Car V3U). The IPMMU hardware design
> of this SoC differs than others. So, add a new ipmmu_
lize the context,
> instead perform the clearing at once during initialization. Also do not
> abuse ctx_offset_stride_adj field for the register's offset calculation,
> instead use recently added control_offset_base field.
>
> Signed-off-by: Oleksandr Tyshchenko
> Reviewed-by: Volodymyr Babchuk
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
18 matches
Mail list logo
