[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211227183253.45a03ca2@redhat.com>
Date: Mon, 27 Dec 2021 18:32:53 +0100
From: Igor Mammedov <imammedo@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Vitaly Kuznetsov <vkuznets@...hat.com>, kvm@...r.kernel.org,
Sean Christopherson <seanjc@...gle.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] KVM: x86: Forbid KVM_SET_CPUID{,2} after KVM_RUN
On Fri, 26 Nov 2021 13:20:28 +0100
Paolo Bonzini <pbonzini@...hat.com> 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
>
Powered by blists - more mailing lists