Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3750126pxf; Mon, 22 Mar 2021 14:10:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyjw9Xfanjv83tRf+xxQHHVYl0RnZIQ6/fCSu7MTtwOTn+qwcEYv3NdOawqQRvCfgdRIlEg X-Received: by 2002:a05:6402:5189:: with SMTP id q9mr1567717edd.168.1616447421648; Mon, 22 Mar 2021 14:10:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616447421; cv=none; d=google.com; s=arc-20160816; b=c0JrUSbdUdOtzjrJIZaOk+8zdNO9JVhEmr23VdS/zCzU+HULQQZBWFkcLwbH5d4n8z 8F76FUGQL8hN/d46J4UaXnV1w3Z22iqsZCq/3tuwNN03ILZvLTvCzOC+rB9QunEOBFxm Oc7Yn9/IUfcrE3VO9TFl3Pklhnd8YhMyjgIY5d7spdpq/55prp40HDHtxxzipWD6eW5J AixTVJdPVS26U3eRSP0qe7hDHVRa+0Ztr6/3LZZs0DnKALfOWIV+J4T77FD3L9FZISfx 6KLHn1TMz3c4Gubp6UjyDwqxYkKOH/0XdaXcQ2EsRifN+zwjbG9rOS6la3mgI6Q2unU1 yQfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:sender:dkim-signature; bh=MeMyP6yxpEyI8O18iLMWHARj/2oI4TtzSo5lwW4fJW4=; b=qu04FJNYc1SoyNsiFiFwLf9yvbaDsuONyPs7MzEBrYlGKYzumoVcAocQFUvZr3R7dD 9mDJQ2GXFmDtTYIlCvULQGj5kDdeJt0FCnyb0CUE2PKp6NM7zrbg20Sx1vMVTCOj3ecG PNIPzihoUAvvBP6gaoo8zJ/2q/LfY5ZDkgshlcVYZID2ioPBGVWnTz0jQzNKbcJkV1ZQ JivigpEwoj0kHpgWeijux53ugSykmCYyhEYnCjHzhikvceSO2WFHX4yLlfbWID65G3hP 7ZCHC/hG/kj/G/MoiJbJeC/dSszmMNy6rqBQM93acL36WTTkEPMG51raJNiV1lH9L/dd NUxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=k5ZGdyQ0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u4si12191212ejz.522.2021.03.22.14.09.58; Mon, 22 Mar 2021 14:10:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=k5ZGdyQ0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230233AbhCVVJC (ORCPT + 99 others); Mon, 22 Mar 2021 17:09:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229574AbhCVVId (ORCPT ); Mon, 22 Mar 2021 17:08:33 -0400 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7170C061574; Mon, 22 Mar 2021 14:08:31 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id j3so21039196edp.11; Mon, 22 Mar 2021 14:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=MeMyP6yxpEyI8O18iLMWHARj/2oI4TtzSo5lwW4fJW4=; b=k5ZGdyQ0UwJMm0SwLsEVo76cQvkNMXFAqTOh+dAJ1+3/dwFvDk8Qfk9LlXI+HULT2T LQekvdF2sqsyQDjh23IpBUHLWUwX7c+9LTWKmXmExAqDs5UiaBgBfrmSSFZ07G7k6WNI DVWdl8ZP4p0a7AlAn1c763j8WLiEBQO8tGMwDTQZGwr1YbhM+DsMyUfUyCDNEMBP0Sw0 Ly8TglYJLFeUrCKRlMHPzay9ybP6GaWMOMj+lsRvyyH9TWjB5MofI9gG6Ssqif+lrfMi /0SI2Fv/ppGBf8mqqBdNlbnDyOrtNF1GbWowpmAO0vlYeMwRkHWeDICTgJ61ItlzB0gk YQMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=MeMyP6yxpEyI8O18iLMWHARj/2oI4TtzSo5lwW4fJW4=; b=lBm3gQQCavVrg4hQGme67zQV78EWGPTyeXU63XIBOR/HyuoHuA8s9q1IltuRl3+QSX pH+cR4VNDubxxWL/TrYGlwQISM/qLei6jvXNAEpDHdILLsMHGy0J0j9jsfHlkiwlHLNK AFEgQI9nL78toTnZvxnQjgMxes2XCSAjxYwWoKYrlEiSeSDGlEmL83zpsRVZmXZQeWFz baHaYUqQ4D59gaKls8Kn9orqW7NV51QFYfjrONXCdNkXDrWqVLYliws8pO0AWOrXfVMR fNe/j5l6xw2sdtgARcTiImR/7ucj4wPfuF1bNmgaVJ3Rz6DpHqTC3OSD2QScq3y7Ngm1 k5lw== X-Gm-Message-State: AOAM532yciLPntDDbFHoc0j3mtKRphwnYhIGS02fqugWHmFHal1kd9Qe YzAv2Nw8UKogoaYY0gRMcV4= X-Received: by 2002:aa7:cd16:: with SMTP id b22mr1514895edw.357.1616447310498; Mon, 22 Mar 2021 14:08:30 -0700 (PDT) Received: from gmail.com (54033286.catv.pool.telekom.hu. [84.3.50.134]) by smtp.gmail.com with ESMTPSA id v22sm10184101ejj.103.2021.03.22.14.08.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Mar 2021 14:08:30 -0700 (PDT) Sender: Ingo Molnar Date: Mon, 22 Mar 2021 22:08:28 +0100 From: Ingo Molnar To: Xu Yihang Cc: kys@microsoft.com, haiyangz@microsoft.com, sthemmin@microsoft.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, johnny.chenyi@huawei.com, heying24@huawei.com Subject: Re: [PATCH -next] x86: Fix unused variable 'msr_val' warning Message-ID: <20210322210828.GA1961861@gmail.com> References: <20210322031713.23853-1-xuyihang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210322031713.23853-1-xuyihang@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Xu Yihang wrote: > Fixes the following W=1 kernel build warning(s): > arch/x86/hyperv/hv_spinlock.c:28:16: warning: variable ‘msr_val’ set but not used [-Wunused-but-set-variable] > unsigned long msr_val; > > As Hypervisor Top-Level Functional Specification states in chapter 7.5 Virtual Processor Idle Sleep State, "A partition which possesses the AccessGuestIdleMsr privilege (refer to section 4.2.2) may trigger entry into the virtual processor idle sleep state through a read to the hypervisor-defined MSR HV_X64_MSR_GUEST_IDLE". That means only a read is necessary, msr_val is not uesed, so __maybe_unused should be added. > > Reference: > https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs > > Reported-by: Hulk Robot > Signed-off-by: Xu Yihang > --- > arch/x86/hyperv/hv_spinlock.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c > index f3270c1fc48c..67bc15c7752a 100644 > --- a/arch/x86/hyperv/hv_spinlock.c > +++ b/arch/x86/hyperv/hv_spinlock.c > @@ -25,7 +25,7 @@ static void hv_qlock_kick(int cpu) > > static void hv_qlock_wait(u8 *byte, u8 val) > { > - unsigned long msr_val; > + unsigned long msr_val __maybe_unused; > unsigned long flags; Please don't add new __maybe_unused annotations to the x86 tree - improve the flow instead to help GCC recognize the initialization sequence better. Thanks, Ingo