public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: Robert Hoo <robert.hu@linux.intel.com>
Cc: <seanjc@google.com>, <pbonzini@redhat.com>,
	<yu.c.zhang@linux.intel.com>, <yuan.yao@linux.intel.com>,
	<jingqi.liu@intel.com>, <weijiang.yang@intel.com>,
	<isaku.yamahata@intel.com>, <kirill.shutemov@linux.intel.com>,
	<kvm@vger.kernel.org>
Subject: Re: [PATCH v4 7/9] KVM: x86: When guest set CR3, handle LAM bits semantics
Date: Tue, 14 Feb 2023 14:48:16 +0800	[thread overview]
Message-ID: <Y+susAC6ZshFEdpn@gao-cwp> (raw)
In-Reply-To: <8ece08328b0ab07303140b9b731e252cfdb38b1f.camel@linux.intel.com>

On Tue, Feb 14, 2023 at 01:28:33PM +0800, Robert Hoo wrote:
>> > +
>> > 	/*
>> > 	 * Do not condition the GPA check on long mode, this helper is
>> > used to
>> > 	 * stuff CR3, e.g. for RSM emulation, and there is no guarantee
>> > that
>> > @@ -1268,8 +1272,20 @@ int kvm_set_cr3(struct kvm_vcpu *vcpu,
>> > unsigned long cr3)
>> > 	if (is_pae_paging(vcpu) && !load_pdptrs(vcpu, cr3))
>> > 		return 1;
>> > 
>> > -	if (cr3 != kvm_read_cr3(vcpu))
>> > -		kvm_mmu_new_pgd(vcpu, cr3);
>> > +	old_cr3 = kvm_read_cr3(vcpu);
>> > +	if (cr3 != old_cr3) {
>> > +		if ((cr3 ^ old_cr3) & CR3_ADDR_MASK) {
>> 
>This means those effective addr bits changes, then no matter LAM bits
>toggled or not, it needs new pgd.
>
>> Does this check against CR3_ADDR_MASK necessarily mean LAM bits are
>> toggled, i.e., CR3_ADDR_MASK == ~(X86_CR3_LAM_U48 | X86_CR3_LAM_U57)?
>> 
>> Why not check if LAM bits are changed? This way the patch only
>> changes
>> cases related to LAM, keeping other cases intact.
>
>Yes, I can better to add check in "else" that LAM bits changes.
>But in fact above kvm_is_valid_cr3() has guaranteed no other high order
>bits changed.
>Emm, now you might ask to melt LAM bits into vcpu-
>>arch.reserved_gpa_bits? ;)

no. I am not asking for that.

My point is for example, bit X isn't in CR3_ADDR_MASK. then toggling
the bit X will go into the else{} branch, which is particularly for LAM
bits. So, the change is correct iff

	CR3_ADDR_MASK = ~(X86_CR3_LAM_U48 | X86_CR3_LAM_U57).

I didn't check if that is true on your code base. If it isn't, replace
CR3_ADDR_MASK with ~(X86_CR3_LAM_U48 | X86_CR3_LAM_U57).

>> 
>> > +			kvm_mmu_new_pgd(vcpu, cr3 & ~(X86_CR3_LAM_U48 |
>> > +					X86_CR3_LAM_U57));
>> 
>> Do you need to touch kvm_mmu_new_pgd() in nested_vmx_load_cr3()?
>
>Didn't scope nested LAM case in this patch set.

Is there any justificaiton for not considering nested virtualization?
Won't nested virtualization be broken by this series?


  reply	other threads:[~2023-02-14  6:48 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-09  2:40 [PATCH v4 0/9] Linear Address Masking (LAM) KVM Enabling Robert Hoo
2023-02-09  2:40 ` [PATCH v4 1/9] KVM: x86: Intercept CR4.LAM_SUP when LAM feature is enabled in guest Robert Hoo
2023-02-09  9:21   ` Chao Gao
2023-02-09 12:48     ` Robert Hoo
2023-02-10  3:29   ` Yang, Weijiang
2023-02-10  5:02     ` Robert Hoo
2023-02-10 16:30       ` Sean Christopherson
2023-02-14  1:27   ` Binbin Wu
2023-02-14  6:11     ` Robert Hoo
2023-02-14  9:00       ` Binbin Wu
2023-02-14 12:24         ` Robert Hoo
2023-02-14 12:36           ` Robert Hoo
2023-02-16  5:31           ` Binbin Wu
2023-02-16  5:54             ` Robert Hoo
2023-02-09  2:40 ` [PATCH v4 2/9] KVM: x86: MMU: Clear CR3 LAM bits when allocate shadow root Robert Hoo
2023-02-09  9:55   ` Chao Gao
2023-02-09 13:02     ` Robert Hoo
2023-02-14  2:55       ` Binbin Wu
2023-02-15  1:17         ` Robert Hoo
2023-02-16  2:14         ` Robert Hoo
2023-02-10  3:38   ` Yang, Weijiang
2023-02-11  3:12     ` Robert Hoo
2023-02-09  2:40 ` [PATCH v4 3/9] KVM: x86: MMU: Commets update Robert Hoo
2023-02-10  6:59   ` Chao Gao
2023-02-10  7:55     ` Robert Hoo
2023-02-10 16:54       ` Sean Christopherson
2023-02-09  2:40 ` [PATCH v4 4/9] KVM: x86: MMU: Integrate LAM bits when build guest CR3 Robert Hoo
2023-02-10 14:04   ` Chao Gao
2023-02-11  6:24     ` Robert Hoo
2023-02-11  6:29       ` Robert Hoo
2023-02-09  2:40 ` [PATCH v4 5/9] KVM: x86: Untag LAM bits when applicable Robert Hoo
2023-02-10 15:04   ` Chao Gao
2023-02-11  5:57     ` Robert Hoo
2023-02-16  6:37       ` Binbin Wu
2023-02-09  2:40 ` [PATCH v4 6/9] KVM: x86: When KVM judges CR3 valid or not, consider LAM bits Robert Hoo
2023-02-13  2:01   ` Chao Gao
2023-02-13 13:25     ` Robert Hoo
2023-02-14  6:18       ` Chao Gao
2023-02-14  7:00         ` Chao Gao
2023-02-18  5:44         ` Robert Hoo
2023-02-09  2:40 ` [PATCH v4 7/9] KVM: x86: When guest set CR3, handle LAM bits semantics Robert Hoo
2023-02-13  3:31   ` Chao Gao
2023-02-14  5:28     ` Robert Hoo
2023-02-14  6:48       ` Chao Gao [this message]
2023-02-09  2:40 ` [PATCH v4 8/9] KVM: x86: emulation: Apply LAM when emulating data access Robert Hoo
2023-02-13  3:53   ` Chao Gao
2023-02-14  5:38     ` Robert Hoo
2023-02-09  2:40 ` [PATCH v4 9/9] KVM: x86: LAM: Expose LAM CPUID to user space VMM Robert Hoo
2023-02-21  5:47   ` Binbin Wu
2023-02-21  7:26     ` Robert Hoo
2023-02-21  8:26       ` Binbin Wu
2023-02-21 11:13         ` Yu Zhang
2023-02-21 13:18           ` Binbin Wu
2023-02-21 14:36             ` Robert Hoo
2023-02-09  6:15 ` [PATCH v4 0/9] Linear Address Masking (LAM) KVM Enabling Chao Gao
2023-02-09 12:25   ` Robert Hoo
2023-02-09 17:27     ` Sean Christopherson
2023-02-10  2:07       ` Robert Hoo
2023-02-10  3:17         ` Chao Gao
2023-02-10  8:41           ` Robert Hoo
2023-02-10  8:39         ` Robert Hoo
2023-02-10  9:22           ` Chao Gao
2023-02-13  9:02 ` Binbin Wu
2023-02-13 13:16   ` Robert Hoo

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=Y+susAC6ZshFEdpn@gao-cwp \
    --to=chao.gao@intel.com \
    --cc=isaku.yamahata@intel.com \
    --cc=jingqi.liu@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=robert.hu@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=weijiang.yang@intel.com \
    --cc=yu.c.zhang@linux.intel.com \
    --cc=yuan.yao@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox