From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5191FFCC07D for ; Fri, 6 Mar 2026 21:30:45 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 08CAF10E40D; Fri, 6 Mar 2026 21:30:45 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="NslTUJnI"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) by gabe.freedesktop.org (Postfix) with ESMTPS id 23BB810E3FA; Fri, 6 Mar 2026 21:30:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772832643; x=1804368643; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=5VGVb44S4Jl8pGAPgj80nmy3APxdU9AwqSy7FuPWvbQ=; b=NslTUJnIbs1NHhsdUaXgvo53P8pGJ2qtucU733ioMfbuONesnLbaern7 tfhjTnMN4fphWqYYrJsJuTx5QPX1SNP8dSOHJPThmX8lxsAO7VBMeNlkS EB4LocQIPy6svyG+EOTbuSK48aJROzYfuArEBAwlLOxWCYzkzzqPOPUUL XSsRXdc4CGq8tTopDZz/loEU0pl6B+ezCVAC1ROUK893OlJE9fVE89ywz 5LZunap/WFF6cVoDQ7sPktUI/ViFODxeEY/v5NryJANzjxtEmQrDjhvM4 6m9JEzEHjqCl/2Uwikjw6OVEbEkwUPGDf4uu0PRB/kucmDZBV1PGRqR3Z A==; X-CSE-ConnectionGUID: PlvCQ/cnTdyL9E/ZyYPu2A== X-CSE-MsgGUID: BtkP8Ue6TfWQRMtYsm1U4A== X-IronPort-AV: E=McAfee;i="6800,10657,11721"; a="61520057" X-IronPort-AV: E=Sophos;i="6.23,105,1770624000"; d="scan'208";a="61520057" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Mar 2026 13:30:43 -0800 X-CSE-ConnectionGUID: BYj3klkDTS2wlqPayerSRA== X-CSE-MsgGUID: e8LlaqTHSl+CCgdO11fRNQ== X-ExtLoop1: 1 Received: from rmigue1x-mobl.amr.corp.intel.com (HELO adixit-MOBL3.intel.com) ([10.125.38.160]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Mar 2026 13:30:42 -0800 Date: Fri, 06 Mar 2026 13:30:41 -0800 Message-ID: <87o6l0sl1a.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Rodrigo Vivi Cc: "Souza, Jose" , =?ISO-8859-2?Q?Micha=B3?= Winiarski , Michal Wajdeczko , "intel-xe@lists.freedesktop.org" , "K V P, Satyanarayana" , "dri-devel@lists.freedesktop.org" , "Brost, Matthew" , "thomas.hellstrom@linux.intel.com" , "Piorkowski, Piotr" , "Dunajski, Bartosz" , "Wajdeczko, Michal" Subject: Re: [RFC v5 1/1] drm/xe/pf: Restrict device query responses in admin-only PF mode In-Reply-To: References: <20260227120702.3651913-3-satyanarayana.k.v.p@intel.com> <20260227120702.3651913-4-satyanarayana.k.v.p@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Fri, 06 Mar 2026 06:00:02 -0800, Rodrigo Vivi wrote: > > On Tue, Mar 03, 2026 at 08:39:56PM +0000, Souza, Jose wrote: > > On Fri, 2026-02-27 at 12:07 +0000, Satyanarayana K V P wrote: > > > When a PF is configured in admin-only mode, it is intended for > > > management > > > only and must not expose workload-facing capabilities to userspace. > > > > > > Limit the exposed ioctl set in admin-only PF mode to XE_DEVICE_QUERY, > > > and > > > suppress capability-bearing query payloads so userspace cannot > > > discover > > > execution-related device details in this mode. > > > > Mesa MR: > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40206 > > Looking to this patch I got myself wondering if query.size == 0 is > long-term proof... I mean, if we need to get some OA/RAS/telemetry > kind of API that end up needing some kind of query information.... > > Michals, thoughts on this? > > I know, I know, this solution is indeed much better than my > proposal of no ioctl exposed. But I mean, since we are taking > this path and allowing some ioctl. Shouldn't we prepare at least > the query for that and then only limiting the number of engines > and memory regions to zero? I think UMD's should handle both these cases, either: 1. The returned query size is 0, so there is no further information, which can only mean nothing is supported (engine, memory region counts are all 0) 2. Or, returned query size is non-zero but engine or memory region counts returned are 0. And then KMD can implement either (or switch between the two later) as needed? Also, there were some questions about supporting OA in the admin-only-pf. Here are some high level points about this: * OA/EUSTALL is not supported in VF's in current products, this might change in the future * OA/EUSTALL in admin-only-pf can be used to profile global counts across VF's * OA/EUSTALL themselves don't allow workload submission etc. They only allow reading profiling data from HW * OA/EUSTALL in admin-only-pf will need the observation ioctl to be supported. Also, some other query ioctls such as hw configuration, topology, frequency will be needed to make sense of OA/EUSTALL data. Thanks. -- Ashutosh