From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x225vB0Je4WBdaFMBZMSE1UwInDXkJo8mQGhP6RTFo7W5x2KjB0dolXOAriTV27XUV/7Y1J4F ARC-Seal: i=1; a=rsa-sha256; t=1517430897; cv=none; d=google.com; s=arc-20160816; b=qqMDT6PCSJLiOaCWKUns27JSwlN8UoJBkPYv0qthLIC2+aftjgTCC6wHPsZum2PjJ8 0H4KZjBWV6A80OHvufYto9t99M5S3i+Mx+5/VIaYQRYiF5u405XDGKNeggnp33Pxmd6B pFjM7uwJpxU6CM1ztFh1neReUXG27pjvzss3mBrQSbiyrOgzrG0OkOqip+WXGw/IX7fx IOOfXxYwTjKDDaSIlLc7mOMLwtyIsmZvmtJTg8lF40DdBRtQDJR5mhb6JWk6op585uPw UsqSODGNLQutN+V4Dzf4dtPwvExPDqcyBSRCKpgLOi1lZKmMCvwxbNep7EZZMmHWA98b bZXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :arc-authentication-results; bh=73J7V4icWxHhWi3bsLgRW88Ac7AAqi6WK62O+NoSjrQ=; b=ZWkyX4Epqst8Me6HJ9IFWte+Nm3iZ9Zem36IrceRZ3NgWNCxvHXQlRce41iSG/yAL+ sGLLAhTvYPzWkELJAcvvVDu2qWuKwEI1C/HJgUenZVnfU/J9q5QK9ovtg68a/96J0MN4 EUfZzQRtfJ8CrZ85zZYkFpKrEQnr0PC8fUs8yOhNb3EyoxaxIihR9r+a6c5e5qe4cyPT NJ3E9OGzzsi8Ak9EmCQvvoAHGdk/186XI3kmnFv+zjVLu/9lfhU+1npGWAfr2KfEi8JB mfUX4YHx7y7pbxoLS0vssWAvmP5TIANRQrkKPxB4B7rq10vq9BZWvs0mjuuBL9R48IhH X2fQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of pbonzini@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=pbonzini@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of pbonzini@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=pbonzini@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Subject: Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL To: Jim Mattson , KarimAllah Ahmed Cc: KarimAllah Ahmed , kvm list , LKML , the arch/x86 maintainers , Asit Mallick , Arjan Van De Ven , Dave Hansen , Andi Kleen , Andrea Arcangeli , Linus Torvalds , Tim Chen , Thomas Gleixner , Dan Williams , Jun Nakajima , David Woodhouse , Greg KH , Andy Lutomirski , Ashok Raj References: <1517427467-28567-1-git-send-email-karahmed@amazon.de> <1517427467-28567-5-git-send-email-karahmed@amazon.de> <06cb88da-f355-41ed-380f-7daa8ddf6159@amazon.com> From: Paolo Bonzini Message-ID: <67dca2bb-1298-c7fa-f681-018e4edc6725@redhat.com> Date: Wed, 31 Jan 2018 15:34:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1591113692084885209?= X-GMAIL-MSGID: =?utf-8?q?1591141621216871431?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 31/01/2018 15:18, Jim Mattson wrote: >> but save_spec_ctrl_on_exit is also set for L2 write. So once L2 writes >> to it, this condition will be true and then the bitmap will be updated. > So if L1 or any L2 writes to the MSR, then save_spec_ctrl_on_exit is > set to true, even if the MSR permission bitmap for a particular VMCS > *doesn't* allow the MSR to be written without an intercept. That's > functionally correct, but inefficient. It seems to me that > save_spec_ctrl_on_exit should indicate whether or not the *current* > MSR permission bitmap allows unintercepted writes to IA32_SPEC_CTRL. > To that end, perhaps save_spec_ctrl_on_exit rightfully belongs in the > loaded_vmcs structure, alongside the msr_bitmap pointer that it is > associated with. For vmcs02, nested_vmx_merge_msr_bitmap() should set > the vmcs02 save_spec_ctrl_on_exit based on (a) whether L0 is willing > to yield the MSR to L1, and (b) whether L1 is willing to yield the MSR > to L2. On the first nested write, (b) must be true for L0 to see the MSR write. If L1 doesn't yield the MSR to L2, the MSR write results in an L2->L1 vmexit and save_spec_ctrl_on_exit is not set to true. So save_spec_ctrl_on_exit is set if all of the following are true: (a) L0 is willing to yield the MSR to L1, (b) and the write happens in L1, or all of the following are true: (a) L0 is willing to yield the MSR to L1, (b) L1 is willing to yield the MSR to L2, (c) and the write happens in L2, It doesn't need to be placed in loaded_vmcs, because in the end if L1 is willing to yield the MSR to L2, it will have to do reads and writes of the MSR too, and both loaded_vmcs structs will have save_spec_ctrl_on_exit=1. Paolo