Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 07/54] KVM: x86: Alert userspace that KVM_SET_CPUID{,2}
 after KVM_RUN is broken
To:     Jim Mattson <jmattson@google.com>
Cc:     Sean Christopherson <seanjc@google.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Joerg Roedel <joro@8bytes.org>, kvm list <kvm@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Yu Zhang <yu.c.zhang@linux.intel.com>,
        Maxim Levitsky <mlevitsk@redhat.com>
References: <20210622175739.3610207-1-seanjc@google.com>
 <20210622175739.3610207-8-seanjc@google.com>
 <f031b6bc-c98d-8e46-34ac-79e540674a55@redhat.com>
 <CALMp9eSpEJrr6mNoLcGgV8Pa2abQUkPA1uwNBMJZWexBArB3gg@mail.gmail.com>
 <6f25273e-ad80-4d99-91df-1dd0c847af39@redhat.com>
 <CALMp9eTzJb0gnRzK_2MQyeO2kmrKJwyYYHE5eYEai+_LPg8HrQ@mail.gmail.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <af716f56-9d68-2514-7b85-f9bbb1a82acf@redhat.com>
Date:   Wed, 23 Jun 2021 20:49:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <CALMp9eTzJb0gnRzK_2MQyeO2kmrKJwyYYHE5eYEai+_LPg8HrQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 23/06/21 20:11, Jim Mattson wrote:
> On Wed, Jun 23, 2021 at 10:11 AM Paolo Bonzini <pbonzini@redhat.com> 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.

Paolo