Tracking issue for core::arch::{x86, x86_64}::has_cpuid

[gnzlbg]

This issue tracks the stabilization of the has_cpuid intrinsic.

The "mini-RFC" is part of the stabilization PR: rust-lang/stdarch#730

cc @rust-lang/libs @alexcrichton

[alexcrichton]

@rfcbot fcp merge

There's a longer description of what's being stablilized on the PR, so looking for an official sign-off now!

[rfcbot]

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @Kimundi
• @SimonSapin
• @alexcrichton
• @dtolnay
• @sfackler
• @withoutboats

Concerns:

• not useful (Tracking issue for core::arch::{x86, x86_64}::has_cpuid #60123 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[briansmith]

In what circumstance would somebody call has_cpuid()? Does Rust support any x86 or amd64 targets that don't have CPUID? I've never even considered the possibility that CPUID would be unavailable.

The original RFC mentioned me as somebody who might be interested in this, but really what I'm interested in is the actual CPUID and related intrinsics.

[nagisa]

Yes. SGX target is notable modern target which does not support CPUID.

[briansmith]

Yes. SGX target is notable modern target which does not support CPUID.

Right. However, in practice we need to know "Is this SGX?" not just vaguely "Is CPUID available?" In particular, if the target is SGX then we'll assume certain features are available that we wouldn't normally assume are available by default otherwise.

FWIW, I have code that uses CPUID extensively on all non-SGX x86 and amd64 targets, but I still don't have any use for this function, AFAICT, because it doesn't provide information useful to make a decision. (I mention this because I was mentioned in the other RFC that motivated this.)

[petrochenkov]

Yes. SGX target is notable modern target which does not support CPUID.

Heh, I wonder what result the EFLAGS.ID-based CPUID detection procedure returns inside an enclave.
I suspect it's still going to be true.

On a similar note, if you are calling CPUID inside a VMX-based hypervisor, it will be rerouted to the hypervisor and the hypervisor can do whatever it wants in theory, including eating your laundry :)

[dtolnay]

Registering Brian's point above in #60123 (comment). Do we know of someone with a use case that benefits from this function? How did it come to be added originally?

FWIW, I have code that uses CPUID extensively on all non-SGX x86 and amd64 targets, but I still don't have any use for this function, AFAICT, because it doesn't provide information useful to make a decision.

@rfcbot concern not useful

[Centril]

@alexcrichton Please cancel the FCP and include T-Lang. (I've noted this on many occasions -- exposing intrinsics adds new fundamental abilities that cannot be done in Rust code otherwise and all such decisions needs T-Lang approval)