[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200124213027.GP2109@linux.intel.com>
Date: Fri, 24 Jan 2020 13:30:28 -0800
From: Sean Christopherson <sean.j.christopherson@...el.com>
To: Randy Dunlap <rdunlap@...radead.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>, KVM <kvm@...r.kernel.org>
Subject: Re: linux-next: Tree for Jan 24 (kvm)
On Fri, Jan 24, 2020 at 12:51:31PM -0800, Randy Dunlap wrote:
> On 1/23/20 10:33 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20200123:
> >
> > The kvm tree gained a conflict against Linus' tree.
> >
>
> on i386:
>
> ../arch/x86/kvm/x86.h:363:16: warning: right shift count >= width of type [-Wshift-count-overflow]
Jim,
This is due to using "unsigned long data" for kvm_dr7_valid() along with
"return !(data >> 32);" to check for bits being set in 63:32. Any
objection to fixing the issue by making @data a u64? Part of me thinks
that's the proper behavior anyways, i.e. the helper is purely a reflection
of the architectural requirements, the caller is responsible for dropping
bits appropriately based on the current mode.
>
>
> --
> ~Randy
> Reported-by: Randy Dunlap <rdunlap@...radead.org>
Powered by blists - more mailing lists