On Tue, Mar 23, 2021 at 01:13:03AM +0100, Ingo Molnar wrote: > > * Michael Kelley <mikelley@xxxxxxxxxxxxx> wrote: > > > From: Ingo Molnar <mingo.kernel.org@xxxxxxxxx> Sent: Monday, March 22, 2021 2:08 PM > > > > > > * Xu Yihang <xuyihang@xxxxxxxxxx> 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 <hulkci@xxxxxxxxxx> > > > > Signed-off-by: Xu Yihang <xuyihang@xxxxxxxxxx> > > > > --- > > > > 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 > > > > 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 problem > > 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. > > Yeah, so the canonical way to signal that the msr_val isn't used would > be to rewrite this as: > > > if (READ_ONCE(*byte) == val) { > unsigned long msr_val; > > rdmsrl(HV_X64_MSR_GUEST_IDLE, msr_val); > > (void)msr_val; > } > > (Also see the patch below - untested.) > > This makes it abundantly clear that the rdmsr() msr_val return value > is not 'maybe' unused, but totally intentionally skipped. > > Thanks, > > Ingo > Thank you for the advice, Ingo. Wei.
