Hardware Trace (HWT) framework

[br]

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
Part4: ARM Statistical Profiling Extension (SPE) support
Part5: Intel Processor Trace (PT) support

Test Plan

Tested on ARM Morello

[br]

Allow attaching to an existed proc

[br]

Regenerate

[br]

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

[andrew]

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

[br]

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

[br]

Fix typo.

[br]

User provides cpusetsize together with *cpuset_t.

[br]

sys/sys/hwt.h

60

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

[andrew]

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

[br]

rebase for freebsd

[br]

Pass ctx to backend_deinit().

[zachary.leaf_arm.com]

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.

[br]

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 ?

[zachary.leaf_arm.com]

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]

Regenerate

[br]

Regenerate

[andrew]

How do you handle different conflicting modes? e.g. a user is tracing a pid & another tries to enable thread tracing. The hardware may not be able to perform both operations.

[br]

Regenerate

[br]

Prevent tracing the same proc by multiple users.

[br]

In D40466#1056428, @andrew wrote:

How do you handle different conflicting modes? e.g. a user is tracing a pid & another tries to enable thread tracing. The hardware may not be able to perform both operations.

I have added a session counter to coresight to ensure it is used for 1 simultaneous sessions at max (regardless of type). @bnovkov is currently working on similar arrangements for Intel PT depending on hardware capabilities.
Generally we could allow thread tracing for multiple users simultaneously in Intel PT.
Coresight is more restricted disallowing us to continue a trace session from specific place in buffer, so we completely disallow multiple users to trace simultaneously.

[markj]

I don't see any documentation for this, is there a separate review for a man page somewhere?

sys/kern/kern_hwt.c

43

We definitely don't need all of these includes.

sys/kern/vfs_vnops.c

2940

We should only do this work if the hook is actually enabled.

[markj]

sys/dev/hwt/hwt_hook.h

29

These tags shouldn't appear in new code.

[markj]

sys/vm/vm_mmap.c

1067

How is this used? You are not passing the size of the mapping anywhere, which seems wrong.

[br]

• Remove $FreeBSD$ tags
• Remove unused include headers
• Check if HWT hooks are installed before constructing data structures

sys/vm/vm_mmap.c

1067

The address of mapping passed to pmcstat. It loads elf file based on mapping address (fullpath). So it knows the size of mapping. See pmcstat_image_link().

[br]

Resubmit updated patch

[br]

Regenerate

[br]

Regenerate. Fix P2_HWT

[kib]

sys/kern/imgact_elf.c

1619

Move the ent declaration under the if().

That said, why do you hook elf image activator at all? Such hook should be generic and set somewhere in kern_exec.c.

sys/kern/kern_hwt.c

49

I doubt that two vars deserve a dedicated kern.c file. Find a place to put them elsewere.

sys/kern/sched_ule.c

3168

What about the same hooks for SCHED_4BSD?

sys/kern/vfs_vnops.c

2937

Move vars declarations under if () block.

sys/vm/vm_mmap.c

1062

Move ent under if().

Also, it seems you only hook vnodes mappings. What about anon memory, or swap-backed non-anon?

[bnovkov]

sys/vm/vm_mmap.c

1062

Also, it seems you only hook vnodes mappings. What about anon memory, or swap-backed non-anon?

The userspace decoder needs to have access to the binaries that generated the execution trace (and their location within the traced process's address space) to decode the trace, which is we only hook vnode mappings.
These hooks forward the mapping information to the userspace decoder, which will load all executable sections from the mapped binary.

I assume that this approach doesn't covers things like tracing JIT-generated code, but that can probably be fixed by placing another hook, if need be.

[br]

• Move ELF image activator hooks to generic kern_exec.c
• HWT_HOOKS: Move variable declarations under the if()
• HWT_HOOKS: Move contents of kern_hwt.c to kern_pmc.c
• Remove VM_ALLOC_NOBUSY flag from vm_page_alloc_contig() request to meet KASSERTs in vm_page.c

[br]

Add SCHED_4BSD hwt hooks

[br]

sys/kern/imgact_elf.c

1619

Agree, I have it moved to generic kern_exec.c!

sys/kern/kern_hwt.c

49

Moved to kern_pmc.c

sys/kern/sched_ule.c

3168

Ok, added and tested!

[kib]

sys/kern/kern_exec.c

945 ↗

(On Diff #157658)

946 ↗

(On Diff #157658)

There should be a blank line after vars definition block.

947 ↗

(On Diff #157658)

What does the hook do? In particular, I wonder why it needs to image text vnode unlocked.

sys/kern/vfs_vnops.c

2939

Blank line is needed after vars block.

[br]

do not unlock image text vnode

[br]

Style.

[br]

sys/kern/kern_exec.c

947 ↗

(On Diff #157658)

The hook makes a copy of ent (using uma_zalloc) and stores it into the tail queue of records to the corresponding tracing context. Then it puts the thread to sleep if needed (see hwt_hook_mmap()).
Userspace periodically fetches the queue of records, locates the address of executable/library in the records, reconfigures hardware tracing units and wakes up the sleeping thread.
Sleep is only needed when the user sets up the 'address range filtering' feature to trace a particular function of an executable/dynamic library.

Based on my experiments, unlocking image text vnode is not needed, so I remove it.

[kib]

sys/kern/kern_exec.c

947 ↗

(On Diff #157658)

Sleeping while owning a vnode lock is not prohibited, but is highly undesirable. It is tabooed when the duration of the sleep is controlled by userspace, since it causes a user-controllable live-lock: any process trying to do anything with this vnode, would be put to sleep until the sleeping thread wakes up and unlocks the vnode.

So from your description, the situation is reverse: you do need to unlock the vnode around the hook call.

[br]

Restore "unlock the vnode around the exec hook call"

[kib]

I only read the sys/kern bits.

sys/kern/vfs_vnops.c

2945

The check for != NULL is not needed.