Bug #14485

Updated by Patrick Mooney 6 months ago

Presently, bhyve exposes feature bits through @cpuid@ solely by applying static masks against the corresponding leafs from the host CPU.    While this does work, it poses a challenge for stabilizing the features exposed via @cpuid@, especially in the face of guests migrated between machines (potentially running different hardware _or_ software).    In order to give userspace more control over @cpuid@ emulation, while still maintaining the relative performance of in-kernel emulation for it, bhyve should add functionality similar to KVM for setting/getting a list of leafs to be used for a given instance. 

 The structs/defines for KVM_SET_CPUID2 (the newer, preferred, interface) are as follows: 

 <code lang="c"><pre> 
 struct kvm_cpuid_entry2 { 
         __u32 function; 
         __u32 index; 
         __u32 flags; 
         __u32 eax; 
         __u32 ebx; 
         __u32 ecx; 
         __u32 edx; 
         __u32 padding[3]; 

 #define KVM_CPUID_FLAG_SIGNIFCANT_INDEX           (1 << 0) 
 #define KVM_CPUID_FLAG_STATEFUL_FUNC              (1 << 1) 
 #define KVM_CPUID_FLAG_STATE_READ_NEXT            (1 << 2) 

 /* for KVM_SET_CPUID2 */ 
 struct kvm_cpuid2 { 
         __u32 nent; 
         __u32 padding; 
         struct kvm_cpuid_entry2 entries[0]; 

 Since we don't use per-vcpu file descriptors, we'll probably want to shuffle our @struct kvm_cpuid2@ equivalent to have the @vcpuid@ as the first member, with @nent@ as the second, omitting the padding.