Re: [Qemu-devel] [PATCH 09/20 v3] target-i386: add x86cpu_vendor_words2str()

[Eduardo Habkost]

On Fri, Jan 04, 2013 at 09:46:30PM +0100, Igor Mammedov wrote:
> On Fri, 4 Jan 2013 18:02:33 -0200
> Eduardo Habkost <address@hidden> 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 <address@hidden>
> > > ---
> > >   v3:
> > >     fix/swap vendor2 and vendor3 order
> > >         Spotted-By: Eduardo Habkost <address@hidden>
> > >   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.

-- 
Eduardo