From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6968FC433E6 for ; Wed, 17 Feb 2021 18:08:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3B56364E5B for ; Wed, 17 Feb 2021 18:08:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233299AbhBQSIG (ORCPT ); Wed, 17 Feb 2021 13:08:06 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:24229 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232243AbhBQSID (ORCPT ); Wed, 17 Feb 2021 13:08:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613585197; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=k+PafZtTxxRkQ/4iNlBI25yfowv1emoIIbzvsMB2gSE=; b=Y/chTFCJ2hixJEiLF88GIhd6CPmu93FcwVns2gkwxSaOn7+mq5vJweNBlZZDP07I73s67u 1K2s1humEN/USTwgWIGwAAib44kOmtBoUBxQK8OBaBlz27I3zqLm3va94WPETtnkkoHhQc xFu5or32tas1vg6jYuSsbRqbtmdXE2M= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-545--iYPh-OmPL65teTp_xmHEg-1; Wed, 17 Feb 2021 13:06:35 -0500 X-MC-Unique: -iYPh-OmPL65teTp_xmHEg-1 Received: by mail-wm1-f71.google.com with SMTP id j204so2710985wmj.4 for ; Wed, 17 Feb 2021 10:06:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=k+PafZtTxxRkQ/4iNlBI25yfowv1emoIIbzvsMB2gSE=; b=BslVZZtFARN0fKNIVv4jJxszSdexZbbozLLMBhBahae2NUaqeydrPKroxTbaijByb4 8DW9VrbbEMhEFNNrwi7S1H8lJR2/9MNtxmNGsxtVLxtA4BLOUeiX6N32kC64tNN1RIYH AyDyYRzjFzqf4DsYi77r/hZ5kkAxK1Q8Id1Qa1yzht3EoWc0WUITSYfHGoi4HkNDsMU8 q/jibNUG32FHI7UGZ0bWZMXPWh2iOINuWb1nz/k9kJc4jcYFzE/BTW61Nd/z9wIzM4dH 1g8bEwDqyc1Bk27uOyaPUauKQBbK/4cyO6UTbU+8O/ouhE6f7cgDt+5ke/E/0sgo97Ee hOXw== X-Gm-Message-State: AOAM532H9ghdt8r9CYjDFURzRBZahJwLWBHjEH4RslGQznJ1q0Tod5ir ncq++Ua7p8fn5dRk1jxZ1wa5q90Nz6v2zfEN6C5RlvnnDycXmheM6YsRXhYMcZvopXS2fRTIFaE vmp92GM4bCL6Q8Sq00xye7TTG X-Received: by 2002:a7b:c397:: with SMTP id s23mr136732wmj.10.1613585194511; Wed, 17 Feb 2021 10:06:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJzj3+yONrD5USEwpi0jytCwqxYl0gWMNhs6MJDy1RnaxhN+ylhooyQJKQvSXLrh8MQUjAvhhA== X-Received: by 2002:a7b:c397:: with SMTP id s23mr136705wmj.10.1613585194201; Wed, 17 Feb 2021 10:06:34 -0800 (PST) Received: from ?IPv6:2001:b07:6468:f312:c8dd:75d4:99ab:290a? ([2001:b07:6468:f312:c8dd:75d4:99ab:290a]) by smtp.gmail.com with ESMTPSA id w8sm5037173wrm.21.2021.02.17.10.06.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Feb 2021 10:06:33 -0800 (PST) To: Sean Christopherson , Maxim Levitsky Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Wanpeng Li , Borislav Petkov , Joerg Roedel , Jim Mattson , "H. Peter Anvin" , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Thomas Gleixner , Vitaly Kuznetsov , Ingo Molnar References: <20210217145718.1217358-1-mlevitsk@redhat.com> <20210217145718.1217358-7-mlevitsk@redhat.com> From: Paolo Bonzini Subject: Re: [PATCH 6/7] KVM: nVMX: don't load PDPTRS right after nested state set Message-ID: <8660e415-5375-d4cf-54d4-b0b8eb6e1dc3@redhat.com> Date: Wed, 17 Feb 2021 19:06:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/02/21 18:52, Sean Christopherson wrote: >> >> Just move the call to nested_vmx_load_cr3 to nested_get_vmcs12_pages >> to implement this. > > I don't love this approach. KVM_SET_NESTED_STATE will now succeed with a bad > vmcs12.GUEST_CR3. At a minimum, GUEST_CR3 should be checked in > nested_vmx_check_guest_state(). It also feels like vcpu->arch.cr3 should be set > immediately, e.g. KVM_SET_NESTED_STATE -> KVM_GET_SREGS should reflect L2's CR3 > even if KVM_RUN hasn't been invoked. Note that KVM_SET_NESTED_STATE does not remove the need to invoke KVM_SET_SREGS. Calling KVM_SET_NESTED_STATE does not necessarily saying anything about the value of KVM_GET_SREGS after it. In particular on SVM it's a "feature" that KVM_SET_NESTED_STATE does not include any guest register state; the nested state only includes the VMCB12 control state and the L1 save state. But thinking more about it, loading the PDPTRs for the guest CR3 might not be advisable even upon KVM_SET_SREGS, and we might want to extend KVM_REQ_GET_NESTED_PAGES to cover non-nested PDPTRs as well. Paolo