From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S932406AbcK1Vw3 (ORCPT <rfc822;w@1wt.eu>);
        Mon, 28 Nov 2016 16:52:29 -0500
Received: from mail-qt0-f182.google.com ([209.85.216.182]:34037 "EHLO
        mail-qt0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1755269AbcK1VwS (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 28 Nov 2016 16:52:18 -0500
MIME-Version: 1.0
In-Reply-To: <CALzav=e31K0j5u1mNrseeiu84TvC-8E8K4RWRQQ-1soeE7eMhA@mail.gmail.com>
References: <1479863680-117511-1-git-send-email-dmatlack@google.com>
 <1479863680-117511-4-git-send-email-dmatlack@google.com> <1168524783.1374944.1479891977484.JavaMail.zimbra@redhat.com>
 <CALzav=ea4JFrsivHV0yqav8nW6tspXNtH0TDkn9hX_rDOPazGQ@mail.gmail.com>
 <e9382662-86f3-379e-2c2e-6e2a061f642d@redhat.com> <CALzav=dGsDjhN3JV9onGbUE9Ge0+spH454GenUxb5S30vS7uxQ@mail.gmail.com>
 <ebbe99dc-9725-4a34-467c-ccbbcd1c55d7@redhat.com> <CALzav=e31K0j5u1mNrseeiu84TvC-8E8K4RWRQQ-1soeE7eMhA@mail.gmail.com>
From: David Matlack <dmatlack@google.com>
Date: Mon, 28 Nov 2016 13:51:46 -0800
Message-ID: <CALzav=dqx8soqvHNEFD-M4+Fnq8oZoJ+gYX2jR7F+3o-qeKu2A@mail.gmail.com>
Subject: Re: [PATCH 3/4] KVM: nVMX: accurate emulation of MSR_IA32_CR{0,4}_FIXED1
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm list <kvm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Jim Mattson <jmattson@google.com>,
        =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Nov 23, 2016 at 3:28 PM, David Matlack <dmatlack@google.com> wrote:
> On Wed, Nov 23, 2016 at 2:11 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> On 23/11/2016 23:07, David Matlack wrote:
>>> A downside of this scheme is we'd have to remember to update
>>> nested_vmx_cr4_fixed1_update() before giving VMs new CPUID bits. If we
>>> forget, a VM could end up with different values for CR{0,4}_FIXED0 for
>>> the same CPUID depending on which version of KVM you're running on.

I've realized my concern here doesn't make sense. Such a VM would
likely fail to enter VMX operation, or #GP (unexpectedly) at some
point later. Linux, for example, does not appear to consult
MSR_IA32_VMX_CR4_FIXED1 when determining which bits of CR4 it can use
(regardless of whether it is in VMX operation or not).

>>
>> If userspace doesn't obey KVM_GET_SUPPORTED_CPUID, all bets are off
>> anyway, so I don't think it's a big deal.  However, if you want to make
>> it generated by userspace, that would be fine as well!
>
> Ok let's generate them in userspace.

I'm more inclined to generate them in the kernel, given the above.