Can someone explain this ioctl to me? The more I look at it, the less sense it makes to me. Let's start with leaf 0. If I see 0xd in EAX, does that indicate the *maximum* supported value in EAX? Or does that mean that only a value of 0xd is supported for EAX? If I see "AuthenticAMD" in EBX/EDX/ECX, does that mean that "GenuineIntel" is *not* supported? I thought people were having reasonable success with cross-vendor migration. What about leaf 7 EBX? If a bit is clear, does that mean setting the bit is unsupported? If a bit is set, does that mean clearing the bit is unsupported? Do those answers still apply for bits 6 and 13, where a '1' indicates the absence of a feature? What about leaf 0xa? Kvm's api.txt says, "Note that certain capabilities, such as KVM_CAP_X86_DISABLE_EXITS, may expose cpuid features (e.g. MONITOR) which are not supported by kvm in its default configuration. If userspace enables such capabilities, it is responsible for modifying the results of this ioctl appropriately." However, it appears that the vPMU is enabled not by such a capability, but by filling in leaf 0xa. How does userspace know what leaf 0xa values are supported by both the hardware and kvm? And as for KVM_CAP_X86_DISABLE_EXITS, in particular, how is userspace supposed to know what the appropriate modification to KVM_GET_SUPPORTED_CPUID is? Is this documented somewhere else? And as for the "certain capabilities" clause above, should I assume that any capability enabled by userspace may require modifications to KVM_GET_SUPPORTED_CPUID? What might those required modifications be? Has anyone thought to document them, or better yet, provide an API to get them? What about the processor brand string in leaves 0x80000000-0x80000004? Is a string of NULs really the only supported value? And just a nit, but why does this ioctl bother returning explicitly zeroed leaves for unsupported leaves in range? It would really be nice if I could use this ioctl to write a "HostSupportsGuest" function based in part on an existing guest's CPUID information, but that doesn't seem all that feasible, without intimate knowledge of how the host's implementation of kvm works.
