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 S1763542AbdJQRfx (ORCPT <rfc822;w@1wt.eu>);
        Tue, 17 Oct 2017 13:35:53 -0400
Received: from mx1.redhat.com ([209.132.183.28]:49414 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753284AbdJQRfw (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 17 Oct 2017 13:35:52 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2437919D225
Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=pbonzini@redhat.com
Subject: Re: [PATCH v2 1/2] KVM: VMX: Don't advertise EPT switching if EPT
 itself is not exposed
To: Jim Mattson <jmattson@google.com>, Wanpeng Li <kernellwp@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, kvm list <kvm@vger.kernel.org>,
        =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        Wanpeng Li <wanpeng.li@hotmail.com>
References: <1508213038-5593-1-git-send-email-wanpeng.li@hotmail.com>
 <CALMp9eRG902CG4kAq19a3dGRMcQyJ1Le9osLF1QcoqLdyRKdbw@mail.gmail.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <f60cbdeb-442f-8151-7b13-833ee8a4dc79@redhat.com>
Date: Tue, 17 Oct 2017 19:35:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CALMp9eRG902CG4kAq19a3dGRMcQyJ1Le9osLF1QcoqLdyRKdbw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 17 Oct 2017 17:35:52 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 17/10/2017 19:29, Jim Mattson wrote:
> Following the same line of reasoning, what if
> vmx->nested.nested_vmx_secondary_ctls_high is 0 after clearing
> SECONDARY_EXEC_ENABLE_VMFUNC? Does it make sense to report
> CPU_BASED_ACTIVATE_SECONDARY_CONTROLS if we don't actually support any
> of the secondary controls?

All-zero is a valid value for secondary controls, so I think yes.  Besides:

1) userspace can always get into a situation where there are no valid
secondary controls but processor-based execution controls have bit 31 as
1-allowed;

2) I doubt that vmfunc can be the one bit that causes
nested_vmx_secondary_ctls_high to become zero :)

Paolo