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

[mhorne]

Summary

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

Test Plan

Events work on x86 and arm64. Passes tinderbox.

[mhorne]

sys/sys/pmckern.h

272

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

[kib]

Why not move this to vm_fault_trap()?

[mhorne]

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.

[kib]

In D30219#678561, @mhorne 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.

[jhb]

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?

[mhorne]

In D30219#678569, @kib wrote:

In D30219#678561, @mhorne 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.

[kib]

In D30219#681183, @mhorne wrote:

In D30219#678569, @kib wrote:

In D30219#678561, @mhorne 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.

[jhb]

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.