History log of /XiangShan/src/main/scala/xiangshan/cache/mmu/PageTableWalker.scala (Results 1 – 25 of 142)
Revision Date Author Comments
# 57a8ca5e 20-Apr-2025 Haoyuan Feng <[email protected]>

fix(LLPTW): dup_wait_resp should not send last_hptw_req when excp (#4596)

In the original design, the condition for `to_last_hptw_req` was:
`dup_wait_resp && entries(io.mem.resp.bits.id).req_info.s2

fix(LLPTW): dup_wait_resp should not send last_hptw_req when excp (#4596)

In the original design, the condition for `to_last_hptw_req` was:
`dup_wait_resp && entries(io.mem.resp.bits.id).req_info.s2xlate ===
allStage`. As a result, when a newly entered LLPTW request dups with an
entry currently returning from memory, and the new request is marked as
allStage, the `to_last_hptw_req` signal would be true. This causes the
state machine to transition to the `state_last_hptw_req` state and send
a request to HPTW.

However, if the page table returned from memory contains a `vsStagePf`
or `gStagePf`, it should directly go to `mem_out` or `bitmap_check`
without performing a final HPTW translation. Therefore, this commit
fixes the bug by adding a restriction to the original `to_last_hptw_req`
condition to ensure that no exceptions are present; otherwise, the state
machine will transition to either `mem_out` or `bitmap_check`.

Additionally, this PR also fixes a bug where `last_hptw_req_ppn` did not
account for the napot case.

show more ...


# 96b05afa 20-Apr-2025 Haoyuan Feng <[email protected]>

fix(LLPTW): dup entry should consider s2xlate in need_to_waiting_vec (#4597)


# c4ffb7e4 20-Apr-2025 Haoyuan Feng <[email protected]>

fix(PTW): false positive accessFault should not use af_level when resp (#4586)

In certain cases where a `pageFault` or `guestFault` occurs,
`accessFault` signal might still be true; however, it is a

fix(PTW): false positive accessFault should not use af_level when resp (#4586)

In certain cases where a `pageFault` or `guestFault` occurs,
`accessFault` signal might still be true; however, it is actually
invalid and should not be reported. We fixed this bug in commit
https://github.com/OpenXiangShan/XiangShan/pull/4540.

However, in the previous design, the level field of the PTW response was
defined as: `Mux(accessFault, af_level, Mux(guestFault, gpf_level,
level))`. As a result, although we fixed the false accessFault reporting
in https://github.com/OpenXiangShan/XiangShan/pull/4540, the level in
the PTW response was still incorrectly set to `af_level`. This commit
fixes that issue.

Additionally, this commit extracts the arguments in `ptw_resp.apply`
into separate variables to improve code readability. Previously, it was
incorrectly assumed that `pte_valid` was a required condition for
`guestFault`, using the condition: `!(pte_valid && (pageFault ||
guestFault))`. In fact, only `pageFault` needs to consider `pte_valid`;
`guestFault` does not depend on it. This bug is also fixed in this
commit.

show more ...


# e5ff9bcb 14-Apr-2025 Haoyuan Feng <[email protected]>

fix(PTW): fix exception gen when both af and (pf | gpf) occur (#4540)

When `pte_valid` is true and a page fault or guest page fault occurs,
the original design only treated `ppn_af` as invalid (with

fix(PTW): fix exception gen when both af and (pf | gpf) occur (#4540)

When `pte_valid` is true and a page fault or guest page fault occurs,
the original design only treated `ppn_af` as invalid (without checking
whether the higher bits of ppn are zero). However, in this case, the PMP
check would still be performed, potentially raising the `accessFault`
signal.

This commit fixes the bug by ensuring that if a PMP check fails, only
`accessFault` is raised, and pf or gpf will not be incorrectly asserted.
Therefore, when either pf or gpf is valid, any `accessFault` resulting
from PMP should be ignored.

show more ...


# e7412eb4 14-Apr-2025 Haoyuan Feng <[email protected]>

fix(LLPTW): each LLPTW entry should use its own s2xlate (#4510)

In the previous design, the input s2xlate signal was directly used to
determine whether to virtualize, but the input signal changed to

fix(LLPTW): each LLPTW entry should use its own s2xlate (#4510)

In the previous design, the input s2xlate signal was directly used to
determine whether to virtualize, but the input signal changed to the
default value 0 due to timing problems, resulting in the use of the
wrong PBMTE.

In fact, LLPTW can handle both virtualized and non-virtualized requests
simultaneously. This information is stored in
entries(i).req_info.s2xlate. By using this signal, we can distinguish
between PBMTEs under different virtualization modes. This commit fixes
the bug.

Co-authored-by: SpecialWeeks <[email protected]>

show more ...


# 8c9da034 09-Apr-2025 Haoyuan Feng <[email protected]>

fix(LLPTW): should not check g-stage pf when vs-stage pf occured (#4525)

When vs-stage pagefault occurs, check high bits of gvpn for g-stage is
meaningless, and should not report guest page fault.


# 98ca902e 09-Apr-2025 Haoyuan Feng <[email protected]>

fix(PTW): should not do pmp check before G-stage finish (#4524)

In https://github.com/OpenXiangShan/XiangShan/pull/4422, For the
virtualized allStage scenario, we attempt to suppress PMP checks unti

fix(PTW): should not do pmp check before G-stage finish (#4524)

In https://github.com/OpenXiangShan/XiangShan/pull/4422, For the
virtualized allStage scenario, we attempt to suppress PMP checks until
the G-stage translation result is returned. However, the approach used
in https://github.com/OpenXiangShan/XiangShan/pull/4422 is to try
ignoring the `accessFault` result when `io.hptw.req.valid` is asserted.

In reality, the `accessFault` signal remains valid because it is
implemented as a `RegEnable`. Therefore, we need to prevent
`sent_to_pmp` from being asserted when sending the G-stage translation
request to HPTW. To address this, we introduce the `vs_finish` signal.
When `vs_finish` is `true.B`, `sent_to_pmp` will be false, thus avoiding
false `accessFault` reports.

show more ...


# 220c4701 01-Apr-2025 Haoyuan Feng <[email protected]>

fix(PTW): fix gpf_level generate logic when Sv39 (#4482)

For historical reasons, `gpf_level` needs to be 1 greater than
`af_level`. In the original design, only the Sv48 case was considered,
and a s

fix(PTW): fix gpf_level generate logic when Sv39 (#4482)

For historical reasons, `gpf_level` needs to be 1 greater than
`af_level`. In the original design, only the Sv48 case was considered,
and a similar treatment is needed for the Sv39 case.

As an extra note here, `gpf_level` is a 2-bit register, so when
`gpf_level` = 0.U, `gpf_level` - 2.U = `00` - 2 = `10` = 2.U. The PTW
module's `gpf_level` computation uses this feature, which is extremely
unscalable, and, except for the original author, is completely
incomprehensible, and is in dire need of refactoring.

show more ...


# 16de2f57 01-Apr-2025 Haoyuan Feng <[email protected]>

fix(PTW): fix gvpn check when req first enter PTW (#4481)

In the previous design, we used `gvpn_gpf` to detect whether the G-Stage
meets the gvpn high level of 0 after the VS-Stage translation is
co

fix(PTW): fix gvpn check when req first enter PTW (#4481)

In the previous design, we used `gvpn_gpf` to detect whether the G-Stage
meets the gvpn high level of 0 after the VS-Stage translation is
completed in allStage case, or else a guest page fault is reported.

However, due to some historical reasons, `gvpn_gpf` can only be used to
detect guest faults during the translation process; for the first time
when entering the PTW after the request to query the Page Table Cache
has finished, similar error checking will be done in
`check_gpa_high_fail`, but when the PTW resp valid is 1, the error
checking will be done in `check_gpa_high_fail`, `full_gvpn` has been
cleared to 0 (line 374), so `gvpn_gpf` will not be 1 (should be 1),
resulting in an error in the returned message.

I do not know why it was designed this way at the time, so I had to add
another `first_gvpn_check_fail` signal to indicate that the first
request into the PTW didn't satisfy the gvpn's high level check, and
therefore needed to report a guest page fault.

show more ...


# e65b7d6b 29-Mar-2025 Haoyuan Feng <[email protected]>

fix(LLPTW): Should consider napot scenario when allStage (#4473)

In previous design, we always use `ptes(index).getPPN()` to generate PPN
for last G-stage translate. However, when VS-Stage is napot,

fix(LLPTW): Should consider napot scenario when allStage (#4473)

In previous design, we always use `ptes(index).getPPN()` to generate PPN
for last G-stage translate. However, when VS-Stage is napot, we should
use the low 4 bits of vpn for generating ppn.

show more ...


# 23ec23f2 29-Mar-2025 Haoyuan Feng <[email protected]>

fix(PTW): Should not do gvpn check when pageFault or ppn_af (#4472)

when pageFault or ppn_af valid, it means that an exception occurs when
Stage1 translation. So should not check high bits of gvpn(S

fix(PTW): Should not do gvpn check when pageFault or ppn_af (#4472)

when pageFault or ppn_af valid, it means that an exception occurs when
Stage1 translation. So should not check high bits of gvpn(Stage2 check)

show more ...


# fc4ea7c0 24-Mar-2025 Haoyuan Feng <[email protected]>

fix(MMU): Stage1Gpf should use hgatp instead of vsatp (#4448)


# f8c4173d 23-Mar-2025 Haoyuan Feng <[email protected]>

fix(PTW): Fix exception handle logic when both pf and af occur (#4422)

In the previous design, every time a page table entry was fetched from
memory, a PMP check was performed on the physical addres

fix(PTW): Fix exception handle logic when both pf and af occur (#4422)

In the previous design, every time a page table entry was fetched from
memory, a PMP check was performed on the physical address of the
next-level page table. However, for cases requiring Stage-2 address
translation or when a page fault occurs during the page table fetch, a
PMP check is unnecessary. Performing a PMP check in these cases could
lead to false access fault reports. This commit fixes the issue.

Future work: The current exception handling logic is messy and
unsustainable. A complete refactor of this code is needed in the future,
rather than continuing to add patches.

show more ...


# 6aa6d737 13-Mar-2025 Haoyuan Feng <[email protected]>

fix(PTW): High bits of GVPN should not be truncated (#4406)


# e5429136 13-Mar-2025 Haoyuan Feng <[email protected]>

fix(LLPTW): Fix exception judgement for different virtualisation stages (#4404)

In the previous exception handling in LLPTW, both isAf and isGpf were
checked for all cases, including allStage, onlyS

fix(LLPTW): Fix exception judgement for different virtualisation stages (#4404)

In the previous exception handling in LLPTW, both isAf and isGpf were
checked for all cases, including allStage, onlyStage1, and noS2xlate.

In fact, for allStage, only isPf & isGpf needs to be checked, while for
onlyStage1 and noS2xlate, only isPf & isAf should be checked.

This commit fixes this issue.

show more ...


# d6b0a27f 09-Mar-2025 LMiaoH <[email protected]>

fix(Bitmap): Fix early `s_llptw_req` trigger in PTW (#4375)

- When `HasBitmapCheck` is enabled in `CVMConfig`.
- PTW module checks whether a bitmap check(`whether_need_bitmap_check`)
is needed after

fix(Bitmap): Fix early `s_llptw_req` trigger in PTW (#4375)

- When `HasBitmapCheck` is enabled in `CVMConfig`.
- PTW module checks whether a bitmap check(`whether_need_bitmap_check`)
is needed after receiving a `mem.resp` . then set `s_llptw_req` to be
valid and send a request to LLPTW.
- However, the `s_llptw_req` signal becomes valid one cycle too early.

Co-authored-by: LMiao <[email protected]>

show more ...


# 8882eb68 21-Feb-2025 Xin Tian <[email protected]>

feat(bitmap/memenc): support memory isolation by bitmap checking and memory encrpty used SM4-XTS (#3980)

- Add bitmap module in MMU for memory isolation
- Add memory encryption module based on AXI p

feat(bitmap/memenc): support memory isolation by bitmap checking and memory encrpty used SM4-XTS (#3980)

- Add bitmap module in MMU for memory isolation
- Add memory encryption module based on AXI protoco
- Can don't using these modules by setting the option `HasMEMencryption`
& `HasBitmapCheck` to false

show more ...


# 48639700 26-Dec-2024 Xu, Zefan <[email protected]>

fix(PTW): incorrect GPF due to timing mismatch (#4090)

In PTW/LLPTW/HPTW, mem.resp.fire is set in first cycle, but
mem.resp.data comes in second cycle. The signal full_gvpn depends on mem
data, but

fix(PTW): incorrect GPF due to timing mismatch (#4090)

In PTW/LLPTW/HPTW, mem.resp.fire is set in first cycle, but
mem.resp.data comes in second cycle. The signal full_gvpn depends on mem
data, but it is incorrectly updated in first cycle, retrieving the old
value. This leads to an in correct GPF.

This patch tries to fix this problem. It splits full_gvpn into wire and
reg, and introduces a new signal to control the update of reg and the
selection between wire and reg.

show more ...


# 81ed4161 11-Dec-2024 Jiuyue Ma <[email protected]>

fix(frontend,cache): fix warning of read-only return value of `.asTypeOf` (#4005)

Signed-off-by: Jiuyue Ma <[email protected]>
Co-authored-by: Easton Man <[email protected]>


# 3dfb64bd 25-Nov-2024 Zehao Liu <[email protected]>

fix(HPM): fix PTW perfevent print error, organize the code format of some perfevents (#3890)

`getperfevent` retrieves both the `name` and `value` fields, whereas
`getperf` only retrieves the `value

fix(HPM): fix PTW perfevent print error, organize the code format of some perfevents (#3890)

`getperfevent` retrieves both the `name` and `value` fields, whereas
`getperf` only retrieves the `value` port. The original implementation
caused all perf event information for PTW to be printed as
`perfEventsPTW`, making them indistinguishable.

show more ...


# faf7d50b 26-Oct-2024 Xiaokun-Pei <[email protected]>

fix(PTW, RVH): modify the logic of checking high bits of gpaddr (#3679)

- In PTW, use a reg to store gvpn to check the high bits.
- The len of gvpn(wire type) is wrong. It should be ptePPNLen.


# 2d991346 25-Oct-2024 Xiaokun-Pei <[email protected]>

fix(PTW, RVH): add the high bits check of the first s2xlate when the req is allstage (#3681)


# 979d98ae 27-Sep-2024 Xiaokun-Pei <[email protected]>

fix(PTW, RVH): fix the priority of gpf, gaf and gvpn_gpf in PTW (#3657)

If hptw resp gpf or gaf, the gvpn_gpf should not be valid. The pr fixes
the bug that gvpn_gpf is valid after hptw resp gpf or

fix(PTW, RVH): fix the priority of gpf, gaf and gvpn_gpf in PTW (#3657)

If hptw resp gpf or gaf, the gvpn_gpf should not be valid. The pr fixes
the bug that gvpn_gpf is valid after hptw resp gpf or gaf.

show more ...


# fa9d630e 23-Sep-2024 Xiaokun-Pei <[email protected]>

fix(PTW, RVH): fix the gpa high check fail in last s2xlate due to a change of gpaddr (#3624)


# 865f73fe 20-Sep-2024 Haoyuan Feng <[email protected]>

fix(PageTableWalker): last_s2xlate should be false when exception occurs (#3614)


123456