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?
next prev parent 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