dmaengine: idxd: Clear Event Log head in idxd upon completion of the Enable Device command
Message ID | 20240209191851.1050501-1-fenghua.yu@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-59864-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:50ea:b0:106:860b:bbdd with SMTP id r10csp1076237dyd; Fri, 9 Feb 2024 11:20:24 -0800 (PST) X-Google-Smtp-Source: AGHT+IEUiEcM4WUZPvCkLPTPT6cr+Ctoct77zdF7xdykSuog54oJNSBKOqh5UZruFhKxmEtv0VAQ X-Received: by 2002:a67:ec16:0:b0:46d:6e0f:37c8 with SMTP id d22-20020a67ec16000000b0046d6e0f37c8mr307907vso.17.1707506424444; Fri, 09 Feb 2024 11:20:24 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707506424; cv=pass; d=google.com; s=arc-20160816; b=FILjtmfaLL40CCBOshKSSO7/NGKBcjR215K6PK+86HSyenWsVD15cU20nej4rKAjem /KnuVXqO4AigKO8ycaki4eTIpXuckSUn4FiY2+LramTtAw6qgAgjUlmh5eQ1wf6HDfsg A3tSAOH+IwFjNM8f0UnyO5MKKZ8GTdJXHdNVYIZMGZU9A3TKNxMmqAgwknY+kIHlcoPm lKrCGqy2CvVMIa44LWtWOAzw0H5DkTZlE6n/mzZ1Z2O85OgIJLm+ocC8RkuqmQUFyKr0 7Avxi8yMGBm1x8to75ILx5xyOflKKa3rVuDs9pDIA1GtA7jNSCcM+A2y8iKzl9OKlPf1 IsQA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=GKb2BNWI8EiadgbwIPpjzpMgX45i6nfdQDyI7Aw3+Gc=; fh=36mZAJLWtrx/1RGnRs4tvftC/Msv2lmba8V3R1iOZFM=; b=qEKS3PFvjd/Leo1QOb5jeUfXBxG5eFp0SKjs53C7kp0MAVnjWXJ/shvjqlt18mxYyA v036ZbQ5hFzIgmBY7E509LPFE6Zp9G0ygqlYdjfk+d3oXC/KpvcOiAgsQ5eBBcqUqp+2 S5e+gRr/OTbuLDwDcY1eDtk4ekGS8SVsaW7SppUQZAsxke6O26t51WyJ66IqcuRe0ItG U5hBeovJO2YhxOjaurFllBAb+sumhTi+lvTEYj4Afil4ooaThoZJrhCt6h498x3YrwP3 xkYfFZYjBudLpXQ4vxtfb1j7NPP9viUSgXgQfzbl4V/M3LpieGF5NgsZIvn7hDABY41Z v/9g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TgskkbuH; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-59864-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-59864-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com X-Forwarded-Encrypted: i=2; AJvYcCXf6ma7G4bMfAXQ7vWncId7ZvnZjvSvCBHxYRM1Ei0NImkM2AmvXXcqRDKA9JDj7ThjTMm8Sm+NltozCql0oPqgB58A+A== Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id j18-20020a056102335200b0046b3102d804si31487vse.137.2024.02.09.11.20.24 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Feb 2024 11:20:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-59864-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TgskkbuH; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-59864-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-59864-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 295331C22BFC for <ouuuleilei@gmail.com>; Fri, 9 Feb 2024 19:20:22 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 843CF84A37; Fri, 9 Feb 2024 19:20:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="TgskkbuH" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 628072E3F7; Fri, 9 Feb 2024 19:20:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707506406; cv=none; b=m3NHEe/wngo2KzscDLJ7PIu0ERGvODjYvcYam1s8lF0hdcuM9EfoZQp9iZ5LoSvJlzRdf1fRj39AnmyY3GKQMrSoZSPjVL2+le4h8ArGjMCqFtn4pZVYIaNyyGDICXtlNeVOEVPD3W0gAx27HWHkv8Rm867Gp78lA9TJBeAQvmQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707506406; c=relaxed/simple; bh=/scsUM1RgXZzQBhcLxf4S2Tcz7R+LGWlrGZHqnYQWx4=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=GFgcUbZqqjzWgvhgzhqZX5SHzlCZHbT9zFiy8wB3QFntsRcdOzvvW9auHZ1d4/nY4xCMoDw3wvD07D01d/v2jgPPlreDEhov5C4KnV8H5axsF/kEKvTgADAGUHmH6aCwQieBQY+1l/QD5X01wcfbzmoNMN0CvsTIwayIvb3hgUc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=TgskkbuH; arc=none smtp.client-ip=198.175.65.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1707506406; x=1739042406; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=/scsUM1RgXZzQBhcLxf4S2Tcz7R+LGWlrGZHqnYQWx4=; b=TgskkbuHrDIs9UkqXnlJyJeKDqMH8ZY7Pzts/KD7stEOGZOehBR1NBz5 vhYB5yJC9kW3P1LGYAZRRvtcuqBZ2q36OglSczxq7g+H5WjY5l2uI306+ G8uyAt6HAHeQr1Y6ztQRnPCwyfBie81UhGaNNFvkvjQH+Sd8m9s9ZXSam 1hf7oOCXu0CLQ7wSyFTofMOOxIuwJXHCJZwvTnj7HjSP1zgM8Yhc1hg3u 0Wun5hE+FKo9sVBgnRLgE6YCWpQoVbXZ8BjI19M0jfzXG2OnoIp3F1qUs opQ9hpTIbPNltCqEZ2onfohCidMAhsRESr+0yHEaBJ1b1cS/MydblT8/y w==; X-IronPort-AV: E=McAfee;i="6600,9927,10979"; a="18900285" X-IronPort-AV: E=Sophos;i="6.05,257,1701158400"; d="scan'208";a="18900285" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2024 11:20:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.05,257,1701158400"; d="scan'208";a="2356550" Received: from fyu1.sc.intel.com ([172.25.103.126]) by orviesa006.jf.intel.com with ESMTP; 09 Feb 2024 11:20:04 -0800 From: Fenghua Yu <fenghua.yu@intel.com> To: "Vinod Koul" <vkoul@kernel.org>, "Dave Jiang" <dave.jiang@intel.com> Cc: dmaengine@vger.kernel.org, "linux-kernel" <linux-kernel@vger.kernel.org>, Fenghua Yu <fenghua.yu@intel.com>, Lingyan Guo <lingyan.guo@intel.com> Subject: [PATCH] dmaengine: idxd: Clear Event Log head in idxd upon completion of the Enable Device command Date: Fri, 9 Feb 2024 11:18:51 -0800 Message-Id: <20240209191851.1050501-1-fenghua.yu@intel.com> X-Mailer: git-send-email 2.37.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790450256644845823 X-GMAIL-MSGID: 1790450256644845823 |
Series |
dmaengine: idxd: Clear Event Log head in idxd upon completion of the Enable Device command
|
|
Commit Message
Fenghua Yu
Feb. 9, 2024, 7:18 p.m. UTC
If Event Log is supported, upon completion of the Enable Device command, the Event Log head in the variable idxd->evl->head should be cleared to match the state of the EVLSTATUS register. But the variable is not reset currently, leading mismatch of the variable and the register state. The mismatch causes incorrect processing of Event Log entries. Fix the issue by clearing the variable after completion of the command. Fixes: 2f431ba908d2 ("dmaengine: idxd: add interrupt handling for event log") Tested-by: Lingyan Guo <lingyan.guo@intel.com> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> --- drivers/dma/idxd/device.c | 8 ++++++++ 1 file changed, 8 insertions(+)
Comments
On 2/9/24 12:18 PM, Fenghua Yu wrote: > If Event Log is supported, upon completion of the Enable Device command, > the Event Log head in the variable idxd->evl->head should be cleared to > match the state of the EVLSTATUS register. But the variable is not reset > currently, leading mismatch of the variable and the register state. > The mismatch causes incorrect processing of Event Log entries. > > Fix the issue by clearing the variable after completion of the command. Should this be done in idxd_device_clear_state() instead? > > Fixes: 2f431ba908d2 ("dmaengine: idxd: add interrupt handling for event log") > Tested-by: Lingyan Guo <lingyan.guo@intel.com> > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> > --- > drivers/dma/idxd/device.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/dma/idxd/device.c b/drivers/dma/idxd/device.c > index ecfdf4a8f1f8..7c9fb9b3e110 100644 > --- a/drivers/dma/idxd/device.c > +++ b/drivers/dma/idxd/device.c > @@ -546,6 +546,14 @@ int idxd_device_enable(struct idxd_device *idxd) > return -ENXIO; > } > > + /* > + * If Event Log is supported, Event Log Status register was > + * cleared after the Enable Device command. Clear Event Log > + * head value that is stored in idxd to match the register state. > + */ > + if (idxd->evl) > + idxd->evl->head = 0; > + > idxd->state = IDXD_DEV_ENABLED; > return 0; > }
Hi, Dave, On 2/9/24 12:17, Dave Jiang wrote: > > > On 2/9/24 12:18 PM, Fenghua Yu wrote: >> If Event Log is supported, upon completion of the Enable Device command, >> the Event Log head in the variable idxd->evl->head should be cleared to >> match the state of the EVLSTATUS register. But the variable is not reset >> currently, leading mismatch of the variable and the register state. >> The mismatch causes incorrect processing of Event Log entries. >> >> Fix the issue by clearing the variable after completion of the command. > > Should this be done in idxd_device_clear_state() instead? If clear evl->head in idxd_device_clear_state(), evl->head still mismatches head in EVLSTATUS in some cases. For exmample, when a few event log entries are logged and then device is disabled, head in EVLSTATUS is still a valid non-zero value. Clearing evl->head in idxd_device_clear_state() when disabling device makes evl->head and head in EVLSTATUS mismatched. I haven't thought a failure test case when they mismatch in these cases though. But while thinking evl->head more, I wonder why is it even needed? head of event log can always be read from EVLSTATUS instead of from its shadow evl->head. And reading head from EVLSTATUS won't degrade performance because tail is always read from EVLSTATUS whenever head is read (no matter from evl->head or from EVLSATUS). To avoid any mismatch issue/trouble, I think the right fix is to remove head definition in struct idxd_evl and always read head from EVLSTATUS. Do you think this is the right fix? Thanks. -Fenghua
On 2/10/24 6:49 PM, Fenghua Yu wrote: > Hi, Dave, > > On 2/9/24 12:17, Dave Jiang wrote: >> >> >> On 2/9/24 12:18 PM, Fenghua Yu wrote: >>> If Event Log is supported, upon completion of the Enable Device command, >>> the Event Log head in the variable idxd->evl->head should be cleared to >>> match the state of the EVLSTATUS register. But the variable is not reset >>> currently, leading mismatch of the variable and the register state. >>> The mismatch causes incorrect processing of Event Log entries. >>> >>> Fix the issue by clearing the variable after completion of the command. >> >> Should this be done in idxd_device_clear_state() instead? > > If clear evl->head in idxd_device_clear_state(), evl->head still mismatches head in EVLSTATUS in some cases. > > For exmample, when a few event log entries are logged and then device is disabled, head in EVLSTATUS is still a valid non-zero value. Clearing evl->head in idxd_device_clear_state() when disabling device makes evl->head and head in EVLSTATUS mismatched. > > I haven't thought a failure test case when they mismatch in these cases though. > > But while thinking evl->head more, I wonder why is it even needed? > > head of event log can always be read from EVLSTATUS instead of from its shadow evl->head. And reading head from EVLSTATUS won't degrade performance because tail is always read from EVLSTATUS whenever head is read (no matter from evl->head or from EVLSATUS). > > To avoid any mismatch issue/trouble, I think the right fix is to remove head definition in struct idxd_evl and always read head from EVLSTATUS. > > Do you think this is the right fix? I was to avoid register reads during event processing. But if you think there's no performance impact then feel free to read directly from the register. > > Thanks. > > -Fenghua
Hi, Dave, On 2/12/24 08:39, Dave Jiang wrote: > > > On 2/10/24 6:49 PM, Fenghua Yu wrote: >> Hi, Dave, >> >> On 2/9/24 12:17, Dave Jiang wrote: >>> >>> >>> On 2/9/24 12:18 PM, Fenghua Yu wrote: >>>> If Event Log is supported, upon completion of the Enable Device command, >>>> the Event Log head in the variable idxd->evl->head should be cleared to >>>> match the state of the EVLSTATUS register. But the variable is not reset >>>> currently, leading mismatch of the variable and the register state. >>>> The mismatch causes incorrect processing of Event Log entries. >>>> >>>> Fix the issue by clearing the variable after completion of the command. >>> >>> Should this be done in idxd_device_clear_state() instead? >> >> If clear evl->head in idxd_device_clear_state(), evl->head still mismatches head in EVLSTATUS in some cases. >> >> For exmample, when a few event log entries are logged and then device is disabled, head in EVLSTATUS is still a valid non-zero value. Clearing evl->head in idxd_device_clear_state() when disabling device makes evl->head and head in EVLSTATUS mismatched. >> >> I haven't thought a failure test case when they mismatch in these cases though. >> >> But while thinking evl->head more, I wonder why is it even needed? >> >> head of event log can always be read from EVLSTATUS instead of from its shadow evl->head. And reading head from EVLSTATUS won't degrade performance because tail is always read from EVLSTATUS whenever head is read (no matter from evl->head or from EVLSATUS). >> >> To avoid any mismatch issue/trouble, I think the right fix is to remove head definition in struct idxd_evl and always read head from EVLSTATUS. >> >> Do you think this is the right fix? > > I was to avoid register reads during event processing. But if you think there's no performance impact then feel free to read directly from the register. This code reads head and tail in event processing: h = evl->head; evl_status.bits = ioread64(idxd->reg_base + IDXD_EVLSTATUS_OFFSET); t = evl_status.tail; As you can see EVLSTATUS is always read to get tail. Reading the register to get tail cannot be avoid because that's required by hw. Reading head from the register won't add additional cost. That's why I would say no impact on performance without the shadow head in idxd. I will cook the v2 patch by removing the shadow head. Thanks. -Fenghua
diff --git a/drivers/dma/idxd/device.c b/drivers/dma/idxd/device.c index ecfdf4a8f1f8..7c9fb9b3e110 100644 --- a/drivers/dma/idxd/device.c +++ b/drivers/dma/idxd/device.c @@ -546,6 +546,14 @@ int idxd_device_enable(struct idxd_device *idxd) return -ENXIO; } + /* + * If Event Log is supported, Event Log Status register was + * cleared after the Enable Device command. Clear Event Log + * head value that is stored in idxd to match the register state. + */ + if (idxd->evl) + idxd->evl->head = 0; + idxd->state = IDXD_DEV_ENABLED; return 0; }