Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755842AbcK1Ws7 (ORCPT ); Mon, 28 Nov 2016 17:48:59 -0500 Received: from mail-wj0-f193.google.com ([209.85.210.193]:33970 "EHLO mail-wj0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755375AbcK1Wst (ORCPT ); Mon, 28 Nov 2016 17:48:49 -0500 Subject: Re: [PATCH 1/4] KVM: nVMX: support restore of VMX capability MSRs To: David Matlack References: <1479863680-117511-1-git-send-email-dmatlack@google.com> <1479863680-117511-2-git-send-email-dmatlack@google.com> Cc: kvm list , "linux-kernel@vger.kernel.org" , Jim Mattson , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= From: Paolo Bonzini Message-ID: Date: Mon, 28 Nov 2016 23:48:46 +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 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 900 Lines: 23 On 28/11/2016 22:11, David Matlack wrote: > > PINBASED_CTLS, PROCBASED_CTLS, EXIT_CTLS and ENTRY_CTLS can be derived > > from their "true" counterparts, so I think it's better to remove the > > "non-true" ones from struct nested_vmx (and/or add the "true" ones when > > missing) and make them entirely computed. But it can be done on top. > > Good point. And that would mean userspace does not need to restore the > non-true MSRs, right? Yes, sorry for being a bit too concise. :) > KVM does not emulate MSR_IA32_VMX_BASIC[55]=0, > and will probably never want to. That's a separate question, MSR_IA32_VMX_BASIC[55]=0 basically means that the "true" capabilities are the same as the "default" capabilities. If userspace wanted to set it that way, KVM right now would not hide the "true" capability MSR, but on the other hand the nested hypervisor should not even notice the difference. Paolo