/* * Copyright © 2015-2016 Intel Corporation * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the "Software"), * to deal in the Software without restriction, including without limitation * the rights to use, copy, modify, merge, publish, distribute, sublicense, * and/or sell copies of the Software, and to permit persons to whom the * Software is furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice (including the next * paragraph) shall be included in all copies or substantial portions of the * Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS * IN THE SOFTWARE. * * Authors: * Robert Bragg <[email protected]> */ /** * DOC: i915 Perf Overview * * Gen graphics supports a large number of performance counters that can help * driver and application developers understand and optimize their use of the * GPU. * * This i915 perf interface enables userspace to configure and open a file * descriptor representing a stream of GPU metrics which can then be read() as * a stream of sample records. * * The interface is particularly suited to exposing buffered metrics that are * captured by DMA from the GPU, unsynchronized with and unrelated to the CPU. * * Streams representing a single context are accessible to applications with a * corresponding drm file descriptor, such that OpenGL can use the interface * without special privileges. Access to system-wide metrics requires root * privileges by default, unless changed via the dev.i915.perf_event_paranoid * sysctl option. * */ /** * DOC: i915 Perf History and Comparison with Core Perf * * The interface was initially inspired by the core Perf infrastructure but * some notable differences are: * * i915 perf file descriptors represent a "stream" instead of an "event"; where * a perf event primarily corresponds to a single 64bit value, while a stream * might sample sets of tightly-coupled counters, depending on the * configuration. For example the Gen OA unit isn't designed to support * orthogonal configurations of individual counters; it's configured for a set * of related counters. Samples for an i915 perf stream capturing OA metrics * will include a set of counter values packed in a compact HW specific format. * The OA unit supports a number of different packing formats which can be * selected by the user opening the stream. Perf has support for grouping * events, but each event in the group is configured, validated and * authenticated individually with separate system calls. * * i915 perf stream configurations are provided as an array of u64 (key,value) * pairs, instead of a fixed struct with multiple miscellaneous config members, * interleaved with event-type specific members. * * i915 perf doesn't support exposing metrics via an mmap'd circular buffer. * The supported metrics are being written to memory by the GPU unsynchronized * with the CPU, using HW specific packing formats for counter sets. Sometimes * the constraints on HW configuration require reports to be filtered before it * would be acceptable to expose them to unprivileged applications - to hide * the metrics of other processes/contexts. For these use cases a read() based * interface is a good fit, and provides an opportunity to filter data as it * gets copied from the GPU mapped buffers to userspace buffers. * * * Issues hit with first prototype based on Core Perf * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * * The first prototype of this driver was based on the core perf * infrastructure, and while we did make that mostly work, with some changes to * perf, we found we were breaking or working around too many assumptions baked * into perf's currently cpu centric design. * * In the end we didn't see a clear benefit to making perf's implementation and * interface more complex by changing design assumptions while we knew we still * wouldn't be able to use any existing perf based userspace tools. * * Also considering the Gen specific nature of the Observability hardware and * how userspace will sometimes need to combine i915 perf OA metrics with * side-band OA data captured via MI_REPORT_PERF_COUNT commands; we're * expecting the interface to be used by a platform specific userspace such as * OpenGL or tools. This is to say; we aren't inherently missing out on having * a standard vendor/architecture agnostic interface by not using perf. * * * For posterity, in case we might re-visit trying to adapt core perf to be * better suited to exposing i915 metrics these were the main pain points we * hit: * * - The perf based OA PMU driver broke some significant design assumptions: * * Existing perf pmus are used for profiling work on a cpu and we were * introducing the idea of _IS_DEVICE pmus with different security * implications, the need to fake cpu-related data (such as user/kernel * registers) to fit with perf's current design, and adding _DEVICE records * as a way to forward device-specific status records. * * The OA unit writes reports of counters into a circular buffer, without * involvement from the CPU, making our PMU driver the first of a kind. * * Given the way we were periodically forward data from the GPU-mapped, OA * buffer to perf's buffer, those bursts of sample writes looked to perf like * we were sampling too fast and so we had to subvert its throttling checks. * * Perf supports groups of counters and allows those to be read via * transactions internally but transactions currently seem designed to be * explicitly initiated from the cpu (say in response to a userspace read()) * and while we could pull a report out of the OA buffer we can't * trigger a report from the cpu on demand. * * Related to being report based; the OA counters are configured in HW as a * set while perf generally expects counter configurations to be orthogonal. * Although counters can be associated with a group leader as they are * opened, there's no clear precedent for being able to provide group-wide * configuration attributes (for example we want to let userspace choose the * OA unit report format used to capture all counters in a set, or specify a * GPU context to filter metrics on). We avoided using perf's grouping * feature and forwarded OA reports to userspace via perf's 'raw' sample * field. This suited our userspace well considering how coupled the counters * are when dealing with normalizing. It would be inconvenient to split * counters up into separate events, only to require userspace to recombine * them. For Mesa it's also convenient to be forwarded raw, periodic reports * for combining with the side-band raw reports it captures using * MI_REPORT_PERF_COUNT commands. * * - As a side note on perf's grouping feature; there was also some concern * that using PERF_FORMAT_GROUP as a way to pack together counter values * would quite drastically inflate our sample sizes, which would likely * lower the effective sampling resolutions we could use when the available * memory bandwidth is limited. * * With the OA unit's report formats, counters are packed together as 32 * or 40bit values, with the largest report size being 256 bytes. * * PERF_FORMAT_GROUP values are 64bit, but there doesn't appear to be a * documented ordering to the values, implying PERF_FORMAT_ID must also be * used to add a 64bit ID before each value; giving 16 bytes per counter. * * Related to counter orthogonality; we can't time share the OA unit, while * event scheduling is a central design idea within perf for allowing * userspace to open + enable more events than can be configured in HW at any * one time. The OA unit is not designed to allow re-configuration while in * use. We can't reconfigure the OA unit without losing internal OA unit * state which we can't access explicitly to save and restore. Reconfiguring * the OA unit is also relatively slow, involving ~100 register writes. From * userspace Mesa also depends on a stable OA configuration when emitting * MI_REPORT_PERF_COUNT commands and importantly the OA unit can't be * disabled while there are outstanding MI_RPC commands lest we hang the * command streamer. * * The contents of sample records aren't extensible by device drivers (i.e. * the sample_type bits). As an example; Sourab Gupta had been looking to * attach GPU timestamps to our OA samples. We were shoehorning OA reports * into sample records by using the 'raw' field, but it's tricky to pack more * than one thing into this field because events/core.c currently only lets a * pmu give a single raw data pointer plus len which will be copied into the * ring buffer. To include more than the OA report we'd have to copy the * report into an intermediate larger buffer. I'd been considering allowing a * vector of data+len values to be specified for copying the raw data, but * it felt like a kludge to being using the raw field for this purpose. * * - It felt like our perf based PMU was making some technical compromises * just for the sake of using perf: * * perf_event_open() requires events to either relate to a pid or a specific * cpu core, while our device pmu related to neither. Events opened with a * pid will be automatically enabled/disabled according to the scheduling of * that process - so not appropriate for us. When an event is related to a * cpu id, perf ensures pmu methods will be invoked via an inter process * interrupt on that core. To avoid invasive changes our userspace opened OA * perf events for a specific cpu. This was workable but it meant the * majority of the OA driver ran in atomic context, including all OA report * forwarding, which wasn't really necessary in our case and seems to make * our locking requirements somewhat complex as we handled the interaction * with the rest of the i915 driver. */ #include <linux/anon_inodes.h> #include <linux/nospec.h> #include <linux/sizes.h> #include <linux/uuid.h> #include "gem/i915_gem_context.h" #include "gem/i915_gem_internal.h" #include "gt/intel_engine_pm.h" #include "gt/intel_engine_regs.h" #include "gt/intel_engine_user.h" #include "gt/intel_execlists_submission.h" #include "gt/intel_gpu_commands.h" #include "gt/intel_gt.h" #include "gt/intel_gt_clock_utils.h" #include "gt/intel_gt_mcr.h" #include "gt/intel_gt_print.h" #include "gt/intel_gt_regs.h" #include "gt/intel_lrc.h" #include "gt/intel_lrc_reg.h" #include "gt/intel_rc6.h" #include "gt/intel_ring.h" #include "gt/uc/intel_guc_slpc.h" #include "i915_drv.h" #include "i915_file_private.h" #include "i915_perf.h" #include "i915_perf_oa_regs.h" #include "i915_reg.h" /* HW requires this to be a power of two, between 128k and 16M, though driver * is currently generally designed assuming the largest 16M size is used such * that the overflow cases are unlikely in normal operation. */ #define OA_BUFFER_SIZE … #define OA_TAKEN(tail, head) … /** * DOC: OA Tail Pointer Race * * There's a HW race condition between OA unit tail pointer register updates and * writes to memory whereby the tail pointer can sometimes get ahead of what's * been written out to the OA buffer so far (in terms of what's visible to the * CPU). * * Although this can be observed explicitly while copying reports to userspace * by checking for a zeroed report-id field in tail reports, we want to account * for this earlier, as part of the oa_buffer_check_unlocked to avoid lots of * redundant read() attempts. * * We workaround this issue in oa_buffer_check_unlocked() by reading the reports * in the OA buffer, starting from the tail reported by the HW until we find a * report with its first 2 dwords not 0 meaning its previous report is * completely in memory and ready to be read. Those dwords are also set to 0 * once read and the whole buffer is cleared upon OA buffer initialization. The * first dword is the reason for this report while the second is the timestamp, * making the chances of having those 2 fields at 0 fairly unlikely. A more * detailed explanation is available in oa_buffer_check_unlocked(). * * Most of the implementation details for this workaround are in * oa_buffer_check_unlocked() and _append_oa_reports() * * Note for posterity: previously the driver used to define an effective tail * pointer that lagged the real pointer by a 'tail margin' measured in bytes * derived from %OA_TAIL_MARGIN_NSEC and the configured sampling frequency. * This was flawed considering that the OA unit may also automatically generate * non-periodic reports (such as on context switch) or the OA unit may be * enabled without any periodic sampling. */ #define OA_TAIL_MARGIN_NSEC … #define INVALID_TAIL_PTR … /* The default frequency for checking whether the OA unit has written new * reports to the circular OA buffer... */ #define DEFAULT_POLL_FREQUENCY_HZ … #define DEFAULT_POLL_PERIOD_NS … /* for sysctl proc_dointvec_minmax of dev.i915.perf_stream_paranoid */ static u32 i915_perf_stream_paranoid = …; /* The maximum exponent the hardware accepts is 63 (essentially it selects one * of the 64bit timestamp bits to trigger reports from) but there's currently * no known use case for sampling as infrequently as once per 47 thousand years. * * Since the timestamps included in OA reports are only 32bits it seems * reasonable to limit the OA exponent where it's still possible to account for * overflow in OA report timestamps. */ #define OA_EXPONENT_MAX … #define INVALID_CTX_ID … /* On Gen8+ automatically triggered OA reports include a 'reason' field... */ #define OAREPORT_REASON_MASK … #define OAREPORT_REASON_MASK_EXTENDED … #define OAREPORT_REASON_SHIFT … #define OAREPORT_REASON_TIMER … #define OAREPORT_REASON_CTX_SWITCH … #define OAREPORT_REASON_CLK_RATIO … #define HAS_MI_SET_PREDICATE(i915) … /* For sysctl proc_dointvec_minmax of i915_oa_max_sample_rate * * The highest sampling frequency we can theoretically program the OA unit * with is always half the timestamp frequency: E.g. 6.25Mhz for Haswell. * * Initialized just before we register the sysctl parameter. */ static int oa_sample_rate_hard_limit; /* Theoretically we can program the OA unit to sample every 160ns but don't * allow that by default unless root... * * The default threshold of 100000Hz is based on perf's similar * kernel.perf_event_max_sample_rate sysctl parameter. */ static u32 i915_oa_max_sample_rate = …; /* XXX: beware if future OA HW adds new report formats that the current * code assumes all reports have a power-of-two size and ~(size - 1) can * be used as a mask to align the OA tail pointer. */ static const struct i915_oa_format oa_formats[I915_OA_FORMAT_MAX] = …; static const u32 mtl_oa_base[] = …; #define SAMPLE_OA_REPORT … /** * struct perf_open_properties - for validated properties given to open a stream * @sample_flags: `DRM_I915_PERF_PROP_SAMPLE_*` properties are tracked as flags * @single_context: Whether a single or all gpu contexts should be monitored * @hold_preemption: Whether the preemption is disabled for the filtered * context * @ctx_handle: A gem ctx handle for use with @single_context * @metrics_set: An ID for an OA unit metric set advertised via sysfs * @oa_format: An OA unit HW report format * @oa_periodic: Whether to enable periodic OA unit sampling * @oa_period_exponent: The OA unit sampling period is derived from this * @engine: The engine (typically rcs0) being monitored by the OA unit * @has_sseu: Whether @sseu was specified by userspace * @sseu: internal SSEU configuration computed either from the userspace * specified configuration in the opening parameters or a default value * (see get_default_sseu_config()) * @poll_oa_period: The period in nanoseconds at which the CPU will check for OA * data availability * * As read_properties_unlocked() enumerates and validates the properties given * to open a stream of metrics the configuration is built up in the structure * which starts out zero initialized. */ struct perf_open_properties { … }; struct i915_oa_config_bo { … }; static struct ctl_table_header *sysctl_header; static enum hrtimer_restart oa_poll_check_timer_cb(struct hrtimer *hrtimer); void i915_oa_config_release(struct kref *ref) { … } struct i915_oa_config * i915_perf_get_oa_config(struct i915_perf *perf, int metrics_set) { … } static void free_oa_config_bo(struct i915_oa_config_bo *oa_bo) { … } static inline const struct i915_perf_regs *__oa_regs(struct i915_perf_stream *stream) { … } static u32 gen12_oa_hw_tail_read(struct i915_perf_stream *stream) { … } static u32 gen8_oa_hw_tail_read(struct i915_perf_stream *stream) { … } static u32 gen7_oa_hw_tail_read(struct i915_perf_stream *stream) { … } #define oa_report_header_64bit(__s) … static u64 oa_report_id(struct i915_perf_stream *stream, void *report) { … } static u64 oa_report_reason(struct i915_perf_stream *stream, void *report) { … } static void oa_report_id_clear(struct i915_perf_stream *stream, u32 *report) { … } static bool oa_report_ctx_invalid(struct i915_perf_stream *stream, void *report) { … } static u64 oa_timestamp(struct i915_perf_stream *stream, void *report) { … } static void oa_timestamp_clear(struct i915_perf_stream *stream, u32 *report) { … } static u32 oa_context_id(struct i915_perf_stream *stream, u32 *report) { … } static void oa_context_id_squash(struct i915_perf_stream *stream, u32 *report) { … } /** * oa_buffer_check_unlocked - check for data and update tail ptr state * @stream: i915 stream instance * * This is either called via fops (for blocking reads in user ctx) or the poll * check hrtimer (atomic ctx) to check the OA buffer tail pointer and check * if there is data available for userspace to read. * * This function is central to providing a workaround for the OA unit tail * pointer having a race with respect to what data is visible to the CPU. * It is responsible for reading tail pointers from the hardware and giving * the pointers time to 'age' before they are made available for reading. * (See description of OA_TAIL_MARGIN_NSEC above for further details.) * * Besides returning true when there is data available to read() this function * also updates the tail in the oa_buffer object. * * Note: It's safe to read OA config state here unlocked, assuming that this is * only called while the stream is enabled, while the global OA configuration * can't be modified. * * Returns: %true if the OA buffer contains data, else %false */ static bool oa_buffer_check_unlocked(struct i915_perf_stream *stream) { … } /** * append_oa_status - Appends a status record to a userspace read() buffer. * @stream: An i915-perf stream opened for OA metrics * @buf: destination buffer given by userspace * @count: the number of bytes userspace wants to read * @offset: (inout): the current position for writing into @buf * @type: The kind of status to report to userspace * * Writes a status record (such as `DRM_I915_PERF_RECORD_OA_REPORT_LOST`) * into the userspace read() buffer. * * The @buf @offset will only be updated on success. * * Returns: 0 on success, negative error code on failure. */ static int append_oa_status(struct i915_perf_stream *stream, char __user *buf, size_t count, size_t *offset, enum drm_i915_perf_record_type type) { … } /** * append_oa_sample - Copies single OA report into userspace read() buffer. * @stream: An i915-perf stream opened for OA metrics * @buf: destination buffer given by userspace * @count: the number of bytes userspace wants to read * @offset: (inout): the current position for writing into @buf * @report: A single OA report to (optionally) include as part of the sample * * The contents of a sample are configured through `DRM_I915_PERF_PROP_SAMPLE_*` * properties when opening a stream, tracked as `stream->sample_flags`. This * function copies the requested components of a single sample to the given * read() @buf. * * The @buf @offset will only be updated on success. * * Returns: 0 on success, negative error code on failure. */ static int append_oa_sample(struct i915_perf_stream *stream, char __user *buf, size_t count, size_t *offset, const u8 *report) { … } /** * gen8_append_oa_reports - Copies all buffered OA reports into * userspace read() buffer. * @stream: An i915-perf stream opened for OA metrics * @buf: destination buffer given by userspace * @count: the number of bytes userspace wants to read * @offset: (inout): the current position for writing into @buf * * Notably any error condition resulting in a short read (-%ENOSPC or * -%EFAULT) will be returned even though one or more records may * have been successfully copied. In this case it's up to the caller * to decide if the error should be squashed before returning to * userspace. * * Note: reports are consumed from the head, and appended to the * tail, so the tail chases the head?... If you think that's mad * and back-to-front you're not alone, but this follows the * Gen PRM naming convention. * * Returns: 0 on success, negative error code on failure. */ static int gen8_append_oa_reports(struct i915_perf_stream *stream, char __user *buf, size_t count, size_t *offset) { … } /** * gen8_oa_read - copy status records then buffered OA reports * @stream: An i915-perf stream opened for OA metrics * @buf: destination buffer given by userspace * @count: the number of bytes userspace wants to read * @offset: (inout): the current position for writing into @buf * * Checks OA unit status registers and if necessary appends corresponding * status records for userspace (such as for a buffer full condition) and then * initiate appending any buffered OA reports. * * Updates @offset according to the number of bytes successfully copied into * the userspace buffer. * * NB: some data may be successfully copied to the userspace buffer * even if an error is returned, and this is reflected in the * updated @offset. * * Returns: zero on success or a negative error code */ static int gen8_oa_read(struct i915_perf_stream *stream, char __user *buf, size_t count, size_t *offset) { … } /** * gen7_append_oa_reports - Copies all buffered OA reports into * userspace read() buffer. * @stream: An i915-perf stream opened for OA metrics * @buf: destination buffer given by userspace * @count: the number of bytes userspace wants to read * @offset: (inout): the current position for writing into @buf * * Notably any error condition resulting in a short read (-%ENOSPC or * -%EFAULT) will be returned even though one or more records may * have been successfully copied. In this case it's up to the caller * to decide if the error should be squashed before returning to * userspace. * * Note: reports are consumed from the head, and appended to the * tail, so the tail chases the head?... If you think that's mad * and back-to-front you're not alone, but this follows the * Gen PRM naming convention. * * Returns: 0 on success, negative error code on failure. */ static int gen7_append_oa_reports(struct i915_perf_stream *stream, char __user *buf, size_t count, size_t *offset) { … } /** * gen7_oa_read - copy status records then buffered OA reports * @stream: An i915-perf stream opened for OA metrics * @buf: destination buffer given by userspace * @count: the number of bytes userspace wants to read * @offset: (inout): the current position for writing into @buf * * Checks Gen 7 specific OA unit status registers and if necessary appends * corresponding status records for userspace (such as for a buffer full * condition) and then initiate appending any buffered OA reports. * * Updates @offset according to the number of bytes successfully copied into * the userspace buffer. * * Returns: zero on success or a negative error code */ static int gen7_oa_read(struct i915_perf_stream *stream, char __user *buf, size_t count, size_t *offset) { … } /** * i915_oa_wait_unlocked - handles blocking IO until OA data available * @stream: An i915-perf stream opened for OA metrics * * Called when userspace tries to read() from a blocking stream FD opened * for OA metrics. It waits until the hrtimer callback finds a non-empty * OA buffer and wakes us. * * Note: it's acceptable to have this return with some false positives * since any subsequent read handling will return -EAGAIN if there isn't * really data ready for userspace yet. * * Returns: zero on success or a negative error code */ static int i915_oa_wait_unlocked(struct i915_perf_stream *stream) { … } /** * i915_oa_poll_wait - call poll_wait() for an OA stream poll() * @stream: An i915-perf stream opened for OA metrics * @file: An i915 perf stream file * @wait: poll() state table * * For handling userspace polling on an i915 perf stream opened for OA metrics, * this starts a poll_wait with the wait queue that our hrtimer callback wakes * when it sees data ready to read in the circular OA buffer. */ static void i915_oa_poll_wait(struct i915_perf_stream *stream, struct file *file, poll_table *wait) { … } /** * i915_oa_read - just calls through to &i915_oa_ops->read * @stream: An i915-perf stream opened for OA metrics * @buf: destination buffer given by userspace * @count: the number of bytes userspace wants to read * @offset: (inout): the current position for writing into @buf * * Updates @offset according to the number of bytes successfully copied into * the userspace buffer. * * Returns: zero on success or a negative error code */ static int i915_oa_read(struct i915_perf_stream *stream, char __user *buf, size_t count, size_t *offset) { … } static struct intel_context *oa_pin_context(struct i915_perf_stream *stream) { … } static int __store_reg_to_mem(struct i915_request *rq, i915_reg_t reg, u32 ggtt_offset) { … } static int __read_reg(struct intel_context *ce, i915_reg_t reg, u32 ggtt_offset) { … } static int gen12_guc_sw_ctx_id(struct intel_context *ce, u32 *ctx_id) { … } /* * For execlist mode of submission, pick an unused context id * 0 - (NUM_CONTEXT_TAG -1) are used by other contexts * XXX_MAX_CONTEXT_HW_ID is used by idle context * * For GuC mode of submission read context id from the upper dword of the * EXECLIST_STATUS register. Note that we read this value only once and expect * that the value stays fixed for the entire OA use case. There are cases where * GuC KMD implementation may deregister a context to reuse it's context id, but * we prevent that from happening to the OA context by pinning it. */ static int gen12_get_render_context_id(struct i915_perf_stream *stream) { … } static bool oa_find_reg_in_lri(u32 *state, u32 reg, u32 *offset, u32 end) { … } static u32 oa_context_image_offset(struct intel_context *ce, u32 reg) { … } static int set_oa_ctx_ctrl_offset(struct intel_context *ce) { … } static bool engine_supports_mi_query(struct intel_engine_cs *engine) { … } /** * oa_get_render_ctx_id - determine and hold ctx hw id * @stream: An i915-perf stream opened for OA metrics * * Determine the render context hw id, and ensure it remains fixed for the * lifetime of the stream. This ensures that we don't have to worry about * updating the context ID in OACONTROL on the fly. * * Returns: zero on success or a negative error code */ static int oa_get_render_ctx_id(struct i915_perf_stream *stream) { … } /** * oa_put_render_ctx_id - counterpart to oa_get_render_ctx_id releases hold * @stream: An i915-perf stream opened for OA metrics * * In case anything needed doing to ensure the context HW ID would remain valid * for the lifetime of the stream, then that can be undone here. */ static void oa_put_render_ctx_id(struct i915_perf_stream *stream) { … } static void free_oa_buffer(struct i915_perf_stream *stream) { … } static void free_oa_configs(struct i915_perf_stream *stream) { … } static void free_noa_wait(struct i915_perf_stream *stream) { … } static bool engine_supports_oa(const struct intel_engine_cs *engine) { … } static bool engine_supports_oa_format(struct intel_engine_cs *engine, int type) { … } static void i915_oa_stream_destroy(struct i915_perf_stream *stream) { … } static void gen7_init_oa_buffer(struct i915_perf_stream *stream) { … } static void gen8_init_oa_buffer(struct i915_perf_stream *stream) { … } static void gen12_init_oa_buffer(struct i915_perf_stream *stream) { … } static int alloc_oa_buffer(struct i915_perf_stream *stream) { … } static u32 *save_restore_register(struct i915_perf_stream *stream, u32 *cs, bool save, i915_reg_t reg, u32 offset, u32 dword_count) { … } static int alloc_noa_wait(struct i915_perf_stream *stream) { … } static u32 *write_cs_mi_lri(u32 *cs, const struct i915_oa_reg *reg_data, u32 n_regs) { … } static int num_lri_dwords(int num_regs) { … } static struct i915_oa_config_bo * alloc_oa_config_buffer(struct i915_perf_stream *stream, struct i915_oa_config *oa_config) { … } static struct i915_vma * get_oa_vma(struct i915_perf_stream *stream, struct i915_oa_config *oa_config) { … } static int emit_oa_config(struct i915_perf_stream *stream, struct i915_oa_config *oa_config, struct intel_context *ce, struct i915_active *active) { … } static struct intel_context *oa_context(struct i915_perf_stream *stream) { … } static int hsw_enable_metric_set(struct i915_perf_stream *stream, struct i915_active *active) { … } static void hsw_disable_metric_set(struct i915_perf_stream *stream) { … } static u32 oa_config_flex_reg(const struct i915_oa_config *oa_config, i915_reg_t reg) { … } /* * NB: It must always remain pointer safe to run this even if the OA unit * has been disabled. * * It's fine to put out-of-date values into these per-context registers * in the case that the OA unit has been disabled. */ static void gen8_update_reg_state_unlocked(const struct intel_context *ce, const struct i915_perf_stream *stream) { … } struct flex { … }; static int gen8_store_flex(struct i915_request *rq, struct intel_context *ce, const struct flex *flex, unsigned int count) { … } static int gen8_load_flex(struct i915_request *rq, struct intel_context *ce, const struct flex *flex, unsigned int count) { … } static int gen8_modify_context(struct intel_context *ce, const struct flex *flex, unsigned int count) { … } static int gen8_modify_self(struct intel_context *ce, const struct flex *flex, unsigned int count, struct i915_active *active) { … } static int gen8_configure_context(struct i915_perf_stream *stream, struct i915_gem_context *ctx, struct flex *flex, unsigned int count) { … } static int gen12_configure_oar_context(struct i915_perf_stream *stream, struct i915_active *active) { … } /* * Manages updating the per-context aspects of the OA stream * configuration across all contexts. * * The awkward consideration here is that OACTXCONTROL controls the * exponent for periodic sampling which is primarily used for system * wide profiling where we'd like a consistent sampling period even in * the face of context switches. * * Our approach of updating the register state context (as opposed to * say using a workaround batch buffer) ensures that the hardware * won't automatically reload an out-of-date timer exponent even * transiently before a WA BB could be parsed. * * This function needs to: * - Ensure the currently running context's per-context OA state is * updated * - Ensure that all existing contexts will have the correct per-context * OA state if they are scheduled for use. * - Ensure any new contexts will be initialized with the correct * per-context OA state. * * Note: it's only the RCS/Render context that has any OA state. * Note: the first flex register passed must always be R_PWR_CLK_STATE */ static int oa_configure_all_contexts(struct i915_perf_stream *stream, struct flex *regs, size_t num_regs, struct i915_active *active) { … } static int lrc_configure_all_contexts(struct i915_perf_stream *stream, const struct i915_oa_config *oa_config, struct i915_active *active) { … } static int gen8_enable_metric_set(struct i915_perf_stream *stream, struct i915_active *active) { … } static u32 oag_report_ctx_switches(const struct i915_perf_stream *stream) { … } static int gen12_enable_metric_set(struct i915_perf_stream *stream, struct i915_active *active) { … } static void gen8_disable_metric_set(struct i915_perf_stream *stream) { … } static void gen11_disable_metric_set(struct i915_perf_stream *stream) { … } static void gen12_disable_metric_set(struct i915_perf_stream *stream) { … } static void gen7_oa_enable(struct i915_perf_stream *stream) { … } static void gen8_oa_enable(struct i915_perf_stream *stream) { … } static void gen12_oa_enable(struct i915_perf_stream *stream) { … } /** * i915_oa_stream_enable - handle `I915_PERF_IOCTL_ENABLE` for OA stream * @stream: An i915 perf stream opened for OA metrics * * [Re]enables hardware periodic sampling according to the period configured * when opening the stream. This also starts a hrtimer that will periodically * check for data in the circular OA buffer for notifying userspace (e.g. * during a read() or poll()). */ static void i915_oa_stream_enable(struct i915_perf_stream *stream) { … } static void gen7_oa_disable(struct i915_perf_stream *stream) { … } static void gen8_oa_disable(struct i915_perf_stream *stream) { … } static void gen12_oa_disable(struct i915_perf_stream *stream) { … } /** * i915_oa_stream_disable - handle `I915_PERF_IOCTL_DISABLE` for OA stream * @stream: An i915 perf stream opened for OA metrics * * Stops the OA unit from periodically writing counter reports into the * circular OA buffer. This also stops the hrtimer that periodically checks for * data in the circular OA buffer, for notifying userspace. */ static void i915_oa_stream_disable(struct i915_perf_stream *stream) { … } static const struct i915_perf_stream_ops i915_oa_stream_ops = …; static int i915_perf_stream_enable_sync(struct i915_perf_stream *stream) { … } static void get_default_sseu_config(struct intel_sseu *out_sseu, struct intel_engine_cs *engine) { … } static int get_sseu_config(struct intel_sseu *out_sseu, struct intel_engine_cs *engine, const struct drm_i915_gem_context_param_sseu *drm_sseu) { … } /* * OA timestamp frequency = CS timestamp frequency in most platforms. On some * platforms OA unit ignores the CTC_SHIFT and the 2 timestamps differ. In such * cases, return the adjusted CS timestamp frequency to the user. */ u32 i915_perf_oa_timestamp_frequency(struct drm_i915_private *i915) { … } /** * i915_oa_stream_init - validate combined props for OA stream and init * @stream: An i915 perf stream * @param: The open parameters passed to `DRM_I915_PERF_OPEN` * @props: The property state that configures stream (individually validated) * * While read_properties_unlocked() validates properties in isolation it * doesn't ensure that the combination necessarily makes sense. * * At this point it has been determined that userspace wants a stream of * OA metrics, but still we need to further validate the combined * properties are OK. * * If the configuration makes sense then we can allocate memory for * a circular OA buffer and apply the requested metric set configuration. * * Returns: zero on success or a negative error code. */ static int i915_oa_stream_init(struct i915_perf_stream *stream, struct drm_i915_perf_open_param *param, struct perf_open_properties *props) { … } void i915_oa_init_reg_state(const struct intel_context *ce, const struct intel_engine_cs *engine) { … } /** * i915_perf_read - handles read() FOP for i915 perf stream FDs * @file: An i915 perf stream file * @buf: destination buffer given by userspace * @count: the number of bytes userspace wants to read * @ppos: (inout) file seek position (unused) * * The entry point for handling a read() on a stream file descriptor from * userspace. Most of the work is left to the i915_perf_read_locked() and * &i915_perf_stream_ops->read but to save having stream implementations (of * which we might have multiple later) we handle blocking read here. * * We can also consistently treat trying to read from a disabled stream * as an IO error so implementations can assume the stream is enabled * while reading. * * Returns: The number of bytes copied or a negative error code on failure. */ static ssize_t i915_perf_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { … } static enum hrtimer_restart oa_poll_check_timer_cb(struct hrtimer *hrtimer) { … } /** * i915_perf_poll_locked - poll_wait() with a suitable wait queue for stream * @stream: An i915 perf stream * @file: An i915 perf stream file * @wait: poll() state table * * For handling userspace polling on an i915 perf stream, this calls through to * &i915_perf_stream_ops->poll_wait to call poll_wait() with a wait queue that * will be woken for new stream data. * * Returns: any poll events that are ready without sleeping */ static __poll_t i915_perf_poll_locked(struct i915_perf_stream *stream, struct file *file, poll_table *wait) { … } /** * i915_perf_poll - call poll_wait() with a suitable wait queue for stream * @file: An i915 perf stream file * @wait: poll() state table * * For handling userspace polling on an i915 perf stream, this ensures * poll_wait() gets called with a wait queue that will be woken for new stream * data. * * Note: Implementation deferred to i915_perf_poll_locked() * * Returns: any poll events that are ready without sleeping */ static __poll_t i915_perf_poll(struct file *file, poll_table *wait) { … } /** * i915_perf_enable_locked - handle `I915_PERF_IOCTL_ENABLE` ioctl * @stream: A disabled i915 perf stream * * [Re]enables the associated capture of data for this stream. * * If a stream was previously enabled then there's currently no intention * to provide userspace any guarantee about the preservation of previously * buffered data. */ static void i915_perf_enable_locked(struct i915_perf_stream *stream) { … } /** * i915_perf_disable_locked - handle `I915_PERF_IOCTL_DISABLE` ioctl * @stream: An enabled i915 perf stream * * Disables the associated capture of data for this stream. * * The intention is that disabling an re-enabling a stream will ideally be * cheaper than destroying and re-opening a stream with the same configuration, * though there are no formal guarantees about what state or buffered data * must be retained between disabling and re-enabling a stream. * * Note: while a stream is disabled it's considered an error for userspace * to attempt to read from the stream (-EIO). */ static void i915_perf_disable_locked(struct i915_perf_stream *stream) { … } static long i915_perf_config_locked(struct i915_perf_stream *stream, unsigned long metrics_set) { … } /** * i915_perf_ioctl_locked - support ioctl() usage with i915 perf stream FDs * @stream: An i915 perf stream * @cmd: the ioctl request * @arg: the ioctl data * * Returns: zero on success or a negative error code. Returns -EINVAL for * an unknown ioctl request. */ static long i915_perf_ioctl_locked(struct i915_perf_stream *stream, unsigned int cmd, unsigned long arg) { … } /** * i915_perf_ioctl - support ioctl() usage with i915 perf stream FDs * @file: An i915 perf stream file * @cmd: the ioctl request * @arg: the ioctl data * * Implementation deferred to i915_perf_ioctl_locked(). * * Returns: zero on success or a negative error code. Returns -EINVAL for * an unknown ioctl request. */ static long i915_perf_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { … } /** * i915_perf_destroy_locked - destroy an i915 perf stream * @stream: An i915 perf stream * * Frees all resources associated with the given i915 perf @stream, disabling * any associated data capture in the process. * * Note: The >->perf.lock mutex has been taken to serialize * with any non-file-operation driver hooks. */ static void i915_perf_destroy_locked(struct i915_perf_stream *stream) { … } /** * i915_perf_release - handles userspace close() of a stream file * @inode: anonymous inode associated with file * @file: An i915 perf stream file * * Cleans up any resources associated with an open i915 perf stream file. * * NB: close() can't really fail from the userspace point of view. * * Returns: zero on success or a negative error code. */ static int i915_perf_release(struct inode *inode, struct file *file) { … } static const struct file_operations fops = …; /** * i915_perf_open_ioctl_locked - DRM ioctl() for userspace to open a stream FD * @perf: i915 perf instance * @param: The open parameters passed to 'DRM_I915_PERF_OPEN` * @props: individually validated u64 property value pairs * @file: drm file * * See i915_perf_ioctl_open() for interface details. * * Implements further stream config validation and stream initialization on * behalf of i915_perf_open_ioctl() with the >->perf.lock mutex * taken to serialize with any non-file-operation driver hooks. * * Note: at this point the @props have only been validated in isolation and * it's still necessary to validate that the combination of properties makes * sense. * * In the case where userspace is interested in OA unit metrics then further * config validation and stream initialization details will be handled by * i915_oa_stream_init(). The code here should only validate config state that * will be relevant to all stream types / backends. * * Returns: zero on success or a negative error code. */ static int i915_perf_open_ioctl_locked(struct i915_perf *perf, struct drm_i915_perf_open_param *param, struct perf_open_properties *props, struct drm_file *file) { … } static u64 oa_exponent_to_ns(struct i915_perf *perf, int exponent) { … } static __always_inline bool oa_format_valid(struct i915_perf *perf, enum drm_i915_oa_format format) { … } static __always_inline void oa_format_add(struct i915_perf *perf, enum drm_i915_oa_format format) { … } /** * read_properties_unlocked - validate + copy userspace stream open properties * @perf: i915 perf instance * @uprops: The array of u64 key value pairs given by userspace * @n_props: The number of key value pairs expected in @uprops * @props: The stream configuration built up while validating properties * * Note this function only validates properties in isolation it doesn't * validate that the combination of properties makes sense or that all * properties necessary for a particular kind of stream have been set. * * Note that there currently aren't any ordering requirements for properties so * we shouldn't validate or assume anything about ordering here. This doesn't * rule out defining new properties with ordering requirements in the future. */ static int read_properties_unlocked(struct i915_perf *perf, u64 __user *uprops, u32 n_props, struct perf_open_properties *props) { … } /** * i915_perf_open_ioctl - DRM ioctl() for userspace to open a stream FD * @dev: drm device * @data: ioctl data copied from userspace (unvalidated) * @file: drm file * * Validates the stream open parameters given by userspace including flags * and an array of u64 key, value pair properties. * * Very little is assumed up front about the nature of the stream being * opened (for instance we don't assume it's for periodic OA unit metrics). An * i915-perf stream is expected to be a suitable interface for other forms of * buffered data written by the GPU besides periodic OA metrics. * * Note we copy the properties from userspace outside of the i915 perf * mutex to avoid an awkward lockdep with mmap_lock. * * Most of the implementation details are handled by * i915_perf_open_ioctl_locked() after taking the >->perf.lock * mutex for serializing with any non-file-operation driver hooks. * * Return: A newly opened i915 Perf stream file descriptor or negative * error code on failure. */ int i915_perf_open_ioctl(struct drm_device *dev, void *data, struct drm_file *file) { … } /** * i915_perf_register - exposes i915-perf to userspace * @i915: i915 device instance * * In particular OA metric sets are advertised under a sysfs metrics/ * directory allowing userspace to enumerate valid IDs that can be * used to open an i915-perf stream. */ void i915_perf_register(struct drm_i915_private *i915) { … } /** * i915_perf_unregister - hide i915-perf from userspace * @i915: i915 device instance * * i915-perf state cleanup is split up into an 'unregister' and * 'deinit' phase where the interface is first hidden from * userspace by i915_perf_unregister() before cleaning up * remaining state in i915_perf_fini(). */ void i915_perf_unregister(struct drm_i915_private *i915) { … } static bool gen8_is_valid_flex_addr(struct i915_perf *perf, u32 addr) { … } static bool reg_in_range_table(u32 addr, const struct i915_range *table) { … } #define REG_EQUAL(addr, mmio) … static const struct i915_range gen7_oa_b_counters[] = …; static const struct i915_range gen12_oa_b_counters[] = …; static const struct i915_range mtl_oam_b_counters[] = …; static const struct i915_range xehp_oa_b_counters[] = …; static const struct i915_range gen7_oa_mux_regs[] = …; static const struct i915_range hsw_oa_mux_regs[] = …; static const struct i915_range chv_oa_mux_regs[] = …; static const struct i915_range gen8_oa_mux_regs[] = …; static const struct i915_range gen11_oa_mux_regs[] = …; static const struct i915_range gen12_oa_mux_regs[] = …; /* * Ref: 14010536224: * 0x20cc is repurposed on MTL, so use a separate array for MTL. */ static const struct i915_range mtl_oa_mux_regs[] = …; static bool gen7_is_valid_b_counter_addr(struct i915_perf *perf, u32 addr) { … } static bool gen8_is_valid_mux_addr(struct i915_perf *perf, u32 addr) { … } static bool gen11_is_valid_mux_addr(struct i915_perf *perf, u32 addr) { … } static bool hsw_is_valid_mux_addr(struct i915_perf *perf, u32 addr) { … } static bool chv_is_valid_mux_addr(struct i915_perf *perf, u32 addr) { … } static bool gen12_is_valid_b_counter_addr(struct i915_perf *perf, u32 addr) { … } static bool mtl_is_valid_oam_b_counter_addr(struct i915_perf *perf, u32 addr) { … } static bool xehp_is_valid_b_counter_addr(struct i915_perf *perf, u32 addr) { … } static bool gen12_is_valid_mux_addr(struct i915_perf *perf, u32 addr) { … } static u32 mask_reg_value(u32 reg, u32 val) { … } static struct i915_oa_reg *alloc_oa_regs(struct i915_perf *perf, bool (*is_valid)(struct i915_perf *perf, u32 addr), u32 __user *regs, u32 n_regs) { … } static ssize_t show_dynamic_id(struct kobject *kobj, struct kobj_attribute *attr, char *buf) { … } static int create_dynamic_oa_sysfs_entry(struct i915_perf *perf, struct i915_oa_config *oa_config) { … } /** * i915_perf_add_config_ioctl - DRM ioctl() for userspace to add a new OA config * @dev: drm device * @data: ioctl data (pointer to struct drm_i915_perf_oa_config) copied from * userspace (unvalidated) * @file: drm file * * Validates the submitted OA register to be saved into a new OA config that * can then be used for programming the OA unit and its NOA network. * * Returns: A new allocated config number to be used with the perf open ioctl * or a negative error code on failure. */ int i915_perf_add_config_ioctl(struct drm_device *dev, void *data, struct drm_file *file) { … } /** * i915_perf_remove_config_ioctl - DRM ioctl() for userspace to remove an OA config * @dev: drm device * @data: ioctl data (pointer to u64 integer) copied from userspace * @file: drm file * * Configs can be removed while being used, the will stop appearing in sysfs * and their content will be freed when the stream using the config is closed. * * Returns: 0 on success or a negative error code on failure. */ int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data, struct drm_file *file) { … } static struct ctl_table oa_table[] = …; static u32 num_perf_groups_per_gt(struct intel_gt *gt) { … } static u32 __oam_engine_group(struct intel_engine_cs *engine) { … } static u32 __oa_engine_group(struct intel_engine_cs *engine) { … } static struct i915_perf_regs __oam_regs(u32 base) { … } static struct i915_perf_regs __oag_regs(void) { … } static void oa_init_groups(struct intel_gt *gt) { … } static int oa_init_gt(struct intel_gt *gt) { … } static int oa_init_engine_groups(struct i915_perf *perf) { … } static void oa_init_supported_formats(struct i915_perf *perf) { … } static void i915_perf_init_info(struct drm_i915_private *i915) { … } /** * i915_perf_init - initialize i915-perf state on module bind * @i915: i915 device instance * * Initializes i915-perf state without exposing anything to userspace. * * Note: i915-perf initialization is split into an 'init' and 'register' * phase with the i915_perf_register() exposing state to userspace. */ int i915_perf_init(struct drm_i915_private *i915) { … } static int destroy_config(int id, void *p, void *data) { … } int i915_perf_sysctl_register(void) { … } void i915_perf_sysctl_unregister(void) { … } /** * i915_perf_fini - Counter part to i915_perf_init() * @i915: i915 device instance */ void i915_perf_fini(struct drm_i915_private *i915) { … } /** * i915_perf_ioctl_version - Version of the i915-perf subsystem * @i915: The i915 device * * This version number is used by userspace to detect available features. */ int i915_perf_ioctl_version(struct drm_i915_private *i915) { … } #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST) #include "selftests/i915_perf.c" #endif
Codebase Browser
linux