From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id CA60E68CF for ; Mon, 24 Mar 2014 21:46:23 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 24 Mar 2014 13:47:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,723,1389772800"; d="scan'208";a="506626811" Received: from unknown (HELO hanvin-mobl6.amr.corp.intel.com) ([10.255.40.25]) by orsmga002.jf.intel.com with ESMTP; 24 Mar 2014 13:47:55 -0700 Message-ID: <533099FB.5030702@linux.intel.com> Date: Mon, 24 Mar 2014 13:47:55 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Neil Horman 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> In-Reply-To: <20140324195206.GG19368@hmsreliant.think-freely.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Mon, 24 Mar 2014 20:46:24 -0000 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. -hpa