Table of Contents

Introduction

Roadmap objectives described in this documents are related mostly to wperf-driver, a KMDF (Kernel Mode Driver) which is a part of WindowsPerf project.

We are consistently developing and improving Kernel driver throughout the project. We are now ready to implement major improvements and fixes to existing driver.

Components

List of components referenced in this document:

• https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/tree/main/wperf-driver?ref_type=heads.

• https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/tree/main/wperf?ref_type=heads.

• https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/tree/main/wperf-devgen?ref_type=heads.

Roadmap

Note: roadmap chapters are NOT sorted in chronological or priority order order! This will be done when we start planning and create fixed timeline in JIRA.

Device Tree Feature (aka DT)

Goal: Split current monolithic wperf-driver (Kernel driver) into small, independent drivers with well defined Kernel ↔︎ User space protocol.

Note: Please note that this is draft, we may want to split drivers in a different way e.g. core PMU and uncore PMU as two separate drivers (not three like its stated below).

• Split current wperf-driver into three separate independent drivers (core, DSU and DMC driver).

• Introduce “driver type” for WindowsPerf drivers in DT.

  • “core PMU” driver type to support vanilla Arm PMUs.

  • “uncore PMU” driver(s):

    • Introduce “DSU” driver type to support uncore PMU counting.

    • Introduce “DMC” driver type to support Dynamic Memory Controllers.

• Introduce driver “template” for each type.

• Move current wperf-driver core PMU and uncore PMU implementations under new driver types.

• Add DT driver enumeration to user space.

  • Adapt wperf and drivers to communicate with N drivers installed.

  • Adapt wperf-devgen to support new driver types enumeration and installation / removal.

Driver Resource Acquisition

This chapter mostly describes work planned in epic WPERF-25 - Getting issue details... STATUS .

Goal: to revisit and expand on existing epic. Objectives for this workload will include:

• Check if wperf-driver correctly loads and unloads its resources.

• Implement PMU (driver) resource acquisition lock and release.

  • wperf-driver should be able to release PMU resources if they are not used by user space application wperf.

• Make sure only one user space application can access wperf-driver’s PMU resources.

• Introduce “busy” state to wperf-driver.

  • All wperf user space instances should be able to tell if driver is currently “in use” by another wperf instance(s).

  • Note: this will be extended in Device Tree feature. Each driver will be able to communicate user space if resource is ready, acquired and ready to use (other “states” may be added later).

    • In DT architecture there will be N drivers, user space can acquire driver(s) leaving other driver for users' disposal. Currently if user space is for example counting core, other wperf instance can’t use DMC resource.

unCore PMU Driver Improvements

Current wperf-driver implementation is not auto detecting unCore PMU.

• Ampere Altra is using CMN-600 (system cache and interconnect) and DMC-620 (memory controller).

• Both could be probed using ACPI. Windows kernel has a built-in generic ACPI driver, and has detected CMN-600 and DMC-620:

  • Configuration registers have been memory mapped:

• Currently wperf user space application is using cfgmgr32.lib to detect uncore PMU resources. We should be able to move this to the driver side.

Driver Verifier

Driver Verifier monitors Windows kernel-mode drivers and graphics drivers to detect illegal function calls or actions that might corrupt the system. Driver Verifier can subject Windows drivers to a variety of stresses and tests to find improper behavior. See WPERF-282 - Getting issue details... STATUS .

Goal: run DV against current wperf-driver code

• Isolate and fix most critical findings from DV.

• Other (sort out other issues that may influence driver’s performance or stability).

wperf-devgen

Project wperf-devgen is a help utility to install the WindowsPerf Driver using the Software Device API.

Goal: improve current implementation of wperf-devgen.

• Code review of current solution.

• Add bulletproof install / remove / driver status functionality to wperf-devgen.

  • Note: in the future we will introduce Device Tree feature.

    • This will expand on wperf-devgen tool which should be able to manage set of WindowsPerf drivers.

Driver Testing Framework

Current project lacks wperf-driver testing infrastructure. WindowsPerf DTF should introduce simple smoke test / canary test framework we can use to verify driver during development and CI/CD testing. Current

Goal: introduce test framework compatible with current testing Python infrastructure.

• Add stress tests for wperf-driver features.

• Add stress test for driver load/unload functionality.

• Add stress test for driver install / remove functionality.

• Add tests and checks based on Driver Verifier

• Add tests for functionality we’ve added with beta branch https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/tree/beta?ref_type=heads.

Vulnerability analysis

The current driver never went through any sort of analysis of possible security vulnerabilities. We need to evaluate and solve all issues.

Goal: Evaluate and report possible driver vulnerabilities and solve them.

IOCTRL

• Check and refactor / evaluate IOCTRL strategy.

Misc

• Evaluate all DPCs and interrupt handlers. We want to make sure each DPC and interrupt handle is efficient.

  • See example issue WPERF-451 - Getting issue details... STATUS where we use few events to count. We want to make sure all interrupts are being handled so that user space can collect from driver accurate sapling data.

• Evaluate changes done in https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/tree/beta?ref_type=heads.

  • Add testing when one or more GPCs are not available.

• Functions inside device.c are too big and complex, we want all this to be broken down and become more easily maneageable.