On 15/11/19 19:33, Jim Mattson wrote: > On Fri, Nov 15, 2019 at 3:42 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >> >> On 14/11/19 21:09, Jim Mattson wrote: >>> Can someone explain this ioctl to me? The more I look at it, the less >>> sense it makes to me. >> >> It certainly has some historical baggage in it, much like >> KVM_GET_MSR_INDEX_LIST. But (unlike KVM_GET_MSR_INDEX_LIST) it's mostly >> okay; the issues you report boil down to one of: >> >> 1) KVM_GET_SUPPORTED_CPUID being a system ioctl >> >> 2) supporting the simple case of taking the output of >> KVM_GET_SUPPORTED_CPUID and passing it to KVM_SET_CPUID2 > > For this purpose, wouldn't 'DEFAULT' make a lot more sense than > 'SUPPORTED' in the name of this ioctl? I'm not sure, this only applies to some relatively unimportant leaves, such as cache topology or vendor/model name. So *in general* SUPPORTED is accurate for leaves that userspace will want to look at in the output of KVM_GET_SUPPORTED_CPUID. DEFAULT would imply that it's what you get if you skip KVM_SET_CPUID2. However, this is not the case. >> 3) CPUID information being poorly designed, or just Intel doing >> undesirable things >> >>> Let's start with leaf 0. If I see 0xd in EAX, does that indicate the >>> *maximum* supported value in EAX? >> >> This is easy, you can always supply a subset of the values to the guest, > > Maybe you can reduce CPUID.0H:EAX, but there are some integer values > that you can't reduce (e.g. CPUID.(EAX=0Dh,ECX=0):ECX). So, I'd argue > that this isn't "easy." True, "easy" referred to leaf 0 only. Other leaves may have nasty interdependencies. The values of EBX and ECX depend on the ECX>1 subleaves, and EAX (as well as the presence of those subleaves) generally depends on feature bits from other CPUID leaves. However, all this is dependent only on processor features and not on KVM's implementation. You can still reduce them if you pay enough attention. For example you can reduce CPUID(0Dh,0).ECX as long as you hide some bits from CPUID(0Dh,0).EDX:EAX. The only thing you need to know about the KVM implementation, is that it takes into account CPUID(0Dh,0).EDX:EAX and CPUID(0Dh,1).EDX:ECX to decide whether to raise an exception on XSETBV or WRMSR(IA32_XSS) respectively. So to some extent this is also a documentation issue. [Aside: fixing leaf 0Dh was my first serious KVM patch. :)] >>> 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? >> >> Again, clearing bits is always supported in theory, but I say "in >> theory" because of course bits 6 and 13 are indeed problematic. And >> unfortunately the only solutions for those is to stick your head in the >> sand and pretend they don't exist. If bits 6 and 13 were handled >> strictly, people would not be able to migrate VMs between e.g. Haswell >> and Ivy Bridge machines within the same fleet, which is something people >> want to do. So, this is (3). > > For these two bits, one could argue that *setting* them is always > supported, at least insofar as *clearing* the normal polarity bits is > supported. True, they just have reversed polarity. The issues are that you might have old VMs started even before the bits were defined, or before you added support for the bits in your stack. Setting them might cause problems in userspace if they were written to know about CPUID(7,0).EBX but not about the reversed polarity of these bits (this may not apply exactly to these two bits---I don't know if they were part of the first batch of features documented for leaf 7---but the same situation may arise in the future). At least CPUID(0Ah).EBX is better in this respect, because you know it exists and what it is going to be used in the future. They are just defined backwards. Of course as you point out those x87 CPUID bits are useless anyway because nobody checks them. > If you say that FCS and FDS are "deprecated [sic]" on your > Ivy Bridge platform, but software relies on it, then that software is > just as ill-behaved as software that depends on any other feature that > has been masked off. (Of course, none of the software that actually > depends on this feature actually checks the CPUID bit, since the CPUID > bit was defined after-the-fact.) So, even if you're strict about it, > you can migrate between Haswell and Ivy Bridge. [...] >> With KVM_ENABLE_CAP, the only one that is _absent_ from >> KVM_GET_SUPPORTED_CPUID the MONITOR bit. > > And leaf 5? Hmm I thought all zeroes would be fine. What does "(default is processor's monitor granularity)" mean for EAX and EBX? Paolo
