Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Architectural State not maintained for fetch-faults #96

Open
MuhammadHammad001 opened this issue Sep 6, 2024 · 0 comments
Open

Architectural State not maintained for fetch-faults #96

MuhammadHammad001 opened this issue Sep 6, 2024 · 0 comments

Comments

@MuhammadHammad001
Copy link
Contributor

@allenjbaum , @pawks , @neelgala , @UmerShahidengr , @jamesbeyond
Consider the following log when we have a load page fault:

mem[X,0x80000A34] -> 0xA703
mem[X,0x80000A36] -> 0x0147
[746] [U]: 0x90000A34 (0x0147A703) lw a4, 20(a5)
mem[R,0x80C02914] -> 0x202000D9
trapping from U to M to handle load-page-fault
handling exc#0x0D at priv M with tval 0x91400014
CSR mstatus <- 0x00000000

As you may see that we have a specific instruction name when we have a load/store fault in our log. So, the RISC-V ISAC maintain its state with the help of instr_name/mnemonic. Consider the following value of instr_vars at some point:

{'inxFlag': None, 'xlen': 32, 'flen': 32, 'mode': 'M', 'mnemonic': 'auipc', 'iflen': 32, 'rd': 'x5', 'imm_val': 0, 'access_len': None, 'mode_change': None, 'call_type': None, 'mcause': None, 'mtval': None, 'scause': None, 'stval': None, 'rs1_val': None, 'rs2_val': None, 'rs3_val': None, 'rd_val': 4096, 'rm_val': None, 'ea_align': None, 'mvendorid': 0, 'marchid': 0, 'mimpid': 0, 'mhartid': 0, 'mstatus': 0, 'misa': 1073741824, 'medeleg': 0, 'mideleg': 0, 'mie': 0, 'mtvec': 0, 'mcounteren': 0, '784': 0, 'mscratch': 0, 'mepc': 0, 'mip': 0, 'pmpcfg0': 0, 'pmpcfg1': 0, 'pmpcfg2': 0, 'pmpcfg3': 0, 'pmpcfg4': 0, 'pmpcfg5': 0, 'pmpcfg6': 0, 'pmpcfg7': 0, 'pmpcfg8': 0, 'pmpcfg9': 0, 'pmpcfg10': 0, 'pmpcfg11': 0, 'pmpcfg12': 0, 'pmpcfg13': 0, 'pmpcfg14': 0, 'pmpcfg15': 0, 'mcycle': 0, 'minstret': 0, 'mcycleh': 0, 'minstreth': 0, 'mcountinhibit': 0, 'tselect': 0, 'tdata1': 0, 'tdata2': 0, 'tdata3': 0, 'dcsr': 0, 'dpc': 0, 'dscratch0': 0, 'dscratch1': 0, 'sstatus': 0, 'sedeleg': 0, 'sideleg': 0, 'sie': 0, 'stvec': 0, 'scounteren': 0, 'sscratch': 0, 'sepc': 0, 'sip': 0, 'satp': 0, 'vxsat': 0, 'fflags': 0, 'frm': 0, 'fcsr': 0, 'pmpaddr0': 0, 'pmpaddr1': 0, 'pmpaddr2': 0, 'pmpaddr3': 0, 'pmpaddr4': 0, 'pmpaddr5': 0, 'pmpaddr6': 0, 'pmpaddr7': 0, 'pmpaddr8': 0, 'pmpaddr9': 0, 'pmpaddr10': 0, 'pmpaddr11': 0, 'pmpaddr12': 0, 'pmpaddr13': 0, 'pmpaddr14': 0, 'pmpaddr15': 0, 'mhpmcounter3': 0, 'mhpmcounter3h': 0, 'mhpmevent3': 0, 'mhpmcounter4': 0, 'mhpmcounter4h': 0, 'mhpmevent4': 0, 'mhpmcounter5': 0, 'mhpmcounter5h': 0, 'mhpmevent5': 0, 'mhpmcounter6': 0, 'mhpmcounter6h': 0, 'mhpmevent6': 0, 'mhpmcounter7': 0, 'mhpmcounter7h': 0, 'mhpmevent7': 0, 'mhpmcounter8': 0, 'mhpmcounter8h': 0, 'mhpmevent8': 0, 'mhpmcounter9': 0, 'mhpmcounter9h': 0, 'mhpmevent9': 0, 'mhpmcounter10': 0, 'mhpmcounter10h': 0, 'mhpmevent10': 0, 'mhpmcounter11': 0, 'mhpmcounter11h': 0, 'mhpmevent11': 0, 'mhpmcounter12': 0, 'mhpmcounter12h': 0, 'mhpmevent12': 0, 'mhpmcounter13': 0, 'mhpmcounter13h': 0, 'mhpmevent13': 0, 'mhpmcounter14': 0, 'mhpmcounter14h': 0, 'mhpmevent14': 0, 'mhpmcounter15': 0, 'mhpmcounter15h': 0, 'mhpmevent15': 0, 'mhpmcounter16': 0, 'mhpmcounter16h': 0, 'mhpmevent16': 0, 'mhpmcounter17': 0, 'mhpmcounter17h': 0, 'mhpmevent17': 0, 'mhpmcounter18': 0, 'mhpmcounter18h': 0, 'mhpmevent18': 0, 'mhpmcounter19': 0, 'mhpmcounter19h': 0, 'mhpmevent19': 0, 'mhpmcounter20': 0, 'mhpmcounter20h': 0, 'mhpmevent20': 0, 'mhpmcounter21': 0, 'mhpmcounter21h': 0, 'mhpmevent21': 0, 'mhpmcounter22': 0, 'mhpmcounter22h': 0, 'mhpmevent22': 0, 'mhpmcounter23': 0, 'mhpmcounter23h': 0, 'mhpmevent23': 0, 'mhpmcounter24': 0, 'mhpmcounter24h': 0, 'mhpmevent24': 0, 'mhpmcounter25': 0, 'mhpmcounter25h': 0, 'mhpmevent25': 0, 'mhpmcounter26': 0, 'mhpmcounter26h': 0, 'mhpmevent26': 0, 'mhpmcounter27': 0, 'mhpmcounter27h': 0, 'mhpmevent27': 0, 'mhpmcounter28': 0, 'mhpmcounter28h': 0, 'mhpmevent28': 0, 'mhpmcounter29': 0, 'mhpmcounter29h': 0, 'mhpmevent29': 0, 'mhpmcounter30': 0, 'mhpmcounter30h': 0, 'mhpmevent30': 0, 'mhpmcounter31': 0, 'mhpmcounter31h': 0, 'mhpmevent31': 0, 'depa': None, 'ieva': None, 'iepa': None, 'ieva_align': None, 'iepa_align': None, 'depa_align': None, 'len_dptw': None, 'dptw0a': None, 'dptw0cont': None, 'dptw1a': None, 'dptw1cont': None, 'dptw2a': None, 'dptw2cont': None, 'dptw3a': None, 'dptw3cont': None, 'dptw4a': None, 'dptw4cont': None, 'iptw0a': None, 'iptw0cont': None, 'iptw1a': None, 'iptw1cont': None, 'iptw2a': None, 'iptw2cont': None, 'iptw3a': None, 'iptw3cont': None, 'iptw4a': None, 'iptw4cont': None, 'len_iptw': 0}

This architectural state is for the mnemonic/instr_name = auipc.

But, let's say we are trying to access a page with no execute permissions. So, for that case, obviously we will have a fetch page fault. Now, the log that Sail will give for this case will look something like:

mem[R,0x80C02914] -> 0x20300401
mem[R,0x80C01000] -> 0x203000D7
trapping from U to M to handle fetch-page-fault
handling exc#0x0C at priv M with tval 0x91400FFC
CSR mstatus <- 0x00000000

So, at this specific point, there is no mnemonic/instr_name as this was a fetch access which was unsuccessful. The problem is that RISC_V ISAC will have no architectural history maintained for this instruction because of no mnemonic which is wrong. I think this should be updated.

P.S:
I can resolve this issue but I need some help/guidance from the previous contributors as I don't specifically know that what was the reason for such a behavior of RISC-V ISAC. @pawks , @neelgala

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant