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. I can't imagine fields *disappearing* from eVMCS definition but oh well.. 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? -- Vitaly
