事情有些复杂。
最开始我为了修复sel4bench的性能问题，尝试了进行修复，其修复在fix_fastpath分支，主要包含两个问题，一个是fastpath没有进去的问题，另一个是tlb刷新的问题。前者不是这个issue需要讨论的，不说，先说后者，具体如图所示
相当于每次都把所有的tlb全清。那每次都清理tlb，这个性能能好么，所以perf需要修复这个bug，也是没毛病的。
他的修复一个是注释掉这里，另一个是在unmap_page函数最后改为invalidate_tlb_by_asid_va(asid, vptr);原先用的是invalidate_tlb_by_asid函数，所以过不去。
OK，但是，注意，这个fix_fastpath分支相比于master分支，所衍生出来的commit，是在yfblock做了一堆提交改动之前的。
于是，我试图把这个改动同步到master分支，但是ci过不去。
经过最小化的尝试，我确定就是这个tlb刷新的问题。
那为什么在更早的commit衍生出来的版本能过去，最新的master分支再加上这个补丁就过不去呢？
我试图查看yfblock做了什么，我看到很多地方改成了paddr的宏，举个例子：
这里调用的这个函数就是之前这里需要注释掉全刷tlb函数的代码。
当然这肯定不止这一处地方。
所以我很有理由怀疑，是因为yfblock的更改导致了这里的问题，至于具体机制我认为是这样的，按道理，需要所有函数调用链路上的paddr都被正确的修改，他的修改才会生效，但是他应该没改对，然而，tlb清理的地址改错了会有什么影响呢？ master的代码是全清所有tlb啊，所以就算改错了，也没有影响，只有当我试图，去去除这个tlb全清代码之后，他才会出bug。
原理说完了，啥时候能修好我也不知道。rel4项目已经很久没开会了，如果只是要给个测评结果写毕业论文，那我用fix fastpath分支，本地跑跑就好了。那我就不知道啥时候能搞定（摊手）
事情有些复杂。
最开始我为了修复sel4bench的性能问题，尝试了进行修复，其修复在fix_fastpath分支，主要包含两个问题，一个是fastpath没有进去的问题，另一个是tlb刷新的问题。前者不是这个issue需要讨论的，不说，先说后者，具体如图所示
他的修复一个是注释掉这里，另一个是在unmap_page函数最后改为invalidate_tlb_by_asid_va(asid, vptr);原先用的是invalidate_tlb_by_asid函数，所以过不去。
OK，但是，注意，这个fix_fastpath分支相比于master分支，所衍生出来的commit，是在yfblock做了一堆提交改动之前的。
于是，我试图把这个改动同步到master分支，但是ci过不去。
经过最小化的尝试，我确定就是这个tlb刷新的问题。
那为什么在更早的commit衍生出来的版本能过去，最新的master分支再加上这个补丁就过不去呢？
我试图查看yfblock做了什么，我看到很多地方改成了paddr的宏，举个例子：
这里调用的这个函数就是之前这里需要注释掉全刷tlb函数的代码。
当然这肯定不止这一处地方。
所以我很有理由怀疑，是因为yfblock的更改导致了这里的问题，至于具体机制我认为是这样的，按道理，需要所有函数调用链路上的paddr都被正确的修改，他的修改才会生效，但是他应该没改对，然而，tlb清理的地址改错了会有什么影响呢？ master的代码是全清所有tlb啊，所以就算改错了，也没有影响，只有当我试图，去去除这个tlb全清代码之后，他才会出bug。
原理说完了，啥时候能修好我也不知道。rel4项目已经很久没开会了，如果只是要给个测评结果写毕业论文，那我用fix fastpath分支，本地跑跑就好了。那我就不知道啥时候能搞定（摊手）