X-Git-Url: https://vilimpoc.org/repos/dotfiles/blobdiff_plain/0aec6243fab52a10889bd5052a4cf1496be80b0d..5c01c42c07a9003596daec75d22f779e743f8e55:/README.md

diff --git a/README.md b/README.md
index 421e1fe..1bdadca 100644
--- a/README.md
+++ b/README.md
@@ -137,6 +137,32 @@ throwaway VM reachable from a Linux host.
   msstore`); it is not installed here because the Store source needs an
   interactive, signed-in session, which the unattended elevated half does not
   have.
+- **Intel VTune Profiler is reported, not installed.** The elevated half prints
+  whether it is on the box, its version, and the path to `vtune.exe`; if it is
+  missing it prints the download page instead (and says so if the CPU is not
+  Intel). Automating the install is not worth it here: the offline installer is a
+  ~750 MB download from a URL carrying a per-release GUID with no "latest"
+  redirect behind it, so every new build would mean editing a hard-coded link,
+  and it is only worth having on Intel silicon since hardware event-based
+  sampling reads Intel PMU counters. It does install unattended if you want it
+  scripted elsewhere:
+
+  ```powershell
+  intel-vtune-<version>_offline.exe -a --silent --cli --eula accept
+  ```
+
+  **Running it needs no elevation, but hardware sampling does.** A standard user
+  gets the User-Mode Sampling analyses — `vtune -collect hotspots` and threading
+  — and they work: measured here, collection and finalization, exit 0. Hardware
+  event-based sampling (`uarch-exploration`, `memory-access`, `hotspots -knob
+  sampling-mode=hw`) wants administrator, and VTune says so in a warning at the
+  top of every unelevated run. Note the failure it actually gives is *"cannot
+  recognize the processor"*, which reads like a hardware problem and is not one:
+  the drivers (`sepdrv5`, `sepdal`, `vtss`) are installed and running, and VTune
+  identifies the PMU through them. Unlike ETW there is no group to join for this
+  — the Linux driver can be handed to a `vtune` group, but on Windows the
+  documented answer is to run as administrator.
+
 - **Tracing without a UAC prompt.** `xperf` and `wpr` fail for a standard user in
   two different ways, because two different things are missing:
 
@@ -178,8 +204,11 @@ throwaway VM reachable from a Linux host.
   Two consequences worth knowing. A privilege and a group membership are both
   read into the access token **at logon**, so the account must sign out and back
   in for 1 and 2 — any new logon does it, and an `ssh` login into the box is the
-  quick way to check without dropping the desktop. (The ACE in 3 is machine
-  state, read when a session starts, so it applies immediately.) And this only
+  quick way to check without dropping the desktop. The ACE in 3 is machine state
+  instead, and a logon does nothing for it: ETW reads these descriptors into a
+  cache, so it takes a **reboot** — with the ACE written and readable, `xperf -on
+  base` was still denied from a fresh shell on the running system. Plan on both
+  on a first run. And this only
   helps a **non-admin** account: UAC hands an administrator a filtered token
   carrying just five harmless privileges, so an admin's ordinary shell still
   cannot trace however the policy reads. Verify from the target account,