From: Igor Mammedov <imammedo@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>,
kvm@vger.kernel.org, Sean Christopherson <seanjc@google.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] KVM: x86: Forbid KVM_SET_CPUID{,2} after KVM_RUN
Date: Mon, 27 Dec 2021 18:32:53 +0100 [thread overview]
Message-ID: <20211227183253.45a03ca2@redhat.com> (raw)
In-Reply-To: <16368a89-99ea-e52c-47b6-bd006933ec1f@redhat.com>
On Fri, 26 Nov 2021 13:20:28 +0100
Paolo Bonzini <pbonzini@redhat.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
>
next prev parent reply other threads:[~2021-12-27 17:33 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-22 17:58 [PATCH 0/2] KVM: x86: Forbid KVM_SET_CPUID{,2} after KVM_RUN Vitaly Kuznetsov
2021-11-22 17:58 ` [PATCH 1/2] KVM: selftests: Avoid KVM_SET_CPUID2 after KVM_RUN in hyperv_features test Vitaly Kuznetsov
2021-11-22 17:58 ` [PATCH 2/2] KVM: x86: Forbid KVM_SET_CPUID{,2} after KVM_RUN Vitaly Kuznetsov
2021-11-26 12:20 ` Paolo Bonzini
2021-12-27 17:32 ` Igor Mammedov [this message]
2022-01-02 17:31 ` Paolo Bonzini
2022-01-03 8:04 ` Vitaly Kuznetsov
2022-01-03 9:40 ` Igor Mammedov
2022-01-03 12:56 ` Vitaly Kuznetsov
2022-01-05 8:17 ` Igor Mammedov
2022-01-05 9:12 ` Vitaly Kuznetsov
2022-01-05 9:10 ` Paolo Bonzini
2022-01-05 10:09 ` Vitaly Kuznetsov
2022-01-07 9:02 ` Vitaly Kuznetsov
2022-01-07 18:15 ` Paolo Bonzini
2022-01-11 8:00 ` Igor Mammedov
2022-01-12 13:58 ` Vitaly Kuznetsov
2022-01-12 18:39 ` Paolo Bonzini
2022-01-13 9:27 ` Vitaly Kuznetsov
2022-01-13 14:28 ` Maxim Levitsky
2022-01-13 14:36 ` Vitaly Kuznetsov
2022-01-13 14:41 ` Maxim Levitsky
2022-01-13 14:59 ` Vitaly Kuznetsov
2022-01-13 16:26 ` Sean Christopherson
2022-01-13 16:30 ` Maxim Levitsky
2022-01-13 22:33 ` Sean Christopherson
2022-01-14 8:28 ` Maxim Levitsky
2022-01-14 16:08 ` Sean Christopherson
2022-01-14 8:55 ` Igor Mammedov
2022-01-14 9:31 ` Vitaly Kuznetsov
2022-01-14 11:22 ` Igor Mammedov
2022-01-14 12:25 ` Vitaly Kuznetsov
2022-01-14 17:00 ` Sean Christopherson
2022-01-17 9:55 ` Vitaly Kuznetsov
2022-01-17 11:20 ` Paolo Bonzini
2022-01-17 13:02 ` Vitaly Kuznetsov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211227183253.45a03ca2@redhat.com \
--to=imammedo@redhat.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.