On Fri, 26 Nov 2021 13:20:28 +0100 Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > On 11/22/21 18:58, Vitaly Kuznetsov wrote: > > - * KVM does not correctly handle changing guest CPUID after KVM_RUN, as > > - * MAXPHYADDR, GBPAGES support, AMD reserved bit behavior, etc.. aren't > > - * tracked in kvm_mmu_page_role. As a result, KVM may miss guest page > > - * faults due to reusing SPs/SPTEs. Alert userspace, but otherwise > > - * sweep the problem under the rug. > > - * > > - * KVM's horrific CPUID ABI makes the problem all but impossible to > > - * solve, as correctly handling multiple vCPU models (with respect to > > - * paging and physical address properties) in a single VM would require > > - * tracking all relevant CPUID information in kvm_mmu_page_role. That > > - * is very undesirable as it would double the memory requirements for > > - * gfn_track (see struct kvm_mmu_page_role comments), and in practice > > - * no sane VMM mucks with the core vCPU model on the fly. > > + * Changing guest CPUID after KVM_RUN is forbidden, see the comment in > > + * kvm_arch_vcpu_ioctl(). > > */ > > The second part of the comment still applies to kvm_mmu_after_set_cpuid > more than to kvm_arch_vcpu_ioctl(). > > > r = -EFAULT; > > [...] > > + if (vcpu->arch.last_vmentry_cpu != -1) > > + goto out; > > + > > if (copy_from_user(&cpuid, cpuid_arg, sizeof(cpuid))) > > goto out; > > r = kvm_vcpu_ioctl_set_cpuid(vcpu, &cpuid, cpuid_arg->entries); > > This should be an EINVAL. > > Tweaked and queued nevertheless, thanks. it seems this patch breaks VCPU hotplug, in scenario: 1. hotunplug existing VCPU (QEMU stores VCPU file descriptor in parked cpus list) 2. hotplug it again (unsuspecting QEMU reuses stored file descriptor when recreating VCPU) RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2028337#c11 > > Paolo >
