Page MenuHomeFreeBSD

generate pmc.soft(3) page fault events on !x86
Needs ReviewPublic

Authored by mhorne on May 11 2021, 8:46 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 19 2024, 3:16 AM
Unknown Object (File)
Dec 22 2023, 11:49 PM
Unknown Object (File)
Dec 21 2023, 8:27 PM
Unknown Object (File)
Aug 27 2023, 2:42 PM
Unknown Object (File)
Aug 13 2023, 6:38 AM
Unknown Object (File)
Jun 26 2023, 6:54 PM
Unknown Object (File)
May 5 2023, 1:56 AM
Unknown Object (File)
Apr 20 2023, 1:17 AM

Details

Summary

A helper function is added to pmckern.h to slightly reduce the
duplication.

Test Plan

Events work on x86 and arm64. Passes tinderbox.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 39128
Build 36017: arc lint + arc unit

Event Timeline

sys/sys/pmckern.h
272

This is a bit ugly, but I wanted to avoid pulling in vm/vm.h unconditionally.

Why not move this to vm_fault_trap()?

In D30219#678555, @kib wrote:

Why not move this to vm_fault_trap()?

It would require passing the trapframe to vm_fault_trap(), which to me seems undesirable.

In D30219#678555, @kib wrote:

Why not move this to vm_fault_trap()?

It would require passing the trapframe to vm_fault_trap(), which to me seems undesirable.

We have td->td_frame for that. You would need to set it for kernel mode as well.

I think making this MI and depend on td_frame is ok. I would maybe add another commit as a followup to handle instruction fetch faults.

sys/sys/pmckern.h
285

Seems like it would be ok to add another event for instruction fetch faults as well using VM_PROT_EXEC?

In D30219#678569, @kib wrote:
In D30219#678555, @kib wrote:

Why not move this to vm_fault_trap()?

It would require passing the trapframe to vm_fault_trap(), which to me seems undesirable.

We have td->td_frame for that. You would need to set it for kernel mode as well.

This does seem like a better idea. However, doing so would affect at least the functionality in 088a7eef95b1. I'll need to check if it would affect anything else, and how to handle it.

In D30219#678569, @kib wrote:
In D30219#678555, @kib wrote:

Why not move this to vm_fault_trap()?

It would require passing the trapframe to vm_fault_trap(), which to me seems undesirable.

We have td->td_frame for that. You would need to set it for kernel mode as well.

This does seem like a better idea. However, doing so would affect at least the functionality in 088a7eef95b1. I'll need to check if it would affect anything else, and how to handle it.

For this, you could add td_user_frame, filled on fault from userspace.

Note that for td_frame, previous frame needs to be saved before update, and then restored.

I have generally assumed that 'td_frame' is the most recent trapframe on the stack, but I believe we aren't consistent about that. I agree that what I would like is to have a 'td_user_frame' that is always the "bottom" and a 'td_frame' that is always "most recent". We used to have (or might still have) a 'td_intr_frame' that was to deal with the lack of consistency in 'td_frame' IIRC.