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;
From:   Michael Kelley <mikelley@microsoft.com>
To:     Ingo Molnar <mingo@kernel.org>, Xu Yihang <xuyihang@huawei.com>
CC:     KY Srinivasan <kys@microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
        "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "johnny.chenyi@huawei.com" <johnny.chenyi@huawei.com>,
        "heying24@huawei.com" <heying24@huawei.com>
Subject: RE: [PATCH -next] x86: Fix unused variable 'msr_val' warning
Thread-Topic: [PATCH -next] x86: Fix unused variable 'msr_val' warning
Thread-Index: AQHXHsoFQEsTM3hxi0W0DEPF+rg7dqqQgW4AgAAmoHA=
Date:   Mon, 22 Mar 2021 23:32:26 +0000
Message-ID: <MWHPR21MB15939242EA50C7C1728412D0D7659@MWHPR21MB1593.namprd21.prod.outlook.com>
References: <20210322031713.23853-1-xuyihang@huawei.com>
 <20210322210828.GA1961861@gmail.com>
In-Reply-To: <20210322210828.GA1961861@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b8a26ae3-9379-4c9a-e54c-08d8ed8ac0e9
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 23:32:26.9020
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7oCmDOf4cWGcWKaXbR4tXikhBFYFTQoQOG3LeQ+Gt9Dtd0i2dqL9hWs9VpsGQv10+isdbjcG/3QCnQyoPHo8n3zaZCvbV4lBeMiWztiqxY4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0478
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

From: Ingo Molnar <mingo.kernel.org@gmail.com> Sent: Monday, March 22, 2021=
 2:08 PM
>=20
> * Xu Yihang <xuyihang@huawei.com> wrote:
>=20
> > Fixes the following W=3D1 kernel build warning(s):
> > arch/x86/hyperv/hv_spinlock.c:28:16: warning: variable 'msr_val' set bu=
t 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 pri=
vilege (refer to
> section 4.2.2) may trigger entry into the virtual processor idle sleep st=
ate 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/refe=
rence/tlfs
> >
> > Reported-by: Hulk Robot <hulkci@huawei.com>
> > Signed-off-by: Xu Yihang <xuyihang@huawei.com>
> > ---
> >  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_spinloc=
k.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;
>=20
> Please don't add new __maybe_unused annotations to the x86 tree -
> improve the flow instead to help GCC recognize the initialization
> sequence better.
>=20
> Thanks,
>=20
> 	Ingo

Could you elaborate on the thinking here, or point to some written
discussion?   I'm just curious.   In this particular case, it's not a probl=
em
with the flow or gcc detection.  This code really does read an MSR and
ignore that value that is read, so it's not clear how gcc would ever
figure out that's OK.

Michael