On 03/19/2014 07:48 AM, Neil Horman wrote:
> The recent conversion to build dpdk as a DSO has an error in
> rte_cpu_get_features. When being build with -fpie, %ebx gets clobbered by the
> cpuid instruction which is also the pic register. Therefore the inline asm
> tries to save off %ebx, but does
On 03/19/2014 05:40 PM, Neil Horman wrote:
> So after some discussion with hpa, I need to self NAK this again, apologies
> for
> the noise. Theres some clean up to be done in this area, and I'm still
> getting
> a segfault that is in some way related to this code, but I need to dig deeper
> to
On 03/20/2014 04:27 AM, Neil Horman wrote:
>>
> So, I answered my own question, sort of. The __i386__ is clear: x86_64 uses
> RIP
> relative addressing, making the saving of ebx not needed - thats perfectly
> clear.
>
> Whats a bit less clear to me is why it matters. Ideally moving ebx and
> re
only needs %eax (leaf) and %ecx
(subleaf) as parameters, and since we are testing for bits, we might
as well list the bits explicitly. Furthermore, we can use an array
rather than doing a switch statement inside a structure.
Reported-by: Neil Horman
Signed-off-by: H. Peter Anvin
---
lib
I just realized there is yet another oddity in this code:
> @@ -78,8 +69,10 @@ struct cpuid_parameters_t {
> struct feature_entry {
> enum rte_cpu_flag_t feature;/**< feature name */
The structure contains a field with an enum value...
> char name[CPU_FLAG_NAME_MAX_LEN];
On 03/21/2014 07:49 AM, Neil Horman wrote:
> From: "H. Peter Anvin"
>
> Neil Horman reported that on x86-64 the upper half of %rbx would get
> clobbered when the code was compiled PIC or PIE, because the
> i386-specific code to preserve %ebx was incorrectly compiled.
On 03/24/2014 09:06 AM, Neil Horman wrote:
>>
>> If C99-style initializers are permitted in this codebase, I would
>> strongly recommend using them, and then drop the enum field in struct
>> feature_entry and use a macro such as:
>>
> Actually, its a bit simpler than that, the enum parameter is act
On 03/24/2014 10:44 AM, Neil Horman wrote:
> * Modified cpuid_reg enum to start at 1 rather than zero
> * Added CPUID_REG macro to drop enum value by 1 during access
I guess I don't get it... why?
-hpa
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
>
On 03/25/2014 10:03 AM, Neil Horman wrote:
> int
> rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
> {
> - int value;
> + const struct feature_entry *feat;
> + cpuid_registers_t regs;
> + static uint32_t max_leaf = 0;
> +
> + if (!max_leaf) {
> + /* Get the
a structure.
>
> Reported-by: Neil Horman
> Signed-off-by: H. Peter Anvin
> Signed-off-by: Neil Horman
>
Looks good to me.
Reviewed-by: H. Peter Anvin
-hpa
From: "H. Peter Anvin"
Checkin
a132a9cf2bcd440a974b9d3f5c44ba30b2c895a1 hash: use intrinsic
changed the rte_hash_crc.h from using the crc32 instruction via inline
assembly to using an intrinsic. The intrinsic should allow for better
compiler performance, but the change did not accou
12 matches
Mail list logo
