rebase

use sleep(9) instead of thread_suspend_one

coresight_allocate() and coresight_release() calls added

another attempt to handle failure case correctly

wrap lines that are longer than 79 characters

fix style

regenerate

fix style

fix style issues (wrap long lines)

regenerate patch

fix memory leak on failure

• fix destroying device on failure
• destroy mtx lock

correctly deregister osd thread on failure

deregister osd thread on failure

Use thread_suspend_one() instead of thread_suspend_switch()

Include sys/x86/include/specialreg.h

destroy the character device first, and then osd_thread_deregister()

• Use bool literals
• Move pmc_vm_initialize() just after pmc_md_initialize()

/dev/pmc* devices permissions changed to read-only

• deregister thread OSD
• use read-only permissions for /dev/pmc*

regenerate

regenerate

regenerate

regenerate

regenerate

regenerate

regenerate

regenerate patch

X1000 is a single-core IoT cpu released 3 years ago. X1000/E even newer. They are so nice, I bought 20 of them (only 5 USD each).
Since X1000 uses parts from jz4780, may be it is better to rename jz4780 to X1000 and remove SMP support.

• Remove unneeded parenthesis in pmap_fault_fixup()
• Set PTE_X for a new entry in pmap_enter_quick_locked()

Check if PTE is valid before setting A or D bits

Don't set PTE_A bit on a regular kernel mapping too

• Don't set PTE_D bit even on kernel mappings of regular VM objects ahead of time
• Don't call to vm_fault on PTE_A, PTE_D (2nd scheme) faults. Use pmap_fault_fixup() instead

Fix issues pointed by markj

restore pte.h

looks good

In D17424#371884, @jhb wrote:

Hmm, I think for this we want to actually wait to set PTE_A and PTE_D for user mappings until we get a fault? Presumably we'd want to check in the page fault handler if f the PTE was already valid before calling vm_fault and if it was set PTE_A (and PTE_D for a write) and then retry?

Setting PTE_A/PTE_D ahead of time for the kernel mappings to avoid the extra faults is certainly sensible (and the manual suggests it IIRC), but if we set them always for user mappings than the VM won't get the right feedback about which pages are accessed vs dirty.

Don't set A and D bits ahead of time of User mappings. Set them on fault

what is test plan ?

Add a comment on why we pause the thread

fix style

I tested this on RISC-V. It boots multiuser fine.