From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 9AF683F9 for ; Tue, 25 Mar 2014 11:40:28 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1WSOnt-0007WE-Af; Tue, 25 Mar 2014 06:42:01 -0400 Date: Tue, 25 Mar 2014 06:41:56 -0400 From: Neil Horman To: "H. Peter Anvin" Message-ID: <20140325104156.GA8102@hmsreliant.think-freely.org> References: <20140320163921.GC7721@hmsreliant.think-freely.org> <1395683088-19687-1-git-send-email-nhorman@tuxdriver.com> <533074F0.3060204@linux.intel.com> <20140324195206.GG19368@hmsreliant.think-freely.org> <533099FB.5030702@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533099FB.5030702@linux.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v3] eal_common_cpuflags: Fix %rbx corruption, and simplify the code X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 10:40:28 -0000 On Mon, Mar 24, 2014 at 01:47:55PM -0700, H. Peter Anvin wrote: > On 03/24/2014 12:52 PM, Neil Horman wrote: > >> > > To add an extra sanity check in rte_get_flag_enabled. If we were moving to the > > use of C99 initalizers, I wanted something to catch the possibility that we skip > > a flag by accident (i.e. leave a zero initalized hole in the array). Except 0 > > from my read is a valid value for all the fields of the array. So I bumped up > > the cpuid register enum by one and wrapped it in a macro. That way we can test > > for !feat->reg as an indicator that we're requesting feature support for a flag > > thats not listed in the array. > > It actually isn't: there aren't any flags in CPUID leaf 0, so since the > code only looks for bits it'd be perfectly okay to reject leaf 0. > > Another thing that I noted is that the code doesn't actually check that > any particular leaf is valid (by checking the maximum leaf number in > CPUID leaf 0xXXXX0000:EAX). Especially for the leaf 7 features this > could result in false positives, which obviously would be disastrous. > Thanks, I'll improve this checking today. > -hpa > > >