From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH v3] eal_common_cpuflags: Fix %rbx corruption, and simplify the code Date: Mon, 24 Mar 2014 13:47:55 -0700 Message-ID: <533099FB.5030702@linux.intel.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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Neil Horman Return-path: In-Reply-To: <20140324195206.GG19368-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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