Page MenuHomeFreeBSD

Hardware Trace (HWT) framework
Needs ReviewPublic

Authored by br on Jun 7 2023, 3:02 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Apr 19, 2:25 AM
Unknown Object (File)
Mar 20 2024, 2:58 AM
Unknown Object (File)
Feb 18 2024, 8:17 PM
Unknown Object (File)
Feb 18 2024, 6:36 AM
Unknown Object (File)
Feb 17 2024, 6:31 PM
Unknown Object (File)
Feb 6 2024, 4:01 AM
Unknown Object (File)
Feb 4 2024, 1:05 AM
Unknown Object (File)
Jan 29 2024, 10:00 AM

Details

Summary

Hardware Trace (HWT) v0.1

HWT framework manages hardware technology that collects information about software execution and records it as "events" in highly compressed format into DRAM. The events cover information about control flow changes of a program, whether branches taken or not, exceptions taken, timing information, cycles elapsed and more. This allowing us to restore entire program flow of a given application.

Initially targeting ARM Coresight technology included into ARM64 processors.

Part2: ARM Coresight Support
Part3: hwt(8) instrumentation tool

Test Plan

Tested on ARM Morello. This patch is for CheriBSD, but could be applied on FreeBSD as well with minor (non-functional) changes.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
br retitled this revision from New Hardware Trace (HWT) framework to Hardware Trace (HWT) framework.

Split out thread/backend/owner/context code to separate files.

Return ctx locked in hwt_ctx_lookup_contexthash().

Split out ioctl code to a separate file.

Split out ownerhash/contexthash code to a separate files.

Remove mtx_threads and mtx_records. Use mtx of entire context

Add hwt_hook variable and HWT_CALL_HOOK macro

Add hwt_hook variable and HWT_CALL_HOOK macro

Add short overview and context lifecycle.

br marked 8 inline comments as done.

Move hwt files to conf/files.

Move changes related to coresight to another review

This looks like a kernel with HWT_HOOKS but not HWT wouldn't link as, for example, hwt_switch_in will be missing. HWPMC handles this by adding a function pointer and protects it with an epoch.

I added this functionality. I am not sure if epoch is needed. PMC have several macroses for hook invocation, only some of them require epoch.

We should handle multiple trace backends, e.g. CoreSight and SPE. One way to test multiple backends is to have an exception trace that logs exception info when taking one from userspace.

Yes, I added this. Looking forward to help with SPE.

sys/dev/hwt/hwt.c
349

I added option to user API so user have to specify buffer size for each thread on context allocation.

355–356

For mapping trace buffers to userspace. One device per each thread of target proc.

656

Implemented, thanks!

sys/dev/hwt/hwt.h
51 ↗(On Diff #123108)

I have re-implemented this part, so we now have just one context, but multiple threads within context. Each thread has its own trace buffers and character device /dev/hwt_%pid_%tid so that user can map trace buffers.

53 ↗(On Diff #123108)

It is passed from userspace to kernel, so why not

ip range filtering (draft) added

suspend specific thread on mmap, not entire proc

Initial work on cpu/system mode of operation

Kernel-mode tracing support added.

sys/kern/imgact_elf.c
1380

How are the HWT_RECORD_EXECUTABLE and HWT_RECORD_INTERP records expected to be used? They use CheriBSD specific variables.

1385–1386

Should the addr and size be related? The address is the entry point and the size appears to be the size of the section, however the entry point may not be at the start of the section.

Remove cheribsd-specific "size" member from hwt_record as not needed

sys/kern/imgact_elf.c
1380

these are fed into pmcstat_image_link(). Size arg is not needed so I removing it. Should work on both FreeBSD/cheribsd with minor (non-functional) changes

1385–1386

thanks "size" was used for debugging only.
pmcstat_image_link() does not require size argument, so I've removed it

Allow tracing multiple cpus in CPU(system) mode

Code cleanup. Implement some TODOs

br removed subscribers: glebius, lwhsu, andrew.

Fix context ID allocation, do not allocate twice and check the status of allocation

Add description for CPU mode of operation into hwt.c

br edited the test plan for this revision. (Show Details)
cy removed a subscriber: cy.

Allow attaching to an existed proc

change backend lock, ident set lock, ownerhash lock to standard mtx

sys/sys/hwt.h
60

The cpuset_t could cause ABI issues when we bump MAXCPU. vmm.ko on amd64 was recently changed to not embed it in the struct in rGe17eca327633efc511450310afb5e4a662724e3d

Replace most of spin locks to standard mtx. Use refcounting in some places

User provides cpusetsize together with *cpuset_t.

sys/sys/hwt.h
60

Thanks I have updated; cpusetsize is now supplied by a user; cpuset_t is now a pointer

Can you rebase the stack on FreeBSD so we can test on non-Morello hardware?

Pass ctx to backend_deinit().

sys/dev/hwt/hwt_context.c
71

In what situations do we have more than one hwt_context? This allocates a unique ident from 0 to 1<<8 but as far as I can tell in both hwt_ioctl_alloc_mode_{thread,cpu} we only allocate a single context aka ident 0.

sys/dev/hwt/hwt_context.c
71

I guess this may happen if two users simultaneously using hwt. This is not possible in coresight, but possible in Intel PT and probably SPE ?

sys/dev/hwt/hwt_context.c
71

Ah yep - okay makes sense. It should be possible to run Coresight and SPE simultaneously at least.

On SPE everything is per core, so you *should* be able to trace on all cores separately. Two users tracing the same core would not be possible. Not sure how that would work with THREAD_MODE, as would depend on where the task is scheduled - I guess no concurrent SPE users will be possible there. I've only implemented CPU_MODE so far.

br added a reviewer: bnovkov.

Regenerate