[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5c0282a66ae54d36af674a568b58071b@AcuMS.aculab.com>
Date: Tue, 25 Feb 2020 15:19:14 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Paolo Bonzini' <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Sean Christopherson <sean.j.christopherson@...el.com>
CC: Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 43/61] KVM: x86: Use KVM cpu caps to mark CR4.LA57 as
not-reserved
From: Paolo Bonzini
> Sent: 25 February 2020 15:12
> On 24/02/20 23:08, Vitaly Kuznetsov wrote:
> >> +
> >> +static __always_inline bool kvm_cpu_cap_has(unsigned x86_feature)
> >> +{
> >> + return kvm_cpu_cap_get(x86_feature);
> >> +}
> > I know this works (and I even checked C99 to make sure that it works not
> > by accident) but I have to admit that explicit '!!' conversion to bool
> > always makes me feel safer :-)
>
> Same here, I don't really like the automagic bool behavior...
I just dislike 'bool'.
Conversion of 0/non-zero to 0/1 isn't completely free.
And something has to 'give' when the referenced memory location
doesn't contain 0 or 1.
One very old version of gcc made a complete hash of:
bool_var |= function_returning_bool();
I'm not sure what the standard requires nor what current gcc
generates - but you want a 'logical or' instruction.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists