On Wed, May 01, 2024 at 06:26:20PM +0800, Baolu Lu wrote: > On 2024/5/1 4:01, Tomasz Jeznach wrote: > > +static int riscv_iommu_init_check(struct riscv_iommu_device *iommu) > > +{ > > + u64 ddtp; > > + > > + /* > > + * Make sure the IOMMU is switched off or in pass-through mode during regular > > + * boot flow and disable translation when we boot into a kexec kernel and the > > + * previous kernel left them enabled. > > + */ > > + ddtp = riscv_iommu_readq(iommu, RISCV_IOMMU_REG_DDTP); > > + if (ddtp & RISCV_IOMMU_DDTP_BUSY) > > + return -EBUSY; > > + > > + if (FIELD_GET(RISCV_IOMMU_DDTP_MODE, ddtp) > RISCV_IOMMU_DDTP_MODE_BARE) { > > + if (!is_kdump_kernel()) > > Is kdump supported for RISC-V architectures? If so, the documentation > in Documentation/admin-guide/kdump/kdump.rst might need an update. > > There is a possibility of ongoing DMAs during the boot process of the > kdump capture kernel because there's a small chance of legacy DMA setups > targeting any memory location. Kdump typically allows these ongoing DMA > transfers to complete, assuming they were intended for valid memory > regions. > > The IOMMU subsystem implements a default domain deferred attachment > mechanism for this. In the kdump capture kernel, the whole device > context tables are copied from the original kernel and will be > overridden once the device driver calls the kernel DMA interface for the > first time. This assumes that all old DMA transfers are completed after > the driver's takeover. > > Will you consider this for RISC-V architecture as well? It seems we decided not to do that mess in ARM.. New architectures doing kdump should put the iommu in a full blocking state before handing over the next kernel, and this implies that devices drivers need to cleanly suspend their DMAs before going into the next kernel. Jason