Hey Eliot,
thank you for your help. I experimented with the checks and I was a bit suprised, that the Page Fault seems not to be raised after a unsuccessful user/supervisor check. After enabling the necessary debug flags and including more Debug statements into the code, I observed that the Page Fault is not raised after entering the If-statement, but before it. Here is a short snippet of my outputs:
14442496349500: system.repeat_switch_cpus5.mmu.dtb: inUser = 1 | entry_user = 1 | badWrite = 0 (Line 470)
14442496349500: system.repeat_switch_cpus5.mmu.dtb: Checks done! (Line 485)
14442496350000: system.repeat_switch_cpus5.mmu.dtb: inUser = 1 | entry_user = 1 | badWrite = 0
14442496350000: system.repeat_switch_cpus5.mmu.dtb: Checks done!
14442496361000: Page-Fault: RIP 0x402da9: vector 14: #PF(0x4) at 0xffff880019688110
14442496387000: system.repeat_switch_cpus5.mmu.itb: inUser = 1 | entry_user = 0 | badWrite = 1
14442496387000: system.repeat_switch_cpus5.mmu.itb: ***************************** If [Line 471]. *****************************************
14442496424000: system.repeat_switch_cpus5.mmu.dtb: inUser = 0 | entry_user = 0 | badWrite = 1
14442496424000: system.repeat_switch_cpus5.mmu.dtb: Checks done!
14442496464000: system.repeat_switch_cpus5.mmu.dtb: inUser = 0 | entry_user = 0 | badWrite = 1
14442496464000: system.repeat_switch_cpus5.mmu.dtb: Checks done!
I expected, that the Page Fault is raised at line 476, but it doesn't seem so.
For further context, my goal is to get this code (https://github.com/IAIK/meltdown/blob/master/reliability.c) working in gem5. Currently, "libkdump_read" (https://github.com/IAIK/meltdown/blob/master/libkdump/libkdump.c#L528) only returns 0 in gem5.
My guess is, that I need to change much more than initially thought. With reference to the answer of Yuan, I guess that I also need to change stuff in the function chain for handling a fault. Can anyone confirm this?
Best regards,
Robin
Gesendet: Mittwoch, 04. Oktober 2023 um 17:00 Uhr
Von: "Eliot Moss via gem5-users" <gem5-users@gem5.org>
An: "The gem5 Users mailing list" <gem5-users@gem5.org>, yuan....@it.uu.se
Cc: reverent.gr...@web.de, "Eliot Moss" <m...@cs.umass.edu>
Betreff: [gem5-users] Re: Squashing Instructions after Page Table Fault
Von: "Eliot Moss via gem5-users" <gem5-users@gem5.org>
An: "The gem5 Users mailing list" <gem5-users@gem5.org>, yuan....@it.uu.se
Cc: reverent.gr...@web.de, "Eliot Moss" <m...@cs.umass.edu>
Betreff: [gem5-users] Re: Squashing Instructions after Page Table Fault
On 10/4/2023 10:03 AM, reverent.green--- via gem5-users wrote:
> Hi Yuan,
> thank you very much for your detailed response. My understanding of the
> fault handling in gem5 is getting better and better. Using debug flags, I
> can trace the control flow during the execution of my code.
> I am currently inspecting tlb.cc in further detail, but I am still searching
> for the exact check for my problem. To further specify my question:
> During the attempt to access kernel memory, the “user/supervisor” (U/S)
> pagetable attribute is used to check whether this page table belongs to
> kernel memory or not. If I want to access the memory, it should raise the
> page table fault. I am looking for this specific check. My goal is, to
> experiment with gem5 and to customize it. Currently, the instruction is not
> executed when raising a Page Table Fault. In a first step, I want to change
> the check in order to execute the instruction although it wants to access
> kernel memory. So I explicitly search for this check inside this command
> chain during the Page Fault handling.
> Thank you very much in advance.
> Best regards
> Robin
Assuming we're talking about the x86 architecture, line 471 in tlb.cc is where
the check in question happens:
https://github.com/gem5/gem5/blob/48a40cf2f5182a82de360b7efa497d82e06b1631/src/arch/x86/tlb.cc#L471
Note that the raw bits of the PTE have been abstracted out in the gem5 TLB
entry data structure, hence properties such as entry->user.
HTH
Eliot Moss
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
> Hi Yuan,
> thank you very much for your detailed response. My understanding of the
> fault handling in gem5 is getting better and better. Using debug flags, I
> can trace the control flow during the execution of my code.
> I am currently inspecting tlb.cc in further detail, but I am still searching
> for the exact check for my problem. To further specify my question:
> During the attempt to access kernel memory, the “user/supervisor” (U/S)
> pagetable attribute is used to check whether this page table belongs to
> kernel memory or not. If I want to access the memory, it should raise the
> page table fault. I am looking for this specific check. My goal is, to
> experiment with gem5 and to customize it. Currently, the instruction is not
> executed when raising a Page Table Fault. In a first step, I want to change
> the check in order to execute the instruction although it wants to access
> kernel memory. So I explicitly search for this check inside this command
> chain during the Page Fault handling.
> Thank you very much in advance.
> Best regards
> Robin
Assuming we're talking about the x86 architecture, line 471 in tlb.cc is where
the check in question happens:
https://github.com/gem5/gem5/blob/48a40cf2f5182a82de360b7efa497d82e06b1631/src/arch/x86/tlb.cc#L471
Note that the raw bits of the PTE have been abstracted out in the gem5 TLB
entry data structure, hence properties such as entry->user.
HTH
Eliot Moss
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
