Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp11273pxb; Wed, 30 Mar 2022 21:21:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzWQYtW0mMH9j4kEH7VbQAOPVTwi68+X9WA0wF8JEfJWfejWI5c4OY+CoYueNb83SsqKoVw X-Received: by 2002:a05:6a00:1acb:b0:4fb:358f:fe87 with SMTP id f11-20020a056a001acb00b004fb358ffe87mr3369013pfv.75.1648700464192; Wed, 30 Mar 2022 21:21:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648700464; cv=none; d=google.com; s=arc-20160816; b=yRrSoqFPNS1F6QA01xkJug36MRJhJ0WZGcfqF37EC/WD9w+V8JlYU5rGHAD2s0FbvT fzNYJfjv7HPJBWqH7j7f6QxOz93hG35GVpw2UMRT9g4LZ6BicjXFfo9Hi1XxyuiefvZB NhdqsZ3SVgGrX9i3c1/gfzPc0U2Tt+OndO27mnOl1jmXvKqgL+VPgMAJSudVsEqfPDNf wA9yOqbDeoBYuHT3h0Gq3qyfBuvROsRvyXL8ppMOiavGt9bn/0T/9lAyR4Edpe78u4Qw WtliXOHr1NqaHTLGsBX/KXQPLG1MjfHtg2fK6KSr9jVQl2Xea5fyhkrRFwu+qXCu8vnz sMoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=eNf6vnrVTwPslnma91YW2/KArE2xWXydZtQIsmM49E8=; b=gE9sVErT+imUoHFwZMEY2cch8JF5J3gXCJbPvk/Tvp0SGPOxYGACBmnJknK7CI0hee DhSUrrkzJJfuI5b9cThvH7HLIRRTBOQ5cFmmuW3t2FO0XOFXVxNLJJjOv+CSwEFVzJwk jGR2ThG/QGrbSOOVkmqRmXDP7wCFPlAc4cTwY1oHVZ6R+OFaMcnzbUTKt0ZgkdPuXEfQ 1thUlMvX9vPtVZok0X3KevEfh4DNsQ0mVCibfmdLzdlSLAHChABCJfmtmKlafdl8cTnQ V9wPxcEfh02FgZSclvwVMfVghGAiXCnuUqo4owZ6rEcmVkSlSRoh0Cm0TqftnCSN0HVl GFfw== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id t13-20020a056a0021cd00b004fa8f4f2d6dsi24793303pfj.144.2022.03.30.21.21.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Mar 2022 21:21:04 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 720D0198EFD; Wed, 30 Mar 2022 20:16:24 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348967AbiC3Qqc (ORCPT + 99 others); Wed, 30 Mar 2022 12:46:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348941AbiC3QqZ (ORCPT ); Wed, 30 Mar 2022 12:46:25 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D4F151E3E14 for ; Wed, 30 Mar 2022 09:44:38 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 88ABB1576; Wed, 30 Mar 2022 09:44:38 -0700 (PDT) Received: from [10.1.196.218] (eglon.cambridge.arm.com [10.1.196.218]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ACA3E3F73B; Wed, 30 Mar 2022 09:44:36 -0700 (PDT) Subject: Re: [PATCH v3 15/21] x86/resctrl: Abstract __rmid_read() To: Reinette Chatre , x86@kernel.org, linux-kernel@vger.kernel.org Cc: Fenghua Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Babu Moger , shameerali.kolothum.thodi@huawei.com, Jamie Iles , D Scott Phillips OS , lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com References: <20220217182110.7176-1-james.morse@arm.com> <20220217182110.7176-16-james.morse@arm.com> <853b9cfd-504d-0dcb-2a2c-8b8df75a9b60@intel.com> From: James Morse Message-ID: Date: Wed, 30 Mar 2022 17:44:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <853b9cfd-504d-0dcb-2a2c-8b8df75a9b60@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Reinette, On 16/03/2022 21:52, Reinette Chatre wrote: > On 2/17/2022 10:21 AM, James Morse wrote: >> __rmid_read() selects the specified eventid and returns the counter >> value from the MSR. The error handling is architecture specific, and >> handled by the callers, rdtgroup_mondata_show() and __mon_event_count(). >> >> Error handling should be handled by architecture specific code, as >> a different architecture may have different requirements. MPAM's >> counters can report that they are 'not ready', requiring a second >> read after a short delay. This should be hidden from resctrl. >> >> Make __rmid_read() the architecture specific function for reading >> a counter. Rename it resctrl_arch_rmid_read() and move the error >> handling into it. >> @@ -180,14 +180,24 @@ static u64 __rmid_read(u32 rmid, enum resctrl_event_id eventid) >> * are error bits. >> */ >> wrmsr(MSR_IA32_QM_EVTSEL, eventid, rmid); >> - rdmsrl(MSR_IA32_QM_CTR, val); >> + rdmsrl(MSR_IA32_QM_CTR, msr_val); >> >> - return val; >> + if (msr_val & RMID_VAL_ERROR) >> + return -EIO; >> + if (msr_val & RMID_VAL_UNAVAIL) >> + return -EINVAL; >> + >> + *val = msr_val; >> + >> + return 0; >> } > > From above we see that resctrl_arch_rmid_read() returns an int that could be > -EIO or -EINVAL ... > > ... > >> @@ -319,15 +331,15 @@ static u64 __mon_event_count(u32 rmid, struct rmid_read *rr) >> { >> struct rdt_hw_resource *hw_res = resctrl_to_arch_res(rr->r); >> struct mbm_state *m; >> - u64 chunks, tval; >> + u64 chunks, tval = 0; >> >> if (rr->first) >> resctrl_arch_reset_rmid(rr->r, rr->d, rmid, rr->evtid); >> >> - tval = __rmid_read(rmid, rr->evtid); >> - if (tval & (RMID_VAL_ERROR | RMID_VAL_UNAVAIL)) { >> - return tval; >> - } >> + rr->err = resctrl_arch_rmid_read(rmid, rr->evtid, &tval); >> + if (rr->err) >> + return rr->err; >> + > > Setting rr->err, an int, to the return of resctrl_arch_rmid_read() is ok and > can handle the negative error codes, but returning it here means that > __mon_event_count()'s return type should be changed, > it is currently u64. Good point. Fixed. >> @@ -419,9 +431,14 @@ void mon_event_count(void *info) >> } >> } >> > > Also take care here ... ret_val in mon_event_count() is still u64 while > __mon_event_count() attempts to return negative errors. (yup, fixed) >> - /* Report error if none of rmid_reads are successful */ >> - if (ret_val) >> - rr->val = ret_val; >> + /* >> + * __mon_event_count() calls for newly created monitor groups may >> + * report -EINVAL/Unavailable if the monitor hasn't seen any traffic. >> + * If the first call for the control group succeed, discard any error >> + * set by reads of monitor groups. >> + */ > > Additionally, if the first call fails, but a following read of monitor group > succeeds then the first call's error is discarded. > > How about if the last sentence is replaced with: > "Discard error if any of the monitor event reads succeeded." Sure, Thanks, James