Received: by 10.223.176.5 with SMTP id f5csp1531831wra; Wed, 7 Feb 2018 22:24:05 -0800 (PST) X-Google-Smtp-Source: AH8x226j/r9xxG5RK1N3zZt67IT68epTB7x2mEtijj+T8HAZRK7ip3moXDCJ0azYXIPa1LJyB2vs X-Received: by 2002:a17:902:8a89:: with SMTP id p9-v6mr8397726plo.397.1518071045847; Wed, 07 Feb 2018 22:24:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518071045; cv=none; d=google.com; s=arc-20160816; b=RbrHQUlp7htm+9KicRNqqERAhF0O4EiafG1NQv72mFFUsUwutQnn0n0nF3xWhNNQ8S jc8HuRm5aUQZxwt7+au7Jhb4oWrMrdTn3AJqWTiZ3uSq//QR7Y12oY1NmLqUYgykC4zo eqPF5K1CTC/1L02fleoHMSATW59cXxb4a4srlUnQ3EkfAys3PWF/lmoRE4/gUvaxq2li QW5tt6dNMZQW23FxoerHQK/wBfheJdLWTV08RBNISgm1eR0trwzKo/8pLQv3Qu7cmoRc XEBnC1Ip9B9eqqVw4kk6pPmFjly76acjnkkV75kTjYW+dmGxKHXXF0ez+udYlmcII5B+ tXTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=yEm4eFy4ZjMQ9MgPoH148qE5xDk/T3mWyryM6ewRZ7U=; b=Efdttq1tKjbuUj2YIBQidwRsjHVyUGLpoIDGZRBLknuE9H+V/uSyMbZMiJq4QK6A+l 51ur4DZAHW9cb4QzwPQeF15b5x2GdKBpUMWgyTmjw0wum92Vq/C32WbZfWz2GBsQtlyz QKdYCbGvO8TcMQ7m8z+aUv4zrpoiolf/FqvLnexeSvkqsbk0SF0hc/T0fYt0bFOI3DAQ BqSVmXPkRYdLZEiLMFzr8GEdDbTLWeWLUwGG81xhdeGd4QgC+Y7IRFVcg054FKDs3tOq BcmxU3OeYkgZd2hWxV/9jaIV3MY5RBVspftxufGL+YR1bqHx9EEmbiXhnOKCafiDbmIY hmUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dTFHKZJP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p11-v6si646733plr.644.2018.02.07.22.23.52; Wed, 07 Feb 2018 22:24:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dTFHKZJP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752110AbeBHGWP (ORCPT + 99 others); Thu, 8 Feb 2018 01:22:15 -0500 Received: from mail-oi0-f46.google.com ([209.85.218.46]:41504 "EHLO mail-oi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751995AbeBHGWO (ORCPT ); Thu, 8 Feb 2018 01:22:14 -0500 Received: by mail-oi0-f46.google.com with SMTP id m83so2580991oik.8; Wed, 07 Feb 2018 22:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yEm4eFy4ZjMQ9MgPoH148qE5xDk/T3mWyryM6ewRZ7U=; b=dTFHKZJPGRVW0HyZRHFLU9AvelqTryWp/vLJzSWQobRetCsTB0ZRFFBjq1IgwKJAvf RGvK0dUE0fLNJ8jxTJD7orEshoSk1wG/846OoGj9BIJT2K6Cols1a/hs7ZBmdkQk+R6c 6PntcnUXgZ5jrWylcPTDpaFLavYwbBz/TPhPHdNyOWlDNDSkdSgkog92989gPgZlfuuO Se4Jrprj3YQ3ZqWeNbXRUdPlJTZGLibk5b2LSI/e2Hd9FRXdlaERnIM8rD/AdTQADJmF Uy6AdqCVRbkC59sgvu2rfiMV0D/TJLVB1KfGIq01kbcwgmfqsyWxB1XEviSzs23sPJH3 XO6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yEm4eFy4ZjMQ9MgPoH148qE5xDk/T3mWyryM6ewRZ7U=; b=cg+DgbNA9mI70wRUY8xN6472+9Wc3WEh1wBg0ltFc3+wLHDl+YfcH28hk4t8W7m8r0 QL+9F/6dgFT/419lq31gP0b6Q+Jgo4JwT/lcokPiQZl+DRQTdnlWVUK6/my6ZQqPCVCF C69Y4A4GxX3kmMc87/xmDIMr+arWrxFzNIXVPeExHZRgp7IgazagRtgCbnm+izEg2twG AdQdvx4JDjDNdZ4yPBEn2ZDP7/KTKNr7q1VbDa6oMOvRy+cMVvOaSK+GPoPyiYa8kU0C 5gPUCRjtyrvlYdwhrXj0QNFkmHTRWBiXX8qFeoIB3+aPi2RHrLgTMPdiWy/DWnVgw42E 7yoA== X-Gm-Message-State: APf1xPB5ZMTqQtwsrIt86FveUMVyRZzPFQGQobu/OKC+OtjfYYOgXu+H WF67fNrz9PWtHigE4G1PRQ6Pam8TwGbsW77iWIQ= X-Received: by 10.202.88.139 with SMTP id m133mr6079123oib.161.1518070933350; Wed, 07 Feb 2018 22:22:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.10.129 with HTTP; Wed, 7 Feb 2018 22:22:13 -0800 (PST) In-Reply-To: References: <1517828686-29070-1-git-send-email-wanpengli@tencent.com> From: Wanpeng Li Date: Thu, 8 Feb 2018 14:22:13 +0800 Message-ID: Subject: Re: [PATCH] KVM: nVMX: Fix CR4 after VMLAUNCH/VMRESUME failure To: Jim Mattson Cc: kvm list , LKML , Radim Krcmar , Paolo Bonzini Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-02-08 0:57 GMT+08:00 Jim Mattson : > vmcs12->host_cr[34] does not contain the up-to-date values when L1 is > running. L1 can vmwrite any values there. We know at this point that It will incur a vmexit to emulate L1 vmwrites vmcs12->host_cr[34] even if vmcs shadow is enabled since host_cr[34] is not shadowed in the bitmap, why it is not up-to-date when L1 is running? Regards, Wanpeng Li > they are legal (because we checked them), but that's about it. If the > VMLAUNCH/VMRESUME of vmcs12 fails for "invalid control field," there > is no VM-exit from L2 to L1, and these fields are not loaded. Instead, > execution just falls through to the next instruction with VMFailValid > semantics. > > On Wed, Feb 7, 2018 at 12:31 AM, Wanpeng Li wrote: >> 2018-02-07 0:58 GMT+08:00 Jim Mattson : >>> On Mon, Feb 5, 2018 at 4:57 PM, Wanpeng Li wrote: >>> >>>> This is effective one, what I restore in this patch is >>>> achitectural/guest visible. >>> >>> This patch doesn't "restore" the guest visible CR4 to its value at the >>> time of VMLAUNCH/VMRESUME. It loads a new CR4 value from the vmcs12. >>> That behavior is incorrect. >> >> You have another pointing out about this. >> https://lkml.org/lkml/2018/2/5/518 vmcs12->host_cr3/host_cr4 has the >> up-to-date value when L1 is running, it is still up-to-date after >> vmexit due to L1 executes VMLAUNCH/VMRESUME, I think the value stays >> the same before L0 emulates the VMLAUNCH/VMRESUME, according to below >> comments, why vmcs12->host_cr3/cr4 is not the value which we should >> restore? >> >> * After an early L2 VM-entry failure, we're now back >> * in L1 which thinks it just finished a VMLAUNCH or >> * VMRESUME instruction >> >> Regards, >> Wanpeng Li