From: Robin Murphy <robin.murphy@arm.com> To: Tomasz Jeznach <tjeznach@rivosinc.com> Cc: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Anup Patel <apatel@ventanamicro.com>, Sunil V L <sunilvl@ventanamicro.com>, Nick Kossifidis <mick@ics.forth.gr>, Sebastien Boeuf <seb@rivosinc.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzk+dt@kernel.org>, Conor Dooley <conor+dt@kernel.org>, devicetree@vger.kernel.org, iommu@lists.linux.dev, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux@rivosinc.com Subject: Re: [PATCH v2 2/7] iommu/riscv: Add RISC-V IOMMU platform device driver Date: Thu, 25 Apr 2024 12:23:10 +0100 [thread overview] Message-ID: <059ae516-aed4-4836-a2ca-aff150ff428d@arm.com> (raw) In-Reply-To: <CAH2o1u6FpDWNZsQCADQQKauPYzxDE73DRHHQKw6LjNb27ePeXw@mail.gmail.com> On 24/04/2024 10:59 pm, Tomasz Jeznach wrote: [...] >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index 2657f9eae84c..051599c76585 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -18972,6 +18972,12 @@ L: iommu@lists.linux.dev >>> L: linux-riscv@lists.infradead.org >>> S: Maintained >>> F: Documentation/devicetree/bindings/iommu/riscv,iommu.yaml >>> +F: drivers/iommu/riscv/Kconfig >>> +F: drivers/iommu/riscv/Makefile >>> +F: drivers/iommu/riscv/iommu-bits.h >>> +F: drivers/iommu/riscv/iommu-platform.c >>> +F: drivers/iommu/riscv/iommu.c >>> +F: drivers/iommu/riscv/iommu.h >> >> I'm pretty sure a single "F: drivers/iommu/riscv/" pattern will suffice. >> > > Correct. But will required a workaround for pretty naive MAINTAINERS update > check in scripts/checkpatch.pl:3014 in next patch. As long as what you're doing is clearly reasonable to humans, the correct workaround for any checkpatch complaint is to ignore checkpatch. [...] >>> +static int riscv_iommu_init_check(struct riscv_iommu_device *iommu) >>> +{ >>> + u64 ddtp; >>> + >>> + /* Hardware must be configured in OFF | BARE mode at system initialization. */ >>> + riscv_iommu_readq_timeout(iommu, RISCV_IOMMU_REG_DDTP, >>> + ddtp, !(ddtp & RISCV_IOMMU_DDTP_BUSY), >>> + 10, RISCV_IOMMU_DDTP_TIMEOUT); >>> + if (FIELD_GET(RISCV_IOMMU_DDTP_MODE, ddtp) > RISCV_IOMMU_DDTP_MODE_BARE) >>> + return -EBUSY; >> >> It looks like RISC-V already supports kdump, so you probably want to be >> prepared to find the IOMMU with its pants down and deal with it from day >> one. >> > > This is the simplest check/fail for the kexec and/or boot loaders > leaving IOMMU translations active. > I've been already looking into kexec path to quiesce all devices and > IOMMU in shutdown path. > I'm not convinced it's ready for the prime time on RISC-V, will > address this in follow up patches. Yeah, for regular kexec you definitely want an orderly shutdown of the IOMMU, although there's still a bit of an open question about whether it's better to actively block any remaining traffic from devices whose drivers haven't cleanly stopped them. It's in the kdump crash kernel case that you can't have any expectations and need to be able to recover the IOMMU into a usable state, since it's likely to be in the way of devices which the crash kernel wants to take over and use. Thanks, Robin.
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com> To: Tomasz Jeznach <tjeznach@rivosinc.com> Cc: Anup Patel <apatel@ventanamicro.com>, devicetree@vger.kernel.org, Conor Dooley <conor+dt@kernel.org>, Albert Ou <aou@eecs.berkeley.edu>, linux@rivosinc.com, Joerg Roedel <joro@8bytes.org>, linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>, Sebastien Boeuf <seb@rivosinc.com>, iommu@lists.linux.dev, Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, Nick Kossifidis <mick@ics.forth.gr>, Krzysztof Kozlowski <krzk+dt@kernel.org>, Will Deacon <will@kernel.org>, linux-riscv@lists.infradead.org Subject: Re: [PATCH v2 2/7] iommu/riscv: Add RISC-V IOMMU platform device driver Date: Thu, 25 Apr 2024 12:23:10 +0100 [thread overview] Message-ID: <059ae516-aed4-4836-a2ca-aff150ff428d@arm.com> (raw) In-Reply-To: <CAH2o1u6FpDWNZsQCADQQKauPYzxDE73DRHHQKw6LjNb27ePeXw@mail.gmail.com> On 24/04/2024 10:59 pm, Tomasz Jeznach wrote: [...] >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index 2657f9eae84c..051599c76585 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -18972,6 +18972,12 @@ L: iommu@lists.linux.dev >>> L: linux-riscv@lists.infradead.org >>> S: Maintained >>> F: Documentation/devicetree/bindings/iommu/riscv,iommu.yaml >>> +F: drivers/iommu/riscv/Kconfig >>> +F: drivers/iommu/riscv/Makefile >>> +F: drivers/iommu/riscv/iommu-bits.h >>> +F: drivers/iommu/riscv/iommu-platform.c >>> +F: drivers/iommu/riscv/iommu.c >>> +F: drivers/iommu/riscv/iommu.h >> >> I'm pretty sure a single "F: drivers/iommu/riscv/" pattern will suffice. >> > > Correct. But will required a workaround for pretty naive MAINTAINERS update > check in scripts/checkpatch.pl:3014 in next patch. As long as what you're doing is clearly reasonable to humans, the correct workaround for any checkpatch complaint is to ignore checkpatch. [...] >>> +static int riscv_iommu_init_check(struct riscv_iommu_device *iommu) >>> +{ >>> + u64 ddtp; >>> + >>> + /* Hardware must be configured in OFF | BARE mode at system initialization. */ >>> + riscv_iommu_readq_timeout(iommu, RISCV_IOMMU_REG_DDTP, >>> + ddtp, !(ddtp & RISCV_IOMMU_DDTP_BUSY), >>> + 10, RISCV_IOMMU_DDTP_TIMEOUT); >>> + if (FIELD_GET(RISCV_IOMMU_DDTP_MODE, ddtp) > RISCV_IOMMU_DDTP_MODE_BARE) >>> + return -EBUSY; >> >> It looks like RISC-V already supports kdump, so you probably want to be >> prepared to find the IOMMU with its pants down and deal with it from day >> one. >> > > This is the simplest check/fail for the kexec and/or boot loaders > leaving IOMMU translations active. > I've been already looking into kexec path to quiesce all devices and > IOMMU in shutdown path. > I'm not convinced it's ready for the prime time on RISC-V, will > address this in follow up patches. Yeah, for regular kexec you definitely want an orderly shutdown of the IOMMU, although there's still a bit of an open question about whether it's better to actively block any remaining traffic from devices whose drivers haven't cleanly stopped them. It's in the kdump crash kernel case that you can't have any expectations and need to be able to recover the IOMMU into a usable state, since it's likely to be in the way of devices which the crash kernel wants to take over and use. Thanks, Robin. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-04-25 11:23 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-04-18 16:32 [PATCH v2 0/7] Linux RISC-V IOMMU Support Tomasz Jeznach 2024-04-18 16:32 ` Tomasz Jeznach 2024-04-18 16:32 ` [PATCH v2 1/7] dt-bindings: iommu: riscv: Add bindings for RISC-V IOMMU Tomasz Jeznach 2024-04-18 16:32 ` Tomasz Jeznach 2024-04-18 17:04 ` Conor Dooley 2024-04-18 17:04 ` Conor Dooley 2024-04-24 22:37 ` Tomasz Jeznach 2024-04-24 22:37 ` Tomasz Jeznach 2024-04-25 17:11 ` Conor Dooley 2024-04-25 17:11 ` Conor Dooley 2024-04-22 14:04 ` Rob Herring 2024-04-22 14:04 ` Rob Herring 2024-04-18 16:32 ` [PATCH v2 2/7] iommu/riscv: Add RISC-V IOMMU platform device driver Tomasz Jeznach 2024-04-18 16:32 ` Tomasz Jeznach 2024-04-18 21:22 ` Robin Murphy 2024-04-18 21:22 ` Robin Murphy 2024-04-24 21:59 ` Tomasz Jeznach 2024-04-24 21:59 ` Tomasz Jeznach 2024-04-25 11:23 ` Robin Murphy [this message] 2024-04-25 11:23 ` Robin Murphy 2024-04-18 16:32 ` [PATCH v2 3/7] iommu/riscv: Add RISC-V IOMMU PCIe " Tomasz Jeznach 2024-04-18 16:32 ` Tomasz Jeznach 2024-04-18 22:07 ` Robin Murphy 2024-04-18 22:07 ` Robin Murphy 2024-04-18 16:32 ` [PATCH v2 4/7] iommu/riscv: Enable IOMMU registration and device probe Tomasz Jeznach 2024-04-18 16:32 ` Tomasz Jeznach 2024-04-18 16:32 ` [PATCH v2 5/7] iommu/riscv: Device directory management Tomasz Jeznach 2024-04-18 16:32 ` Tomasz Jeznach 2024-04-19 12:40 ` Jason Gunthorpe 2024-04-19 12:40 ` Jason Gunthorpe 2024-04-24 23:01 ` Tomasz Jeznach 2024-04-24 23:01 ` Tomasz Jeznach 2024-04-24 23:07 ` Jason Gunthorpe 2024-04-24 23:07 ` Jason Gunthorpe 2024-04-22 5:11 ` Baolu Lu 2024-04-22 5:11 ` Baolu Lu 2024-04-24 23:07 ` Tomasz Jeznach 2024-04-24 23:07 ` Tomasz Jeznach 2024-04-18 16:32 ` [PATCH v2 6/7] iommu/riscv: Command and fault queue support Tomasz Jeznach 2024-04-18 16:32 ` Tomasz Jeznach 2024-04-18 16:32 ` [PATCH v2 7/7] iommu/riscv: Paging domain support Tomasz Jeznach 2024-04-18 16:32 ` Tomasz Jeznach 2024-04-19 12:56 ` Jason Gunthorpe 2024-04-19 12:56 ` Jason Gunthorpe 2024-04-22 7:40 ` Baolu Lu 2024-04-22 7:40 ` Baolu Lu 2024-04-24 23:30 ` Tomasz Jeznach 2024-04-24 23:30 ` Tomasz Jeznach 2024-04-24 23:39 ` Jason Gunthorpe 2024-04-24 23:39 ` Jason Gunthorpe 2024-04-24 23:54 ` Tomasz Jeznach 2024-04-24 23:54 ` Tomasz Jeznach 2024-04-25 0:48 ` Jason Gunthorpe 2024-04-25 0:48 ` Jason Gunthorpe 2024-04-22 5:21 ` Baolu Lu 2024-04-22 5:21 ` Baolu Lu 2024-04-22 19:30 ` Jason Gunthorpe 2024-04-22 19:30 ` Jason Gunthorpe 2024-04-23 17:00 ` Andrew Jones 2024-04-23 17:00 ` Andrew Jones
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=059ae516-aed4-4836-a2ca-aff150ff428d@arm.com \ --to=robin.murphy@arm.com \ --cc=aou@eecs.berkeley.edu \ --cc=apatel@ventanamicro.com \ --cc=conor+dt@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=iommu@lists.linux.dev \ --cc=joro@8bytes.org \ --cc=krzk+dt@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=linux@rivosinc.com \ --cc=mick@ics.forth.gr \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=robh+dt@kernel.org \ --cc=seb@rivosinc.com \ --cc=sunilvl@ventanamicro.com \ --cc=tjeznach@rivosinc.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.