| Message ID | 1357328244-4410-1-git-send-email-imammedo@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Fri, Jan 04, 2013 at 08:37:24PM +0100, Igor Mammedov wrote: > Make for() cycle reusable for the next patch > > Signed-off-by: Igor Mammedov <imammedo@redhat.com> > --- > v3: > fix/swap vendor2 and vendor3 order > Spotted-By: Eduardo Habkost <ehabkost@redhat.com> > v2: > place x86cpu_vendor_words2str() a bit earlier, before feature > arrays to avoid compile error when vendor property is converted > static property. > --- > target-i386/cpu.c | 21 ++++++++++++++------- > 1 files changed, 14 insertions(+), 7 deletions(-) > > diff --git a/target-i386/cpu.c b/target-i386/cpu.c > index d6e4e71..e26e631 100644 > --- a/target-i386/cpu.c > +++ b/target-i386/cpu.c > @@ -45,6 +45,18 @@ > #include "hw/apic_internal.h" > #endif > > +static void x86cpu_vendor_words2str(char *dst, uint32_t ebx, uint32_t ecx, > + uint32_t edx) > +{ > + int i; > + for (i = 0; i < 4; i++) { > + dst[i] = ebx >> (8 * i); > + dst[i + 4] = ecx >> (8 * i); > + dst[i + 8] = edx >> (8 * i); > + } > + dst[CPUID_VENDOR_SZ] = '\0'; > +} Now the code seems to work as expected, but the parameter names are misleading. String bytes 4-7 (vendor2) come from EDX on the CPUID instruction, and bytes 8-11 (vendor3) come from ECX. Look at the x86cpu_vendor_words2str() calls you added on patch 10/20. > + > /* feature flags taken from "Intel Processor Identification and the CPUID > * Instruction" and AMD's "CPUID Specification". In cases of disagreement > * between feature naming conventions, aliases may be added. > @@ -1131,15 +1143,10 @@ static char *x86_cpuid_get_vendor(Object *obj, Error **errp) > X86CPU *cpu = X86_CPU(obj); > CPUX86State *env = &cpu->env; > char *value; > - int i; > > value = (char *)g_malloc(CPUID_VENDOR_SZ + 1); > - for (i = 0; i < 4; i++) { > - value[i ] = env->cpuid_vendor1 >> (8 * i); > - value[i + 4] = env->cpuid_vendor2 >> (8 * i); > - value[i + 8] = env->cpuid_vendor3 >> (8 * i); > - } > - value[CPUID_VENDOR_SZ] = '\0'; > + x86cpu_vendor_words2str(value, env->cpuid_vendor1, env->cpuid_vendor2, > + env->cpuid_vendor3); > return value; > } > > -- > 1.7.1 >
On Fri, 4 Jan 2013 18:02:33 -0200 Eduardo Habkost <ehabkost@redhat.com> wrote: > On Fri, Jan 04, 2013 at 08:37:24PM +0100, Igor Mammedov wrote: > > Make for() cycle reusable for the next patch > > > > Signed-off-by: Igor Mammedov <imammedo@redhat.com> > > --- > > v3: > > fix/swap vendor2 and vendor3 order > > Spotted-By: Eduardo Habkost <ehabkost@redhat.com> > > v2: > > place x86cpu_vendor_words2str() a bit earlier, before feature > > arrays to avoid compile error when vendor property is converted > > static property. > > --- > > target-i386/cpu.c | 21 ++++++++++++++------- > > 1 files changed, 14 insertions(+), 7 deletions(-) > > > > diff --git a/target-i386/cpu.c b/target-i386/cpu.c > > index d6e4e71..e26e631 100644 > > --- a/target-i386/cpu.c > > +++ b/target-i386/cpu.c > > @@ -45,6 +45,18 @@ > > #include "hw/apic_internal.h" > > #endif > > > > +static void x86cpu_vendor_words2str(char *dst, uint32_t ebx, uint32_t ecx, > > + uint32_t edx) > > +{ > > + int i; > > + for (i = 0; i < 4; i++) { > > + dst[i] = ebx >> (8 * i); > > + dst[i + 4] = ecx >> (8 * i); > > + dst[i + 8] = edx >> (8 * i); > > + } > > + dst[CPUID_VENDOR_SZ] = '\0'; > > +} > > Now the code seems to work as expected, but the parameter names are > misleading. String bytes 4-7 (vendor2) come from EDX on the CPUID > instruction, and bytes 8-11 (vendor3) come from ECX. Look at the > x86cpu_vendor_words2str() calls you added on patch 10/20. Perhaps naming params like this would be better: x86cpu_vendor_words2str(char *dst, uint32_t vendor1, uint32_t vendor2, uint32_t vendor3) > [...] > > > > -- > > 1.7.1 > > > > -- > Eduardo
On Fri, Jan 04, 2013 at 09:46:30PM +0100, Igor Mammedov wrote: > On Fri, 4 Jan 2013 18:02:33 -0200 > Eduardo Habkost <ehabkost@redhat.com> wrote: > > > On Fri, Jan 04, 2013 at 08:37:24PM +0100, Igor Mammedov wrote: > > > Make for() cycle reusable for the next patch > > > > > > Signed-off-by: Igor Mammedov <imammedo@redhat.com> > > > --- > > > v3: > > > fix/swap vendor2 and vendor3 order > > > Spotted-By: Eduardo Habkost <ehabkost@redhat.com> > > > v2: > > > place x86cpu_vendor_words2str() a bit earlier, before feature > > > arrays to avoid compile error when vendor property is converted > > > static property. > > > --- > > > target-i386/cpu.c | 21 ++++++++++++++------- > > > 1 files changed, 14 insertions(+), 7 deletions(-) > > > > > > diff --git a/target-i386/cpu.c b/target-i386/cpu.c > > > index d6e4e71..e26e631 100644 > > > --- a/target-i386/cpu.c > > > +++ b/target-i386/cpu.c > > > @@ -45,6 +45,18 @@ > > > #include "hw/apic_internal.h" > > > #endif > > > > > > +static void x86cpu_vendor_words2str(char *dst, uint32_t ebx, uint32_t ecx, > > > + uint32_t edx) > > > +{ > > > + int i; > > > + for (i = 0; i < 4; i++) { > > > + dst[i] = ebx >> (8 * i); > > > + dst[i + 4] = ecx >> (8 * i); > > > + dst[i + 8] = edx >> (8 * i); > > > + } > > > + dst[CPUID_VENDOR_SZ] = '\0'; > > > +} > > > > Now the code seems to work as expected, but the parameter names are > > misleading. String bytes 4-7 (vendor2) come from EDX on the CPUID > > instruction, and bytes 8-11 (vendor3) come from ECX. Look at the > > x86cpu_vendor_words2str() calls you added on patch 10/20. > > Perhaps naming params like this would be better: > x86cpu_vendor_words2str(char *dst, uint32_t vendor1, uint32_t vendor2, uint32_t vendor3) Sounds good to me, considering that the x86_cpuid_get_vendor() code doesn't know anything about ebx/ecx/edx, just about vendor1/vendor2/vendor3. Then just the code that deals directly with registers from the CPUID output will need to take care about the ebx/edx/ecx ordering when calling the function.
diff --git a/target-i386/cpu.c b/target-i386/cpu.c index d6e4e71..e26e631 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -45,6 +45,18 @@ #include "hw/apic_internal.h" #endif +static void x86cpu_vendor_words2str(char *dst, uint32_t ebx, uint32_t ecx, + uint32_t edx) +{ + int i; + for (i = 0; i < 4; i++) { + dst[i] = ebx >> (8 * i); + dst[i + 4] = ecx >> (8 * i); + dst[i + 8] = edx >> (8 * i); + } + dst[CPUID_VENDOR_SZ] = '\0'; +} + /* feature flags taken from "Intel Processor Identification and the CPUID * Instruction" and AMD's "CPUID Specification". In cases of disagreement * between feature naming conventions, aliases may be added. @@ -1131,15 +1143,10 @@ static char *x86_cpuid_get_vendor(Object *obj, Error **errp) X86CPU *cpu = X86_CPU(obj); CPUX86State *env = &cpu->env; char *value; - int i; value = (char *)g_malloc(CPUID_VENDOR_SZ + 1); - for (i = 0; i < 4; i++) { - value[i ] = env->cpuid_vendor1 >> (8 * i); - value[i + 4] = env->cpuid_vendor2 >> (8 * i); - value[i + 8] = env->cpuid_vendor3 >> (8 * i); - } - value[CPUID_VENDOR_SZ] = '\0'; + x86cpu_vendor_words2str(value, env->cpuid_vendor1, env->cpuid_vendor2, + env->cpuid_vendor3); return value; }
Make for() cycle reusable for the next patch Signed-off-by: Igor Mammedov <imammedo@redhat.com> --- v3: fix/swap vendor2 and vendor3 order Spotted-By: Eduardo Habkost <ehabkost@redhat.com> v2: place x86cpu_vendor_words2str() a bit earlier, before feature arrays to avoid compile error when vendor property is converted static property. --- target-i386/cpu.c | 21 ++++++++++++++------- 1 files changed, 14 insertions(+), 7 deletions(-)