| Message ID | 20220726200739.30017-2-semen.protsenko@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | iommu/exynos: Add fault handling on SysMMU v7 | expand |
Hi Sam, On 26.07.2022 22:07, Sam Protsenko wrote: > Fault info obtaining is implemented for SysMMU v1..v5 in a very hardware > specific way, as it relies on: > - interrupt bits being tied to read or write access > - having separate registers for the fault address w.r.t. AR/AW ops > > Newer SysMMU versions (like SysMMU v7) have different way of providing > the fault info via registers: > - the transaction type (read or write) should be read from the > register (instead of hard-coding it w.r.t. corresponding interrupt > status bit) > - there is only one single register for storing the fault address > > Because of that, it is not possible to add newer SysMMU support into > existing paradigm. Also it's not very effective performance-wise: > - checking SysMMU version in ISR each time is not necessary > - performing linear search to find the fault info by interrupt bit can > be replaced with a single lookup operation > > Pave the way for adding support for new SysMMU versions by abstracting > the getting of fault info in ISR. While at it, do some related style > cleanups as well. > > This is mostly a refactoring patch, but there are some minor functional > changes: > - fault message format is a bit different; now instead of AR/AW > prefixes for the fault's name, the request direction is printed as > [READ]/[WRITE]. It has to be done to prepare an abstraction for > SysMMU v7 support > - don't panic on unknown interrupts; print corresponding message and > continue > - if fault wasn't recovered, panic with some sane message instead of > just doing BUG_ON() > > The whole fault message looks like this now: > > [READ] PAGE FAULT occurred at 0x12341000 > > Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> I'm not very happy with converting the sysmmu_fault_info arrays into the decoding functions. If I got the code right, adding v7 is still possible with the current approach. The main advantage of the array-based approach is readability and keeping all the information together in a single place. I agree for the items listed above as 'minor functional changes', though. Those sysmmu_fault_info arrays might be a part of sysmmu hw variant to avoid decoding hw version for each fault. I'm not sure that the linear scan is so problematic with regards to the performance. You really don't want your drivers to trigger IOMMU fault so often during normal operation. It is just a way to get some debugging information or handle some exception. You mentioned that the transaction type is read from the separate register in case of v7, but your code (here and in second patch) still relies on the reported interrupt bits. Could you try to rework all your changes in a such way, that the sysmmu_fault_info arrays are still used? V7 is really very similar to the v5 already supported by the current driver. > --- > drivers/iommu/exynos-iommu.c | 162 +++++++++++++++++++++-------------- > 1 file changed, 100 insertions(+), 62 deletions(-) > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c > index 8e18984a0c4f..766d409e084a 100644 > --- a/drivers/iommu/exynos-iommu.c > +++ b/drivers/iommu/exynos-iommu.c > @@ -185,38 +185,36 @@ static sysmmu_pte_t *page_entry(sysmmu_pte_t *sent, sysmmu_iova_t iova) > lv2table_base(sent)) + lv2ent_offset(iova); > } > > -/* > - * IOMMU fault information register > - */ > -struct sysmmu_fault_info { > - unsigned int bit; /* bit number in STATUS register */ > - unsigned short addr_reg; /* register to read VA fault address */ > +struct sysmmu_fault { > + sysmmu_iova_t addr; /* IOVA address that caused fault */ > + const char *name; /* human readable fault name */ > + unsigned int type; /* fault type for report_iommu_fault() */ > +}; > + > +struct sysmmu_v1_fault_info { > + unsigned short addr_reg; /* register to read IOVA fault address */ > const char *name; /* human readable fault name */ > unsigned int type; /* fault type for report_iommu_fault */ > }; > > -static const struct sysmmu_fault_info sysmmu_faults[] = { > - { 0, REG_PAGE_FAULT_ADDR, "PAGE", IOMMU_FAULT_READ }, > - { 1, REG_AR_FAULT_ADDR, "AR MULTI-HIT", IOMMU_FAULT_READ }, > - { 2, REG_AW_FAULT_ADDR, "AW MULTI-HIT", IOMMU_FAULT_WRITE }, > - { 3, REG_DEFAULT_SLAVE_ADDR, "BUS ERROR", IOMMU_FAULT_READ }, > - { 4, REG_AR_FAULT_ADDR, "AR SECURITY PROTECTION", IOMMU_FAULT_READ }, > - { 5, REG_AR_FAULT_ADDR, "AR ACCESS PROTECTION", IOMMU_FAULT_READ }, > - { 6, REG_AW_FAULT_ADDR, "AW SECURITY PROTECTION", IOMMU_FAULT_WRITE }, > - { 7, REG_AW_FAULT_ADDR, "AW ACCESS PROTECTION", IOMMU_FAULT_WRITE }, > +static const struct sysmmu_v1_fault_info sysmmu_v1_faults[] = { > + { REG_PAGE_FAULT_ADDR, "PAGE", IOMMU_FAULT_READ }, > + { REG_AR_FAULT_ADDR, "MULTI-HIT", IOMMU_FAULT_READ }, > + { REG_AW_FAULT_ADDR, "MULTI-HIT", IOMMU_FAULT_WRITE }, > + { REG_DEFAULT_SLAVE_ADDR, "BUS ERROR", IOMMU_FAULT_READ }, > + { REG_AR_FAULT_ADDR, "SECURITY PROTECTION", IOMMU_FAULT_READ }, > + { REG_AR_FAULT_ADDR, "ACCESS PROTECTION", IOMMU_FAULT_READ }, > + { REG_AW_FAULT_ADDR, "SECURITY PROTECTION", IOMMU_FAULT_WRITE }, > + { REG_AW_FAULT_ADDR, "ACCESS PROTECTION", IOMMU_FAULT_WRITE }, > }; > > -static const struct sysmmu_fault_info sysmmu_v5_faults[] = { > - { 0, REG_V5_FAULT_AR_VA, "AR PTW", IOMMU_FAULT_READ }, > - { 1, REG_V5_FAULT_AR_VA, "AR PAGE", IOMMU_FAULT_READ }, > - { 2, REG_V5_FAULT_AR_VA, "AR MULTI-HIT", IOMMU_FAULT_READ }, > - { 3, REG_V5_FAULT_AR_VA, "AR ACCESS PROTECTION", IOMMU_FAULT_READ }, > - { 4, REG_V5_FAULT_AR_VA, "AR SECURITY PROTECTION", IOMMU_FAULT_READ }, > - { 16, REG_V5_FAULT_AW_VA, "AW PTW", IOMMU_FAULT_WRITE }, > - { 17, REG_V5_FAULT_AW_VA, "AW PAGE", IOMMU_FAULT_WRITE }, > - { 18, REG_V5_FAULT_AW_VA, "AW MULTI-HIT", IOMMU_FAULT_WRITE }, > - { 19, REG_V5_FAULT_AW_VA, "AW ACCESS PROTECTION", IOMMU_FAULT_WRITE }, > - { 20, REG_V5_FAULT_AW_VA, "AW SECURITY PROTECTION", IOMMU_FAULT_WRITE }, > +/* SysMMU v5 has the same faults for AR (0..4 bits) and AW (16..20 bits) */ > +static const char * const sysmmu_v5_fault_names[] = { > + "PTW", > + "PAGE", > + "MULTI-HIT", > + "ACCESS PROTECTION", > + "SECURITY PROTECTION" > }; > > /* > @@ -246,9 +244,12 @@ struct exynos_iommu_domain { > struct iommu_domain domain; /* generic domain data structure */ > }; > > +struct sysmmu_drvdata; > + > /* > * SysMMU version specific data. Contains offsets for the registers which can > * be found in different SysMMU variants, but have different offset values. > + * Also contains version specific callbacks to abstract the hardware. > */ > struct sysmmu_variant { > u32 pt_base; /* page table base address (physical) */ > @@ -259,6 +260,9 @@ struct sysmmu_variant { > u32 flush_end; /* end address of range invalidation */ > u32 int_status; /* interrupt status information */ > u32 int_clear; /* clear the interrupt */ > + > + int (*get_fault_info)(struct sysmmu_drvdata *data, unsigned int itype, > + struct sysmmu_fault *fault); > }; > > /* > @@ -293,6 +297,46 @@ struct sysmmu_drvdata { > > #define SYSMMU_REG(data, reg) ((data)->sfrbase + (data)->variant->reg) > > +static int exynos_sysmmu_v1_get_fault_info(struct sysmmu_drvdata *data, > + unsigned int itype, > + struct sysmmu_fault *fault) > +{ > + const struct sysmmu_v1_fault_info *finfo; > + > + if (itype >= ARRAY_SIZE(sysmmu_v1_faults)) > + return -ENXIO; > + > + finfo = &sysmmu_v1_faults[itype]; > + fault->addr = readl(data->sfrbase + finfo->addr_reg); > + fault->name = finfo->name; > + fault->type = finfo->type; > + > + return 0; > +} > + > +static int exynos_sysmmu_v5_get_fault_info(struct sysmmu_drvdata *data, > + unsigned int itype, > + struct sysmmu_fault *fault) > +{ > + unsigned int addr_reg; > + > + if (itype < ARRAY_SIZE(sysmmu_v5_fault_names)) { > + fault->type = IOMMU_FAULT_READ; > + addr_reg = REG_V5_FAULT_AR_VA; > + } else if (itype >= 16 && itype <= 20) { > + fault->type = IOMMU_FAULT_WRITE; > + addr_reg = REG_V5_FAULT_AW_VA; > + itype -= 16; > + } else { > + return -ENXIO; > + } > + > + fault->name = sysmmu_v5_fault_names[itype]; > + fault->addr = readl(data->sfrbase + addr_reg); > + > + return 0; > +} > + > /* SysMMU v1..v3 */ > static const struct sysmmu_variant sysmmu_v1_variant = { > .flush_all = 0x0c, > @@ -300,6 +344,8 @@ static const struct sysmmu_variant sysmmu_v1_variant = { > .pt_base = 0x14, > .int_status = 0x18, > .int_clear = 0x1c, > + > + .get_fault_info = exynos_sysmmu_v1_get_fault_info, > }; > > /* SysMMU v5 and v7 (non-VM capable) */ > @@ -312,6 +358,8 @@ static const struct sysmmu_variant sysmmu_v5_variant = { > .flush_end = 0x24, > .int_status = 0x60, > .int_clear = 0x64, > + > + .get_fault_info = exynos_sysmmu_v5_get_fault_info, > }; > > /* SysMMU v7: VM capable register set */ > @@ -324,6 +372,8 @@ static const struct sysmmu_variant sysmmu_v7_vm_variant = { > .flush_end = 0x8024, > .int_status = 0x60, > .int_clear = 0x64, > + > + .get_fault_info = exynos_sysmmu_v5_get_fault_info, > }; > > static struct exynos_iommu_domain *to_exynos_domain(struct iommu_domain *dom) > @@ -453,68 +503,56 @@ static void __sysmmu_get_version(struct sysmmu_drvdata *data) > } > > static void show_fault_information(struct sysmmu_drvdata *data, > - const struct sysmmu_fault_info *finfo, > - sysmmu_iova_t fault_addr) > + const struct sysmmu_fault *fault) > { > sysmmu_pte_t *ent; > > - dev_err(data->sysmmu, "%s: %s FAULT occurred at %#x\n", > - dev_name(data->master), finfo->name, fault_addr); > + dev_err(data->sysmmu, "%s: [%s] %s FAULT occurred at %#x\n", > + dev_name(data->master), > + fault->type == IOMMU_FAULT_READ ? "READ" : "WRITE", > + fault->name, fault->addr); > dev_dbg(data->sysmmu, "Page table base: %pa\n", &data->pgtable); > - ent = section_entry(phys_to_virt(data->pgtable), fault_addr); > + ent = section_entry(phys_to_virt(data->pgtable), fault->addr); > dev_dbg(data->sysmmu, "\tLv1 entry: %#x\n", *ent); > if (lv1ent_page(ent)) { > - ent = page_entry(ent, fault_addr); > + ent = page_entry(ent, fault->addr); > dev_dbg(data->sysmmu, "\t Lv2 entry: %#x\n", *ent); > } > } > > static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id) > { > - /* SYSMMU is in blocked state when interrupt occurred. */ > struct sysmmu_drvdata *data = dev_id; > - const struct sysmmu_fault_info *finfo; > - unsigned int i, n, itype; > - sysmmu_iova_t fault_addr; > + unsigned int itype; > + struct sysmmu_fault fault; > int ret = -ENOSYS; > > WARN_ON(!data->active); > > - if (MMU_MAJ_VER(data->version) < 5) { > - finfo = sysmmu_faults; > - n = ARRAY_SIZE(sysmmu_faults); > - } else { > - finfo = sysmmu_v5_faults; > - n = ARRAY_SIZE(sysmmu_v5_faults); > - } > - > spin_lock(&data->lock); > - > clk_enable(data->clk_master); > > itype = __ffs(readl(SYSMMU_REG(data, int_status))); > - for (i = 0; i < n; i++, finfo++) > - if (finfo->bit == itype) > - break; > - /* unknown/unsupported fault */ > - BUG_ON(i == n); > - > - /* print debug message */ > - fault_addr = readl(data->sfrbase + finfo->addr_reg); > - show_fault_information(data, finfo, fault_addr); > - > - if (data->domain) > - ret = report_iommu_fault(&data->domain->domain, > - data->master, fault_addr, finfo->type); > - /* fault is not recovered by fault handler */ > - BUG_ON(ret != 0); > + ret = data->variant->get_fault_info(data, itype, &fault); > + if (ret) { > + dev_err(data->sysmmu, "Unhandled interrupt bit %u\n", itype); > + goto out; > + } > + show_fault_information(data, &fault); > > + if (data->domain) { > + ret = report_iommu_fault(&data->domain->domain, data->master, > + fault.addr, fault.type); > + } > + if (ret) > + panic("Unrecoverable System MMU Fault!"); > + > +out: > writel(1 << itype, SYSMMU_REG(data, int_clear)); > > + /* SysMMU is in blocked state when interrupt occurred */ > sysmmu_unblock(data); > - > clk_disable(data->clk_master); > - > spin_unlock(&data->lock); > > return IRQ_HANDLED; Best regards
Hi Marek, On Fri, 12 Aug 2022 at 14:25, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > Hi Sam, > [snip] > > Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> > > I'm not very happy with converting the sysmmu_fault_info arrays into the > decoding functions. If I got the code right, adding v7 is still possible > with the current approach. The main advantage of the array-based > approach is readability and keeping all the information together in a > single place. > > I agree for the items listed above as 'minor functional changes', > though. Those sysmmu_fault_info arrays might be a part of sysmmu hw > variant to avoid decoding hw version for each fault. > > I'm not sure that the linear scan is so problematic with regards to the > performance. You really don't want your drivers to trigger IOMMU fault > so often during normal operation. It is just a way to get some debugging > information or handle some exception. > > You mentioned that the transaction type is read from the separate > register in case of v7, but your code (here and in second patch) still > relies on the reported interrupt bits. > > Could you try to rework all your changes in a such way, that the > sysmmu_fault_info arrays are still used? V7 is really very similar to > the v5 already supported by the current driver. > That's actually how I implemented this patch on my first attempt. Really didn't like it, because a half of existing sysmmu_fault_info structure doesn't make sense for v7, and some functionality of v7 has to be implemented separately from that structure. I'd argue that previous abstraction is just broken, and doesn't work for all SysMMU versions anymore. It's easy to see how much difference between v5 and v7, just by looking at corresponding get_fault_info() functions I implemented. For example, the transaction type is probed from different registers using different version, etc. There is also the need to handle new VM/non-VM registers on v7. Also there is some extra functionality that will be added later, like multiple translation domains support, which is also quite different from how things done for v5. I'd show more specifics to demonstrate my statements above, but alas I already deleted my initial implementation (which was exactly what you suggest). This callback-style HAL seems to be a perfect choice, and I spent several days just experimenting with different approaches and seeing all pros and cons. And from my point of view, this way is the best for providing actual solid abstraction, which doesn't require adding any workarounds on top of that. I understand that my patch changes the very conception of how IRQ is handled in this driver, but I'm still convinced it's a proper way to do that for all v1/v5/v7, especially w.r.t. further v7 additions, to keep the abstraction solid. Not that I'm lazy and don't want to rework things :) But in this particular case I'd go with unchanged patches. Do you think it's reasonable to take this series as is? I can try and collect more particular code snippets to demonstrate my point, if you like. Thanks! [snip]
Hi Marek, On Mon, 24 Oct 2022 at 09:43, Sam Protsenko <semen.protsenko@linaro.org> wrote: > > Hi Marek, > > On Fri, 12 Aug 2022 at 14:25, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > > > Hi Sam, > > > > [snip] > > > > Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> > > > > I'm not very happy with converting the sysmmu_fault_info arrays into the > > decoding functions. If I got the code right, adding v7 is still possible > > with the current approach. The main advantage of the array-based > > approach is readability and keeping all the information together in a > > single place. > > > > I agree for the items listed above as 'minor functional changes', > > though. Those sysmmu_fault_info arrays might be a part of sysmmu hw > > variant to avoid decoding hw version for each fault. > > > > I'm not sure that the linear scan is so problematic with regards to the > > performance. You really don't want your drivers to trigger IOMMU fault > > so often during normal operation. It is just a way to get some debugging > > information or handle some exception. > > > > You mentioned that the transaction type is read from the separate > > register in case of v7, but your code (here and in second patch) still > > relies on the reported interrupt bits. > > > > Could you try to rework all your changes in a such way, that the > > sysmmu_fault_info arrays are still used? V7 is really very similar to > > the v5 already supported by the current driver. > > > > That's actually how I implemented this patch on my first attempt. > Really didn't like it, because a half of existing sysmmu_fault_info > structure doesn't make sense for v7, and some functionality of v7 has > to be implemented separately from that structure. I'd argue that > previous abstraction is just broken, and doesn't work for all SysMMU > versions anymore. It's easy to see how much difference between v5 and > v7, just by looking at corresponding get_fault_info() functions I > implemented. For example, the transaction type is probed from > different registers using different version, etc. There is also the > need to handle new VM/non-VM registers on v7. Also there is some extra > functionality that will be added later, like multiple translation > domains support, which is also quite different from how things done > for v5. > > I'd show more specifics to demonstrate my statements above, but alas I > already deleted my initial implementation (which was exactly what you > suggest). This callback-style HAL seems to be a perfect choice, and I > spent several days just experimenting with different approaches and > seeing all pros and cons. And from my point of view, this way is the > best for providing actual solid abstraction, which doesn't require > adding any workarounds on top of that. I understand that my patch > changes the very conception of how IRQ is handled in this driver, but > I'm still convinced it's a proper way to do that for all v1/v5/v7, > especially w.r.t. further v7 additions, to keep the abstraction solid. > Not that I'm lazy and don't want to rework things :) But in this > particular case I'd go with unchanged patches. > > Do you think it's reasonable to take this series as is? I can try and > collect more particular code snippets to demonstrate my point, if you > like. > > Thanks! > So, what do you think about this? > [snip]
On 21.12.2022 22:32, Sam Protsenko wrote: > Hi Marek, > > On Mon, 24 Oct 2022 at 09:43, Sam Protsenko <semen.protsenko@linaro.org> wrote: >> Hi Marek, >> >> On Fri, 12 Aug 2022 at 14:25, Marek Szyprowski <m.szyprowski@samsung.com> wrote: >>> Hi Sam, >> [snip] >> >>>> Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> >>> I'm not very happy with converting the sysmmu_fault_info arrays into the >>> decoding functions. If I got the code right, adding v7 is still possible >>> with the current approach. The main advantage of the array-based >>> approach is readability and keeping all the information together in a >>> single place. >>> >>> I agree for the items listed above as 'minor functional changes', >>> though. Those sysmmu_fault_info arrays might be a part of sysmmu hw >>> variant to avoid decoding hw version for each fault. >>> >>> I'm not sure that the linear scan is so problematic with regards to the >>> performance. You really don't want your drivers to trigger IOMMU fault >>> so often during normal operation. It is just a way to get some debugging >>> information or handle some exception. >>> >>> You mentioned that the transaction type is read from the separate >>> register in case of v7, but your code (here and in second patch) still >>> relies on the reported interrupt bits. >>> >>> Could you try to rework all your changes in a such way, that the >>> sysmmu_fault_info arrays are still used? V7 is really very similar to >>> the v5 already supported by the current driver. >>> >> That's actually how I implemented this patch on my first attempt. >> Really didn't like it, because a half of existing sysmmu_fault_info >> structure doesn't make sense for v7, and some functionality of v7 has >> to be implemented separately from that structure. I'd argue that >> previous abstraction is just broken, and doesn't work for all SysMMU >> versions anymore. It's easy to see how much difference between v5 and >> v7, just by looking at corresponding get_fault_info() functions I >> implemented. For example, the transaction type is probed from >> different registers using different version, etc. There is also the >> need to handle new VM/non-VM registers on v7. Also there is some extra >> functionality that will be added later, like multiple translation >> domains support, which is also quite different from how things done >> for v5. >> >> I'd show more specifics to demonstrate my statements above, but alas I >> already deleted my initial implementation (which was exactly what you >> suggest). This callback-style HAL seems to be a perfect choice, and I >> spent several days just experimenting with different approaches and >> seeing all pros and cons. And from my point of view, this way is the >> best for providing actual solid abstraction, which doesn't require >> adding any workarounds on top of that. I understand that my patch >> changes the very conception of how IRQ is handled in this driver, but >> I'm still convinced it's a proper way to do that for all v1/v5/v7, >> especially w.r.t. further v7 additions, to keep the abstraction solid. >> Not that I'm lazy and don't want to rework things :) But in this >> particular case I'd go with unchanged patches. >> >> Do you think it's reasonable to take this series as is? I can try and >> collect more particular code snippets to demonstrate my point, if you >> like. >> >> Thanks! > So, what do you think about this? Okay, go ahead with your approach. If I find a better way, I will rework it then. I would just like to have the code for fault handling for hw v1, v5 and v7 similar as much as possible. Best regards
On Thu, 22 Dec 2022 at 07:20, Marek Szyprowski <m.szyprowski@samsung.com> wrote: [snip] > > So, what do you think about this? > > Okay, go ahead with your approach. If I find a better way, I will rework > it then. I would just like to have the code for fault handling for hw > v1, v5 and v7 similar as much as possible. > Thanks, Marek! Joerg, can you please apply this series? Please let me know if I need to rebase it first, but I guess there shouldn't be any issues, the SysMMU driver doesn't seem to get updated often. > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland >
On 22.12.2022 16:23, Sam Protsenko wrote: > On Thu, 22 Dec 2022 at 07:20, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > [snip] > >>> So, what do you think about this? >> Okay, go ahead with your approach. If I find a better way, I will rework >> it then. I would just like to have the code for fault handling for hw >> v1, v5 and v7 similar as much as possible. >> > Thanks, Marek! > > Joerg, can you please apply this series? Please let me know if I need > to rebase it first, but I guess there shouldn't be any issues, the > SysMMU driver doesn't seem to get updated often. Just to makes things a bit more formal - feel free to add: Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Best regards
Hi Joerg, On Thu, 22 Dec 2022 at 09:34, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > On 22.12.2022 16:23, Sam Protsenko wrote: > > On Thu, 22 Dec 2022 at 07:20, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > > > [snip] > > > >>> So, what do you think about this? > >> Okay, go ahead with your approach. If I find a better way, I will rework > >> it then. I would just like to have the code for fault handling for hw > >> v1, v5 and v7 similar as much as possible. > >> > > Thanks, Marek! > > > > Joerg, can you please apply this series? Please let me know if I need > > to rebase it first, but I guess there shouldn't be any issues, the > > SysMMU driver doesn't seem to get updated often. > > Just to makes things a bit more formal - feel free to add: > > Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> > Can you please apply this series? Thanks! > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland >
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c index 8e18984a0c4f..766d409e084a 100644 --- a/drivers/iommu/exynos-iommu.c +++ b/drivers/iommu/exynos-iommu.c @@ -185,38 +185,36 @@ static sysmmu_pte_t *page_entry(sysmmu_pte_t *sent, sysmmu_iova_t iova) lv2table_base(sent)) + lv2ent_offset(iova); } -/* - * IOMMU fault information register - */ -struct sysmmu_fault_info { - unsigned int bit; /* bit number in STATUS register */ - unsigned short addr_reg; /* register to read VA fault address */ +struct sysmmu_fault { + sysmmu_iova_t addr; /* IOVA address that caused fault */ + const char *name; /* human readable fault name */ + unsigned int type; /* fault type for report_iommu_fault() */ +}; + +struct sysmmu_v1_fault_info { + unsigned short addr_reg; /* register to read IOVA fault address */ const char *name; /* human readable fault name */ unsigned int type; /* fault type for report_iommu_fault */ }; -static const struct sysmmu_fault_info sysmmu_faults[] = { - { 0, REG_PAGE_FAULT_ADDR, "PAGE", IOMMU_FAULT_READ }, - { 1, REG_AR_FAULT_ADDR, "AR MULTI-HIT", IOMMU_FAULT_READ }, - { 2, REG_AW_FAULT_ADDR, "AW MULTI-HIT", IOMMU_FAULT_WRITE }, - { 3, REG_DEFAULT_SLAVE_ADDR, "BUS ERROR", IOMMU_FAULT_READ }, - { 4, REG_AR_FAULT_ADDR, "AR SECURITY PROTECTION", IOMMU_FAULT_READ }, - { 5, REG_AR_FAULT_ADDR, "AR ACCESS PROTECTION", IOMMU_FAULT_READ }, - { 6, REG_AW_FAULT_ADDR, "AW SECURITY PROTECTION", IOMMU_FAULT_WRITE }, - { 7, REG_AW_FAULT_ADDR, "AW ACCESS PROTECTION", IOMMU_FAULT_WRITE }, +static const struct sysmmu_v1_fault_info sysmmu_v1_faults[] = { + { REG_PAGE_FAULT_ADDR, "PAGE", IOMMU_FAULT_READ }, + { REG_AR_FAULT_ADDR, "MULTI-HIT", IOMMU_FAULT_READ }, + { REG_AW_FAULT_ADDR, "MULTI-HIT", IOMMU_FAULT_WRITE }, + { REG_DEFAULT_SLAVE_ADDR, "BUS ERROR", IOMMU_FAULT_READ }, + { REG_AR_FAULT_ADDR, "SECURITY PROTECTION", IOMMU_FAULT_READ }, + { REG_AR_FAULT_ADDR, "ACCESS PROTECTION", IOMMU_FAULT_READ }, + { REG_AW_FAULT_ADDR, "SECURITY PROTECTION", IOMMU_FAULT_WRITE }, + { REG_AW_FAULT_ADDR, "ACCESS PROTECTION", IOMMU_FAULT_WRITE }, }; -static const struct sysmmu_fault_info sysmmu_v5_faults[] = { - { 0, REG_V5_FAULT_AR_VA, "AR PTW", IOMMU_FAULT_READ }, - { 1, REG_V5_FAULT_AR_VA, "AR PAGE", IOMMU_FAULT_READ }, - { 2, REG_V5_FAULT_AR_VA, "AR MULTI-HIT", IOMMU_FAULT_READ }, - { 3, REG_V5_FAULT_AR_VA, "AR ACCESS PROTECTION", IOMMU_FAULT_READ }, - { 4, REG_V5_FAULT_AR_VA, "AR SECURITY PROTECTION", IOMMU_FAULT_READ }, - { 16, REG_V5_FAULT_AW_VA, "AW PTW", IOMMU_FAULT_WRITE }, - { 17, REG_V5_FAULT_AW_VA, "AW PAGE", IOMMU_FAULT_WRITE }, - { 18, REG_V5_FAULT_AW_VA, "AW MULTI-HIT", IOMMU_FAULT_WRITE }, - { 19, REG_V5_FAULT_AW_VA, "AW ACCESS PROTECTION", IOMMU_FAULT_WRITE }, - { 20, REG_V5_FAULT_AW_VA, "AW SECURITY PROTECTION", IOMMU_FAULT_WRITE }, +/* SysMMU v5 has the same faults for AR (0..4 bits) and AW (16..20 bits) */ +static const char * const sysmmu_v5_fault_names[] = { + "PTW", + "PAGE", + "MULTI-HIT", + "ACCESS PROTECTION", + "SECURITY PROTECTION" }; /* @@ -246,9 +244,12 @@ struct exynos_iommu_domain { struct iommu_domain domain; /* generic domain data structure */ }; +struct sysmmu_drvdata; + /* * SysMMU version specific data. Contains offsets for the registers which can * be found in different SysMMU variants, but have different offset values. + * Also contains version specific callbacks to abstract the hardware. */ struct sysmmu_variant { u32 pt_base; /* page table base address (physical) */ @@ -259,6 +260,9 @@ struct sysmmu_variant { u32 flush_end; /* end address of range invalidation */ u32 int_status; /* interrupt status information */ u32 int_clear; /* clear the interrupt */ + + int (*get_fault_info)(struct sysmmu_drvdata *data, unsigned int itype, + struct sysmmu_fault *fault); }; /* @@ -293,6 +297,46 @@ struct sysmmu_drvdata { #define SYSMMU_REG(data, reg) ((data)->sfrbase + (data)->variant->reg) +static int exynos_sysmmu_v1_get_fault_info(struct sysmmu_drvdata *data, + unsigned int itype, + struct sysmmu_fault *fault) +{ + const struct sysmmu_v1_fault_info *finfo; + + if (itype >= ARRAY_SIZE(sysmmu_v1_faults)) + return -ENXIO; + + finfo = &sysmmu_v1_faults[itype]; + fault->addr = readl(data->sfrbase + finfo->addr_reg); + fault->name = finfo->name; + fault->type = finfo->type; + + return 0; +} + +static int exynos_sysmmu_v5_get_fault_info(struct sysmmu_drvdata *data, + unsigned int itype, + struct sysmmu_fault *fault) +{ + unsigned int addr_reg; + + if (itype < ARRAY_SIZE(sysmmu_v5_fault_names)) { + fault->type = IOMMU_FAULT_READ; + addr_reg = REG_V5_FAULT_AR_VA; + } else if (itype >= 16 && itype <= 20) { + fault->type = IOMMU_FAULT_WRITE; + addr_reg = REG_V5_FAULT_AW_VA; + itype -= 16; + } else { + return -ENXIO; + } + + fault->name = sysmmu_v5_fault_names[itype]; + fault->addr = readl(data->sfrbase + addr_reg); + + return 0; +} + /* SysMMU v1..v3 */ static const struct sysmmu_variant sysmmu_v1_variant = { .flush_all = 0x0c, @@ -300,6 +344,8 @@ static const struct sysmmu_variant sysmmu_v1_variant = { .pt_base = 0x14, .int_status = 0x18, .int_clear = 0x1c, + + .get_fault_info = exynos_sysmmu_v1_get_fault_info, }; /* SysMMU v5 and v7 (non-VM capable) */ @@ -312,6 +358,8 @@ static const struct sysmmu_variant sysmmu_v5_variant = { .flush_end = 0x24, .int_status = 0x60, .int_clear = 0x64, + + .get_fault_info = exynos_sysmmu_v5_get_fault_info, }; /* SysMMU v7: VM capable register set */ @@ -324,6 +372,8 @@ static const struct sysmmu_variant sysmmu_v7_vm_variant = { .flush_end = 0x8024, .int_status = 0x60, .int_clear = 0x64, + + .get_fault_info = exynos_sysmmu_v5_get_fault_info, }; static struct exynos_iommu_domain *to_exynos_domain(struct iommu_domain *dom) @@ -453,68 +503,56 @@ static void __sysmmu_get_version(struct sysmmu_drvdata *data) } static void show_fault_information(struct sysmmu_drvdata *data, - const struct sysmmu_fault_info *finfo, - sysmmu_iova_t fault_addr) + const struct sysmmu_fault *fault) { sysmmu_pte_t *ent; - dev_err(data->sysmmu, "%s: %s FAULT occurred at %#x\n", - dev_name(data->master), finfo->name, fault_addr); + dev_err(data->sysmmu, "%s: [%s] %s FAULT occurred at %#x\n", + dev_name(data->master), + fault->type == IOMMU_FAULT_READ ? "READ" : "WRITE", + fault->name, fault->addr); dev_dbg(data->sysmmu, "Page table base: %pa\n", &data->pgtable); - ent = section_entry(phys_to_virt(data->pgtable), fault_addr); + ent = section_entry(phys_to_virt(data->pgtable), fault->addr); dev_dbg(data->sysmmu, "\tLv1 entry: %#x\n", *ent); if (lv1ent_page(ent)) { - ent = page_entry(ent, fault_addr); + ent = page_entry(ent, fault->addr); dev_dbg(data->sysmmu, "\t Lv2 entry: %#x\n", *ent); } } static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id) { - /* SYSMMU is in blocked state when interrupt occurred. */ struct sysmmu_drvdata *data = dev_id; - const struct sysmmu_fault_info *finfo; - unsigned int i, n, itype; - sysmmu_iova_t fault_addr; + unsigned int itype; + struct sysmmu_fault fault; int ret = -ENOSYS; WARN_ON(!data->active); - if (MMU_MAJ_VER(data->version) < 5) { - finfo = sysmmu_faults; - n = ARRAY_SIZE(sysmmu_faults); - } else { - finfo = sysmmu_v5_faults; - n = ARRAY_SIZE(sysmmu_v5_faults); - } - spin_lock(&data->lock); - clk_enable(data->clk_master); itype = __ffs(readl(SYSMMU_REG(data, int_status))); - for (i = 0; i < n; i++, finfo++) - if (finfo->bit == itype) - break; - /* unknown/unsupported fault */ - BUG_ON(i == n); - - /* print debug message */ - fault_addr = readl(data->sfrbase + finfo->addr_reg); - show_fault_information(data, finfo, fault_addr); - - if (data->domain) - ret = report_iommu_fault(&data->domain->domain, - data->master, fault_addr, finfo->type); - /* fault is not recovered by fault handler */ - BUG_ON(ret != 0); + ret = data->variant->get_fault_info(data, itype, &fault); + if (ret) { + dev_err(data->sysmmu, "Unhandled interrupt bit %u\n", itype); + goto out; + } + show_fault_information(data, &fault); + if (data->domain) { + ret = report_iommu_fault(&data->domain->domain, data->master, + fault.addr, fault.type); + } + if (ret) + panic("Unrecoverable System MMU Fault!"); + +out: writel(1 << itype, SYSMMU_REG(data, int_clear)); + /* SysMMU is in blocked state when interrupt occurred */ sysmmu_unblock(data); - clk_disable(data->clk_master); - spin_unlock(&data->lock); return IRQ_HANDLED;
Fault info obtaining is implemented for SysMMU v1..v5 in a very hardware specific way, as it relies on: - interrupt bits being tied to read or write access - having separate registers for the fault address w.r.t. AR/AW ops Newer SysMMU versions (like SysMMU v7) have different way of providing the fault info via registers: - the transaction type (read or write) should be read from the register (instead of hard-coding it w.r.t. corresponding interrupt status bit) - there is only one single register for storing the fault address Because of that, it is not possible to add newer SysMMU support into existing paradigm. Also it's not very effective performance-wise: - checking SysMMU version in ISR each time is not necessary - performing linear search to find the fault info by interrupt bit can be replaced with a single lookup operation Pave the way for adding support for new SysMMU versions by abstracting the getting of fault info in ISR. While at it, do some related style cleanups as well. This is mostly a refactoring patch, but there are some minor functional changes: - fault message format is a bit different; now instead of AR/AW prefixes for the fault's name, the request direction is printed as [READ]/[WRITE]. It has to be done to prepare an abstraction for SysMMU v7 support - don't panic on unknown interrupts; print corresponding message and continue - if fault wasn't recovered, panic with some sane message instead of just doing BUG_ON() The whole fault message looks like this now: [READ] PAGE FAULT occurred at 0x12341000 Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> --- drivers/iommu/exynos-iommu.c | 162 +++++++++++++++++++++-------------- 1 file changed, 100 insertions(+), 62 deletions(-)