VMware Cloud Community
veswamin
Contributor
Contributor

VMWare ESXi 6.5 U2 Intelk RDRAND/RDSEED instruction behavior

Hi,

I have the following configuration :-

• Dell PowerEdge R630 Server

o Hypervisor: VMware ESXi 6.5 U2

o Guest OS : FreeBSD v8.4

o CPU : Intel Xeon E5-2680 v4 2.4 GHz

I'm using Intel provided RDRAND/RDSEED instructions for getting random numbers..

I wanted to know if the instruction  are used in freebsd , whether hypervisor wil

override those Intel instruction RDRAND/RDSEED with its own information,

or the instruction will be directly processed by Intel CPU and data will be relayed back

to the guest os. (Hypervisor doesn't override).

I have some internet sources which says that  to support lockstep mode, hypervisor may override

Intel RDRAND/RDSEED with its own implementation.

Can some one please clarify the  behavior wrt VMware  ESXi 6.5 U2 ?

Thanks.

Reply
0 Kudos
1 Reply
bluefirestorm
Champion
Champion

Your CPU is a Broadwell CPU so it should have both RDRAND and RDSEED.

Look at the vmware.log for these (the samples below is from VMware Player 15.0.2 with a Skylake i7-6700HQ).

vmx| I125:   RDRAND exiting                           {0,1}

vmx| I125:   RDSEED exiting                           {0,1}

vmx| I125: VM Features Required: cpuid.rdrand - Bool:Min:1

vmx| I125: VM Features Required: cpuid.rdseed - Bool:Min:1

The exiting determines whether a VMexit happens whenever the instruction is executed.

You want to make sure that the virtual hardware version is set to 13 (highest possible for ESXi 6.5) and that it does not have any EVC masks. The hardware compatibility can act as a CPU mask and masking out CPU features (e.g. version 10 or lower masks out Haswell features).

I don't think the hypervisor overrides with its own implementation as that would be a form of binary translation.

So if RDRAND and RDSEED instructions are not available inside the VM and it invokes them, it should cause an error rather than the hypervisor deciding what to do with it; just as some VM appliances require AES-NI and the host CPU does not have AES-NI it fails rather than ESXi trying to replace it with its own implementation.

Reply
0 Kudos