Loading ...
Sorry, an error occurred while loading the content.

Re: Need a tool for pulling CPU information...

Expand Messages
  • thad_floryan
    ... Compiling and running assembly code within GCC piqued my curiosity, so I cobbled up a test program that runs on Linux and Windows and correctly reported
    Message 1 of 11 , Jan 7, 2010
    • 0 Attachment
      --- In linux@yahoogroups.com, "thad_floryan" <thad@...> wrote:
      > [...]
      > It's very odd the latest Linux kernels don't have those virtualization
      > flags listed in /proc/cpuinfo's output.
      > [...]

      Compiling and running assembly code within GCC piqued my curiosity, so
      I cobbled up a test program that runs on Linux and Windows and correctly
      reported VMX for my Intel E8500 systems. The two dual-core Athlon AMD
      systems I have do not have hardware virtualization support so I have no
      way to test for SVN which AMD has had since September 2005.

      Jeff and/or anyone else, if you have any AMD systems whose CPUs you
      know have hardware virtualization support, please try the enclosed
      program.

      Simply do a copy'n'paste of everything from "#include <stdio.h>" to the
      end of this article and save in a file named cpuid.c

      On Linux, simply type "make cpuid" (no Makefile is needed), or you can
      do this: "gcc cpuid.c -o cpuid"

      Then enter "./cpuid" to run the program whose source code follows:

      #include <stdio.h>
      #define cpuid(func,ax,bx,cx,dx)\
      __asm__ __volatile__ ("cpuid":\
      "=a" (ax), "=b" (bx), "=c" (cx), "=d" (dx) : "a" (func));

      #define CHECK_BIT(var,pos) ((var) & (1<<(pos)))
      #define BIT(pos) (1<<(pos))

      main()
      {
      unsigned int eax,ebx,ecx,edx;

      cpuid(0, eax, ebx, ecx, edx);
      printf("eax/%8x, ebx/%8x, ecx/%8x, edx/%8x\n", eax, ebx, ecx, edx);

      if (0x756e6547 == ebx && 0x6c65746e == ecx && 0x49656e69 == edx)
      { /* encoded "GenuineIntel" */
      printf("Intel CPU\n");
      cpuid(1, eax, ebx, ecx, edx);
      printf("eax/%8x, ebx/%8x, ecx/%8x, edx/%8x\n", eax, ebx, ecx, edx);

      if (0 != CHECK_BIT(ecx,5)) /* test if bit 5 set */
      {
      printf("CPU has VMX (Virtual Machine Extensions)\n");
      }
      else
      {
      printf("CPU does NOT have VMX\n");
      }
      }
      else if (0x68747541 == ebx && 0x444d4163 == ecx && 0x69746e65 == edx)
      { /* encoded "AuthenticAMD" */
      printf("AMD CPU\n");
      cpuid(0x80000001, eax, ebx, ecx, edx);
      printf("eax/%8x, ebx/%8x, ecx/%8x, edx/%8x\n", eax, ebx, ecx, edx);

      if (0 != CHECK_BIT(ecx,2)) /* test if bit 2 set */
      {
      printf("CPU has SVM (Secure Virtual Machine)\n");
      }
      else
      {
      printf("CPU does NOT have SVM\n");
      }
      }
      else
      {
      printf("Unknown CPU\n");
      }
      }
    • J
      ... That was an interesting read... and now bookmarked. ... I ve been thinking about this, and you re wrong, at least in a small part. And the more I think
      Message 2 of 11 , Jan 7, 2010
      • 0 Attachment
        On Wed, Jan 6, 2010 at 20:09, thad_floryan <thad@...> wrote:

        > <http://softpixel.com/~cwright/programming/simd/cpuid.php>

        That was an interesting read... and now bookmarked.

        > It's very odd the latest Linux kernels don't have those virtualization
        > flags listed in /proc/cpuinfo's output.

        I've been thinking about this, and you're wrong, at least in a small
        part. And the more I think about it, the more bizarre this lack of
        support becomes.

        I haven't tested this on any of my systems at home, mostly because
        right now my netbook running #!Crunchbang is the only working *nix
        system I have. My aging RHEL box is not long for this world, and my
        fedora running Toshiba is in pieces waiting for me to grow a pair and
        finish soldering the new power socket onto the mainboard.

        What I've realized is that at least SuSE and Red Hat have supported
        these extra flags in their kernels for a while now... at the very
        least, I've verified that the extra Intel flags are seen and reported
        in /proc/cpuinfo by SLES 11 and RHEL 5.4. What's odd, is that it
        seems that this support did NOT make it into OpenSuSE and Fedora.

        That makes me wonder if this little bit of functionality is being
        treated as one of their "Enterprise Level Value-Adds" or something
        silly like that. Of course, I'm assuming all this based on your
        observations that other distros (and I'm hoping you at least tried
        this on Fedora) don't show the extended flag set from the ECX
        register.

        Like I said earlier, at least as far as Red Hat goes, the kernel code
        that pulls the CPU info for /proc/cpuinfo is either partly or
        completely from "some version" of the dmidecode source code, and that
        code is NOT part of the actual compiled dmidecode tool. So that would
        make it seem that they have two versions of dmidecode.c. One CAN get
        the flag info and reports it in /proc/cpuinfo, and one can not.

        Another consideration is that perhaps they are instead doing what you
        just did, and just wrote a bit of embedded asm in the kernel code to
        get all the cpuid info instead of the limited info that DMI reports.
        Either way, I am still now curious as to why that is in their
        Enterprise level kernels and no where else.

        Given that the code is the same, I'd expect that CentOS 5.4 can also
        see all the flags though.

        > Another idea, though kludgy, is get the CPU model number and make
        > some assumptions whether SVM and VMX are supported or not.  :-)

        Yeah... and honestly, it may come to that. I'm enjoying this
        experience immensely, but since what I'm writing officially has to be
        simple and easy to maintain, the Powers That Be, may not be so happy
        with the lengths I'm going to for this :) on the other hand, it gives
        me something to do besides troll Craigslist.

        For part of this, at least, I am 99% sure that the test for AMD
        virtualization will never be used. IBM seems to have turned their
        back on AMD and gone strictly Intel (there may be some systems under
        development over in Tiawan that use AMD chips, the Tiawan group
        handles low-end mass quantity systems). However, the winds could
        certainly change at any time, so I wanted to include it just in case
        that happens.

        OTOH, it may indeed be far simpler to just assume that the tester
        running my code has at least some $CLUE and knows the capabilities of
        what he/she is testing and I'd almost be willing to make the
        assumption that ANY processor we test here, at least, will include
        virtualization support as we tend to only use the high-end Intel
        processors. But then again, either of those assumptions could easily
        bite me in the butt... sigh... what a world.

        Cheers
        Jeff

        --

        Pablo Picasso - "Computers are useless. They can only give you
        answers." - http://www.brainyquote.com/quotes/authors/p/pablo_picasso.html
      • thad_floryan
        ... I was looking at w-a-y too many systems and, you re correct, I was partially wrong, contributed in part by an error in AMD s docs dated March 2009 but
        Message 3 of 11 , Jan 7, 2010
        • 0 Attachment
          --- In linux@yahoogroups.com, J <dreadpiratejeff@...> wrote:
          >
          > On Wed, Jan 6, 2010 at 20:09, thad_floryan <thad@...> wrote:
          >
          > > <http://softpixel.com/~cwright/programming/simd/cpuid.php>
          >
          > That was an interesting read... and now bookmarked.
          >
          > > It's very odd the latest Linux kernels don't have those
          > > virtualization flags listed in /proc/cpuinfo's output.
          >
          > I've been thinking about this, and you're wrong, at least in a small
          > part. And the more I think about it, the more bizarre this lack of
          > support becomes.
          > [...]
          > What I've realized is that at least SuSE and Red Hat have supported
          > these extra flags in their kernels for a while now... at the very
          > least, I've verified that the extra Intel flags are seen and reported
          > in /proc/cpuinfo by SLES 11 and RHEL 5.4. What's odd, is that it
          > seems that this support did NOT make it into OpenSuSE and Fedora.

          I was looking at w-a-y too many systems and, you're correct, I was
          partially wrong, contributed in part by an error in AMD's docs dated
          March 2009 but since corrected; for example, the Athlon 4850e CPUs are
          *now* stated as supporting SVM (hardware virtualization).

          Two good things:

          1. the SVM support *is* in Fedora (at least Fedora 9), and
          2. the program I posted here yesterday works on both Intel and AMD
          CPU systems.

          To wit:

          [thad@antares ~]$ cat /proc/cpuinfo
          processor : 0
          vendor_id : AuthenticAMD
          cpu family : 15
          model : 107
          model name : AMD Athlon(tm) Dual Core Processor 4850e
          [...]
          flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca \
          cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt \
          rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic \
          cr8_legacy 3dnowprefetch

          [thad@antares ~]$ ./cpuid
          eax/ 1, ebx/68747541, ecx/444d4163, edx/69746e65
          AMD CPU
          eax/ 60fb2, ebx/ 4e57, ecx/ 11f, edx/ebd3fbff
          CPU has SVM (Secure Virtual Machine)












          >
          > That makes me wonder if this little bit of functionality is being
          > treated as one of their "Enterprise Level Value-Adds" or something
          > silly like that. Of course, I'm assuming all this based on your
          > observations that other distros (and I'm hoping you at least tried
          > this on Fedora) don't show the extended flag set from the ECX
          > register.
          >
          > Like I said earlier, at least as far as Red Hat goes, the kernel code
          > that pulls the CPU info for /proc/cpuinfo is either partly or
          > completely from "some version" of the dmidecode source code, and that
          > code is NOT part of the actual compiled dmidecode tool. So that would
          > make it seem that they have two versions of dmidecode.c. One CAN get
          > the flag info and reports it in /proc/cpuinfo, and one can not.
          >
          > Another consideration is that perhaps they are instead doing what you
          > just did, and just wrote a bit of embedded asm in the kernel code to
          > get all the cpuid info instead of the limited info that DMI reports.
          > Either way, I am still now curious as to why that is in their
          > Enterprise level kernels and no where else.
          >
          > Given that the code is the same, I'd expect that CentOS 5.4 can also
          > see all the flags though.
          >
          > > Another idea, though kludgy, is get the CPU model number and make
          > > some assumptions whether SVM and VMX are supported or not. :-)
          >
          > Yeah... and honestly, it may come to that. I'm enjoying this
          > experience immensely, but since what I'm writing officially has to be
          > simple and easy to maintain, the Powers That Be, may not be so happy
          > with the lengths I'm going to for this :) on the other hand, it gives
          > me something to do besides troll Craigslist.
          >
          > For part of this, at least, I am 99% sure that the test for AMD
          > virtualization will never be used. IBM seems to have turned their
          > back on AMD and gone strictly Intel (there may be some systems under
          > development over in Tiawan that use AMD chips, the Tiawan group
          > handles low-end mass quantity systems). However, the winds could
          > certainly change at any time, so I wanted to include it just in case
          > that happens.
          >
          > OTOH, it may indeed be far simpler to just assume that the tester
          > running my code has at least some $CLUE and knows the capabilities of
          > what he/she is testing and I'd almost be willing to make the
          > assumption that ANY processor we test here, at least, will include
          > virtualization support as we tend to only use the high-end Intel
          > processors. But then again, either of those assumptions could easily
          > bite me in the butt... sigh... what a world.
          >
          > Cheers
          > Jeff
          >
          > --
          >
          > Pablo Picasso - "Computers are useless. They can only give you
          > answers." - http://www.brainyquote.com/quotes/authors/p/pablo_picasso.html
          >
        • thad_floryan
          ... The glitch on Fedora is still dmidecode; though /proc/cpuinfo has the correct info for SVM, here s is dmidecode s for the same CPU on the same system
          Message 4 of 11 , Jan 7, 2010
          • 0 Attachment
            --- In linux@yahoogroups.com, "thad_floryan" <thad@...> wrote:
            > [...]
            > I was looking at w-a-y too many systems and, you're correct, I was
            > partially wrong, contributed in part by an error in AMD's docs dated
            > March 2009 but since corrected; for example, the Athlon 4850e CPUs are
            > *now* stated as supporting SVM (hardware virtualization).
            > [...]

            The "glitch" on Fedora is still dmidecode; though /proc/cpuinfo has the
            correct info for SVM, here's is dmidecode's for the same CPU on the
            same system noting that SVM isn't displayed even though that bit in the
            flags register was available for years before the last dmidecode update:

            Flags:
            FPU (Floating-point unit on-chip)
            VME (Virtual mode extension)
            DE (Debugging extension)
            PSE (Page size extension)
            TSC (Time stamp counter)
            MSR (Model specific registers)
            PAE (Physical address extension)
            MCE (Machine check exception)
            CX8 (CMPXCHG8 instruction supported)
            APIC (On-chip APIC hardware supported)
            SEP (Fast system call)
            MTRR (Memory type range registers)
            PGE (Page global enable)
            MCA (Machine check architecture)
            CMOV (Conditional move instruction supported)
            PAT (Page attribute table)
            PSE-36 (36-bit page size extension)
            CLFSH (CLFLUSH instruction supported)
            MMX (MMX technology supported)
            FXSR (Fast floating-point save and restore)
            SSE (Streaming SIMD extensions)
            SSE2 (Streaming SIMD extensions 2)
            HTT (Hyper-threading technology)
            Version: AMD Athlon(tm) Dual Core Processor 4850e
            Voltage: 1.2 V
            External Clock: 200 MHz
            Max Speed: 3700 MHz
            Current Speed: 2500 MHz
            Status: Populated, Enabled
            Upgrade: Socket 940
          Your message has been successfully submitted and would be delivered to recipients shortly.