From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37C28C48BC2 for ; Wed, 23 Jun 2021 19:02:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 200126120D for ; Wed, 23 Jun 2021 19:02:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230013AbhFWTEw (ORCPT ); Wed, 23 Jun 2021 15:04:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229759AbhFWTEu (ORCPT ); Wed, 23 Jun 2021 15:04:50 -0400 Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 97DF7C061756 for ; Wed, 23 Jun 2021 12:02:31 -0700 (PDT) Received: by mail-oo1-xc2f.google.com with SMTP id k21-20020a4a2a150000b029024955603642so984146oof.8 for ; Wed, 23 Jun 2021 12:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MRqftscF1FzfzzSjl5zFo7iO4VJxE2+eaqEj1NzMIwk=; b=N3zmO53vFPvwU+U7IahzduZVgdhRclf7RioMWOY+16NWHJ0+cf/uqdULwG4OvgCQzk Z6QN1tXNYwWWK9PuDVzuLkTlINpbkyhFYm6US7NUtvm7pzLLQV3daJvVqQnGZxOAjy0l jAnBACNa/mO2/NxRq+VFB9DvMh8xuTW6lKvZ86vb97EtPEi7hZv/zYhR+pd/cvohlto8 Pq8LEF2+gZaR0LjsQz1yiiPJsC/kP+mxmUZ1/1VRzEyQhxW8yW27q7qb6OeNRa4e6Pwm 5xUykPTFC1nvHZJ79TwbMEjjtMA45P1oAGfvzsW9OIoYtpz0Qj/tsyhCfORb8jz1hG9i KYag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MRqftscF1FzfzzSjl5zFo7iO4VJxE2+eaqEj1NzMIwk=; b=eBFV7SOs0kM9Jvo4mOktI8OGERkCk21uh+cGN0W8Qa637GzZbytCj/C7ng5+78O/rA ZAHr56Oumleq1hokVhiiYbAKCruTJvhet1tTR/YY7XRMn84L83QKVXSmpa1EovaIvNYj s/PA1E216SJ6axO309BCz0qzclx9el8LuwLZ9OZXl2Zj5Y0iKgoeJ0hIkAh+4vsJom4k 0CezQOeEpYhFNP6r4pXbejMFQQbhVv4GysCzMWuc7M+MNafTyHIbNAcbgAxrCOCu2B1n 0bR8NiXLdqYEx3W6+hMOyR2GKHBa6RljGHSJoitPK3uD/PbhcSY5MnaQMjBueef71fXb UgIQ== X-Gm-Message-State: AOAM5322+pbSgZOlsOjQlbCxOca6nAgtP6yY3FriAzZNJfhmrQAjGqqs x0kvGcSg3aVyTbBJ9VCF/Tkipym3aGGti36kn3bwXA== X-Google-Smtp-Source: ABdhPJx1rKEuvgjZXk4Aa0YPqdFzImQ6xpZMX639CAYw+F7eQsq6FSOuI4g8MPeykoozbRPJyFgLT8+n15pY7iONbVI= X-Received: by 2002:a4a:6c0c:: with SMTP id q12mr1045468ooc.81.1624474950658; Wed, 23 Jun 2021 12:02:30 -0700 (PDT) MIME-Version: 1.0 References: <20210622175739.3610207-1-seanjc@google.com> <20210622175739.3610207-8-seanjc@google.com> <6f25273e-ad80-4d99-91df-1dd0c847af39@redhat.com> In-Reply-To: From: Jim Mattson Date: Wed, 23 Jun 2021 12:02:19 -0700 Message-ID: Subject: Re: [PATCH 07/54] KVM: x86: Alert userspace that KVM_SET_CPUID{,2} after KVM_RUN is broken To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , kvm list , LKML , Yu Zhang , Maxim Levitsky Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 23, 2021 at 11:49 AM Paolo Bonzini wrote: > > On 23/06/21 20:11, Jim Mattson wrote: > > On Wed, Jun 23, 2021 at 10:11 AM Paolo Bonzini wrote: > >> Nah, that's not the philosophy. The philosophy is that covering all > >> possible ways for userspace to shoot itself in the foot is impossible. > >> > >> However, here we're talking about 2 lines of code (thanks also to your > >> patches that add last_vmentry_cpu for completely unrelated reasons) to > >> remove a whole set of bullet/foot encounters. > > > > What about the problems that arise when we have different CPUID tables > > for different vCPUs in the same VM? Can we just replace this > > hole-in-foot inducing ioctl with a KVM_VM_SET_CPUID ioctl on the VM > > level that has to be called before any vCPUs are created? > > Are there any KVM bugs that this can fix? The problem is that, unlike > this case, it would be effectively impossible to deprecate > KVM_SET_CPUID2 as a vcpu ioctl, so it would be hard to reap any benefits > in KVM. > > BTW, there is actually a theoretical usecase for KVM_SET_CPUID2 after > KVM_RUN, which is to test OSes against microcode updates that hide, > totally random example, the RTM bit. But it's still not worth keeping > it given 1) the bugs and complications in KVM, 2) if you really wanted > that kind of testing so hard, the fact that you can just create a new > vcpu file descriptor from scratch, possibly in cooperation with > userspace MSR filtering 3) AFAIK no one has done that anyway in 15 years. Though such a usecase may exist, I don't think it actually works today. For example, kvm_vcpu_after_set_cpuid() potentially changes the value of the guest IA32_PERF_GLOBAL_CTRL MSR.