All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: "Huang, Kai" <kai.huang@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>, "Christopherson,,
	Sean" <seanjc@google.com>,
	"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
	"Guo, Xuelian" <xuelian.guo@intel.com>,
	"robert.hu@linux.intel.com" <robert.hu@linux.intel.com>
Subject: Re: [PATCH v7 2/5] KVM: x86: Virtualize CR3.LAM_{U48,U57}
Date: Sat, 22 Apr 2023 12:51:14 +0800	[thread overview]
Message-ID: <ZENnwtBzRVz14eS+@chao-email> (raw)
In-Reply-To: <ZEKsgceQo6MEWbB5@chao-email>

On Fri, Apr 21, 2023 at 11:32:17PM +0800, Chao Gao wrote:
>>For case 2) I _think_ we need new code to check both VMCS12's HOST_CR3 and
>>GUEST_CR3 against active control bits.  The key code path is 
>
>...
>
>>
>>	nested_vmx_run() -> 
>>		-> nested_vmx_check_host_state()
>>		-> nested_vmx_enter_non_root_mode()
>>			-> prepare_vmcs02_early()
>>			-> prepare_vmcs02()
>>
>>Since nested_vmx_load_cr3() is used in both VMENTER using VMCS12's HOST_CR3
>>(VMEXIT to L1) and GUEST_CR3 (VMENTER to L2), and it currently already checks
>>kvm_vcpu_is_illegal_gpa(vcpu, cr3), changing it to additionally check guest CR3
>>active control bits seems just enough.
>
>IMO, current KVM relies on hardware to do consistency check on the GUEST_CR3
>during VM entry.

Please disregard my remark on the consistency check on GUEST_CR3. I just took
a closer look at the code. It is indeed done by KVM in nested_vmx_load_cr3().
Sorry for the noise.

  reply	other threads:[~2023-04-22  4:51 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-04 13:09 [PATCH v7 0/5] Linear Address Masking (LAM) KVM Enabling Binbin Wu
2023-04-04 13:09 ` [PATCH v7 1/5] KVM: x86: Virtualize CR4.LAM_SUP Binbin Wu
2023-04-04 13:09 ` [PATCH v7 2/5] KVM: x86: Virtualize CR3.LAM_{U48,U57} Binbin Wu
2023-04-06 12:57   ` Huang, Kai
2023-04-09 11:36     ` Binbin Wu
2023-04-11 23:11       ` Huang, Kai
2023-04-12 11:58   ` Huang, Kai
2023-04-13  1:36     ` Binbin Wu
2023-04-13  2:27       ` Huang, Kai
2023-04-13  4:45         ` Binbin Wu
2023-04-13  9:13           ` Huang, Kai
2023-04-21  6:35             ` Binbin Wu
2023-04-21 11:43               ` Huang, Kai
2023-04-21 15:32                 ` Chao Gao
2023-04-22  4:51                   ` Chao Gao [this message]
2023-04-22  8:14                     ` Huang, Kai
2023-04-22  3:32                 ` Binbin Wu
2023-04-22  4:43                   ` Chao Gao
2023-04-27 13:19                     ` Huang, Kai
2023-04-29  4:56                       ` Binbin Wu
2023-04-25 22:48                   ` Huang, Kai
2023-04-26  3:05                     ` Chao Gao
2023-04-26  5:13                       ` Binbin Wu
2023-04-26  8:44                         ` Huang, Kai
2023-04-26  8:50                           ` Binbin Wu
2023-04-26  8:43                       ` Huang, Kai
2023-04-26 10:52                         ` Binbin Wu
2023-04-27 13:23                           ` Huang, Kai
2023-04-17  7:24   ` Chao Gao
2023-04-17  8:02     ` Binbin Wu
2023-04-04 13:09 ` [PATCH v7 3/5] KVM: x86: Introduce untag_addr() in kvm_x86_ops Binbin Wu
2023-04-18  3:08   ` Zeng Guang
2023-04-18  3:34     ` Binbin Wu
2023-04-19  2:30   ` Chao Gao
2023-04-19  3:08     ` Binbin Wu
2023-04-21  7:48       ` Binbin Wu
2023-04-21  8:21         ` Chao Gao
2023-04-04 13:09 ` [PATCH v7 4/5] KVM: x86: Untag address when LAM applicable Binbin Wu
2023-04-06 13:20   ` Huang, Kai
2023-04-10  3:35     ` Binbin Wu
2023-04-18  3:28   ` Zeng Guang
2023-04-18  3:38     ` Binbin Wu
2023-04-19  6:43   ` Chao Gao
2023-04-21  7:57     ` Binbin Wu
2023-04-21  8:36       ` Chao Gao
2023-04-21  9:13         ` Binbin Wu
2023-04-04 13:09 ` [PATCH v7 5/5] KVM: x86: Expose LAM feature to userspace VMM Binbin Wu
2023-04-21  9:40 ` [PATCH v7 0/5] Linear Address Masking (LAM) KVM Enabling Binbin Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZENnwtBzRVz14eS+@chao-email \
    --to=chao.gao@intel.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=kai.huang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=robert.hu@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=xuelian.guo@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.