On Sat, Aug 27, 2022, Vitaly Kuznetsov wrote: > Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> writes: > > ... > > > > > Honestly I'm starting to think the 'evmcs revisions' idea (to keep > > the exact list of features in KVM and update them every couple years > > when new Hyper-V releases) is easier. It's just a list, it doesn't > > require much. The main downside, as was already named, is that userspace > > VMM doesn't see which VMX features are actually passed to the guest > > unless it is also taught about these "evmcs revisions" (more than what's > > the latest number available). This, to certain extent, can probably be > > solved by VMM itself by doing KVM_GET_MSRS after vCPU is created (this > > won't help much with feature discovery by upper layers, tough). This, > > however, is a new use-case, unsupported with the current > > KVM_CAP_HYPERV_ENLIGHTENED_VMCS implementation. > > ... > > Thinking more about the above, if we invert the filtering logic (to > explicitly list what's supported), KVM's code which we will have to add > for every new revision can be very compact as it will only have to list > the newly added features. But that point KVM would effectively be implementing a less flexible version of VMX MSRs. > I can't imagine fields *disappearing* from eVMCS definition but oh well.. It's unlikely that features will truly disappear, but it is relatively likely that userspace will want to hide a feature. It's also likely that hardware won't support all "previous" features, e.g. Intel has a habit of making features like TSC scaling and APICv available only on Xeon SKUs. Handling arbitrary configurations via version numbers gets kludgy because it's impossible for userspace to communicate its exact desires to KVM. All userspace can do is state that it's aware of features up through version X; hiding individual features requires maniuplating the VMX MSRs. And if userspace needs to set VMX MSRs, then userspace also needs to get VMX MSRs, and so why not simply have userspace do exactly that? The only missing piece is a way for userspace to opt-in to activating the "feature is available if supported in hardware _and_ eVMCS" logic so as not to break backwards compatibility. A per-VM capability works very well for that. > Anyway, I think this series is already getting too big and has many > important fixes but some parts are still controversial. What if I split > off everything-but-Hyper-V-on-KVM (where no controversy is currenly > observed) and send it out so we can continue discussing the issue at > hand more conveniently? Yes, let's do that.
