Messages in this thread | | | From | Vitaly Kuznetsov <> | Subject | Re: [PATCH 0/5] KVM: x86: Partially allow KVM_SET_CPUID{,2} after KVM_RUN for CPU hotplug | Date | Fri, 14 Jan 2022 09:12:37 +0100 |
| |
Sean Christopherson <seanjc@google.com> writes:
> On Thu, Jan 13, 2022, Vitaly Kuznetsov wrote: >> Recently, KVM made it illegal to change CPUID after KVM_RUN but >> unfortunately this change is not fully compatible with existing VMMs. >> In particular, QEMU reuses vCPU fds for CPU hotplug after unplug and it >> calls KVM_SET_CPUID2. Relax the requirement by implementing an allowlist >> of entries which are allowed to change. > > Honestly, I'd prefer we give up and just revert feb627e8d6f6 ("KVM: x86: Forbid > KVM_SET_CPUID{,2} after KVM_RUN"). Attempting to retroactively restrict the > existing ioctls is becoming a mess, and I'm more than a bit concerned that this > will be a maintenance nightmare in the future, without all that much benefit to > anyone.
I cannot say I disagree)
> > I also don't love that the set of volatile entries is nothing more than "this is > what QEMU needs today". There's no architectural justification, and the few cases > that do architecturally allow CPUID bits to change are disallowed. E.g. OSXSAVE, > MONITOR/MWAIT, CPUID.0x12.EAX.SGX1 are all _architecturally_ defined scenarios > where CPUID can change, yet none of those appear in this list. Some of those are > explicitly handled by KVM (runtime CPUID updates), but why should it be illegal > for userspace to intercept writes to MISC_ENABLE and do its own CPUID emulation?
I see. Another approach would be to switch from the current allowlist approach to a blocklist of things which we forbid to change ("MAXPHYADDR, GBPAGES support, AMD reserved bit behavior, ...") after the first KVM_RUN.
-- Vitaly
| |