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 4F0CDC36002 for ; Mon, 24 Mar 2025 21:25:56 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 10C3D10E419; Mon, 24 Mar 2025 21:25:56 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="I86lYH9Z"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2920B10E419; Mon, 24 Mar 2025 21:25:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1742851555; x=1774387555; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=yjhB+rVSzzbzVNiZ7SWxaEPpUuDhlUxtmSOFhIj4+gc=; b=I86lYH9ZPSGLtKiWvcq2xrCz/DCVHvskxeC0NENB2KxOLlIC0yyum36A nYarlr+1hjxXGeaP/onshbQ8nGZ3TF7gxhtgTsJMKV2DVlM16P2UJu3jA 35TpZMh2m+dyyOktlYni9SK5bHfjYePCEwLeYAO5PRYpuM5nhJqeiDcDH rR7QtohJKjfVU83awWk3ijV74hSzdmg38UcUBEOzzkiANt/8d9BNQ+uEJ zUjEwMvyky/qsWSwW2lF/6jPzJhvXwfkmR5pu+MoTa5dAXzyj0ZWxmXac /QT3tdC4ajKJZv7QnHttZ0f8MvhX3fFuwvW4ODRpxcdYn3US0DOOH+UnG w==; X-CSE-ConnectionGUID: m2myyvVuTaGU6IdQthgSpw== X-CSE-MsgGUID: Xz9BZyiRRFCHylAVD8p8uw== X-IronPort-AV: E=McAfee;i="6700,10204,11383"; a="47736043" X-IronPort-AV: E=Sophos;i="6.14,272,1736841600"; d="scan'208";a="47736043" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2025 14:25:55 -0700 X-CSE-ConnectionGUID: MUjQmz5WQgWJPzAZXGUy3Q== X-CSE-MsgGUID: xFOJZ+JhRlSRA1XKaiI2rg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,272,1736841600"; d="scan'208";a="124705703" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa007.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2025 14:25:52 -0700 Date: Mon, 24 Mar 2025 23:25:49 +0200 From: Raag Jadav To: "Cavitt, Jonathan" Cc: "intel-xe@lists.freedesktop.org" , "Gupta, saurabhg" , "Zuo, Alex" , "joonas.lahtinen@linux.intel.com" , "Brost, Matthew" , "Zhang, Jianxun" , "Lin, Shuicheng" , "dri-devel@lists.freedesktop.org" , "Wajdeczko, Michal" , "Mrozek, Michal" Subject: Re: [PATCH v10 5/5] drm/xe/xe_vm: Implement xe_vm_get_property_ioctl Message-ID: References: <20250320152616.74587-1-jonathan.cavitt@intel.com> <20250320152616.74587-6-jonathan.cavitt@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon, Mar 24, 2025 at 10:27:08PM +0530, Cavitt, Jonathan wrote: > From: Jadav, Raag > > On Thu, Mar 20, 2025 at 03:26:15PM +0000, Jonathan Cavitt wrote: > > > Add support for userspace to request a list of observed faults > > > from a specified VM. > > > > ... > > > > > +static int xe_vm_get_property_size(struct xe_vm *vm, u32 property) > > > +{ > > > + int size = -EINVAL; > > > > Mixing size and error codes is usually received with mixed feelings. > > > > > + > > > + switch (property) { > > > + case DRM_XE_VM_GET_PROPERTY_FAULTS: > > > + spin_lock(&vm->faults.lock); > > > + size = vm->faults.len * sizeof(struct xe_vm_fault); > > > > size_mul() and, > > [1] perhaps fill it up into the pointer passed by the caller here? > > "The pointer passed by the caller". You mean the args pointer? > > We'd still need to check that the args->size value is empty here before overwriting > it, and we'd also still need to return the size to the ioctl so we can verify it's > acceptable later in xe_vm_get_property_verify_size. > > Unless you want to merge those two processes together into here? The semantics are a bit fuzzy to me. Why do we have a single ioctl for two different processes? Shouldn't they be handled separately? Raag