From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hpa@linux.intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id CA60E68CF
 for <dev@dpdk.org>; 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" <hpa@linux.intel.com>
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 <nhorman@tuxdriver.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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