Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934337AbcKWTZH (ORCPT ); Wed, 23 Nov 2016 14:25:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36906 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933361AbcKWTZF (ORCPT ); Wed, 23 Nov 2016 14:25:05 -0500 Subject: Re: [PATCH 3/4] KVM: nVMX: accurate emulation of MSR_IA32_CR{0,4}_FIXED1 To: David Matlack 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> Cc: kvm list , "linux-kernel@vger.kernel.org" , Jim Mattson , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= From: Paolo Bonzini Message-ID: Date: Wed, 23 Nov 2016 20:24:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 23 Nov 2016 19:24:24 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1384 Lines: 30 On 23/11/2016 20:16, David Matlack wrote: > > Oh, I thought userspace would do that! Doing it in KVM is fine as well, > > but then do we need to give userspace access to CR{0,4}_FIXED{0,1} at all? > > I think it should be safe for userspace to skip restoring CR4_FIXED1, > since it is 100% generated based on CPUID. But I'd prefer to keep it > accessible from userspace, for consistency with the other VMX MSRs and > for flexibility. The auditing should ensure userspace doesn't restore > a CR4_FIXED1 that is inconsistent with CPUID. Or would it just allow userspace to put anything into it, even if it's inconsistent with CPUID, as long as it's consistent with the host? > Userspace should restore CR0_FIXED1 in case future CPUs change which > bits of CR0 are valid in VMX operation. Userspace should also restore > CR{0,4}_FIXED0 so we have the flexibility to change the defaults in > KVM. Both of these situations seem unlikely but we might as well play > it safe, the cost is small. I disagree, there is always a cost. Besides the fact that it's unlikely that there'll be any future CR0 bits at all, any changes would most likely be keyed by a new CPUID bit (the same as CR4) or execution control (the same as unrestricted guest). In the end, since we assume that userspace (any) has no idea of what to do with it, I see no good reason to make the MSRs available. Paolo