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
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_
; in 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
>
> 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
79,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
patches (8/10 through 10/10) tomorrow or later.
Best regards,
Yoshihiro Shimoda
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
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,
>
umber_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 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 futu
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 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
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
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-off-b
or 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
lobal 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 familiar abou
nslation), 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 is OK, I think.
Best r
xen_domain->root_domain )
> +ipmmu_free_root_domain(xen_domain->root_domain);
> +
> +spin_unlock(_domain->lock);
> +
> +/*
> + * We assume that all master devices have already been detached from
> + * this Xen domain and there must be no
18 matches
Mail list logo
