Re: [RFC PATCH v6 00/36] KVM: x86: eVMCS rework

Vitaly Kuznetsov
2022-08-27T14:03:29Z

Vitaly Kuznetsov <vkuznets@redhat.com> 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