Add CPUID instruction

[adsnaider]

Not sure why this isn't already part of the API, it seems like a very natural instruction to have. Am I missing something?

[josephlr]

Nope, it's mostly just figuring out the correct abstraction around the instruction. CPUID does a lot of things, and returns a bunch of different types of data. We will likely need a combination of a "raw" and "non-raw" CPUID function.

[adsnaider]

Tbh, I was just thinking of a low level function like this one

use core::arch::asm;

/// Runs the CPUID instruction with the provided `eax` register.
///
/// # Returns
///
/// A 4-tuple (eax, ebx, ecx, edx). It's up to the user to interpret these values based on the
/// input.
pub fn cpuid(mut eax: u32) -> (u32, u32, u32, u32) {
    let ebx: u32;
    let ecx: u32;
    let edx: u32;
    unsafe {
        asm!(
            "push rbx",
            "cpuid",
            "mov esi, ebx",
            "pop rbx",
             out("esi") ebx,
             inout("eax") eax,
             out("ecx") ecx,
             out("edx") edx
        );
    }
    (eax, ebx, ecx, edx)
}

Even this I think would be useful as it's non-trivial given that LLVM uses rbx.

[josephlr]

So they're already are some functions related to CPUID in the standard library core::arch::x86_64 module:

• __cpuid_count (unsafe)
• __cpuid (unsafe)
• has_cpuid (safe, but unstable)
  • Tracking issue for core::arch::{x86, x86_64}::has_cpuid rust-lang/rust#60123
  • Stabilize the x86 has_cpuid intrinsic rust-lang/stdarch#730 (comment)
• __get_cpuid_max (unsafe)

I would want to make sure we're doing something more then just reimplementing them. That could just be providing a safe and/or stable API.

Regardless, we should reuse the CpuidResult type.

[Freax13]

Just wanted to point out that there's already a very good crate that implements abstractions over cpuid: raw-cpuid.

[josephlr]

@Freax13 That's a really good point. Should we just add a note to the README mentioning that crate? It could be in a "other helper crates" section.

[adsnaider]

@Freax13 Thank you for the info. I agree that having that linked in the README would be sufficient in my opinion.