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 ABB65EB64D8 for ; Fri, 16 Jun 2023 06:52:20 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 22B1C10E090; Fri, 16 Jun 2023 06:52:20 +0000 (UTC) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8B42710E090 for ; Fri, 16 Jun 2023 06:52:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686898337; x=1718434337; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=G0xzJnQCpkoxOsXc7eo3qgFsIufFNVRds2dtcskuq80=; b=X4lA6rLna5I0kR1lVubSpMGvp8bRHK7ineNklVFqv6JKX0KDNd8XArli Hifi45IVe4dFtF+Xg9H8Rwbrq9uleR1ADRbfN08oTSnQ356TYDSWg9QLU 1JfGqKrj31xueSwgXSDERha3BS0s1FeECgxnjUxfJqABtjrs9Ooq3RC0O GLRShR0yUXgleghES/06xoUhQZnFAVCAAE/Znmglumw0PTBpA86FeFnJ4 D6vI8SWwPiWj8PT7+aS3b90Ba4yYIDVB7+RuYiL12LsZzUX136iqHxGLP MJGlSj+jBO2HsXL/H0KwDaRQDWeU9KtCMylA56fyE2gKMloKqe1jIgxaf w==; X-IronPort-AV: E=McAfee;i="6600,9927,10742"; a="358019210" X-IronPort-AV: E=Sophos;i="6.00,246,1681196400"; d="scan'208";a="358019210" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jun 2023 23:52:16 -0700 X-IronPort-AV: E=McAfee;i="6600,9927,10742"; a="746067747" X-IronPort-AV: E=Sophos;i="6.00,246,1681196400"; d="scan'208";a="746067747" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.255.230.186]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jun 2023 23:52:16 -0700 Date: Thu, 15 Jun 2023 23:39:29 -0700 Message-ID: <87ttv7ykpq.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa In-Reply-To: <20230616015035.616403-1-umesh.nerlige.ramappa@intel.com> References: <20230616015035.616403-1-umesh.nerlige.ramappa@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/28.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 Subject: Re: [Intel-gfx] [PATCH] drm/i915/perf: Consider OA buffer boundary when zeroing out reports X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Thu, 15 Jun 2023 18:50:35 -0700, Umesh Nerlige Ramappa wrote: > > For reports that are not powers of 2, reports at the end of the OA > buffer may get split across the buffer boundary. When zeroing out such > reports, take the split into consideration. > > Fixes: 09a36015d9a0 ("drm/i915/perf: Clear out entire reports after reading if not power of 2 size") > Signed-off-by: Umesh Nerlige Ramappa > --- > drivers/gpu/drm/i915/i915_perf.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c > index b5491a382bfd..9a8e329c5b5e 100644 > --- a/drivers/gpu/drm/i915/i915_perf.c > +++ b/drivers/gpu/drm/i915/i915_perf.c > @@ -867,8 +867,17 @@ static int gen8_append_oa_reports(struct i915_perf_stream *stream, > oa_report_id_clear(stream, report32); > oa_timestamp_clear(stream, report32); > } else { > + u8 *oa_buf_end = stream->oa_buffer.vaddr + > + stream->oa_buffer.vma->size; Probably: "u8 *oa_buf_end = oa_buf_base + OA_BUFFER_SIZE;" ? We haven't used 'stream->oa_buffer.vma->size' much in this file so I think better to stick to OA_BUFFER_SIZE. > + u32 part = (u32)((void *)oa_buf_end - (void *)report32); This should be sufficient, no need to cast as above I think: u32 part = oa_buf_end - report32; or u32 part = oa_buf_end - report; > + > /* Zero out the entire report */ > - memset(report32, 0, report_size); > + if (report_size <= part) { > + memset(report32, 0, report_size); > + } else { > + memset(report32, 0, part); > + memset(oa_buf_base, 0, report_size - part); > + } Thanks for finding this: Reviewed-by: Ashutosh Dixit > } > } > > -- > 2.36.1 >