From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, rkrcmar@redhat.com,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
xiaoguangrong@tencent.com, joro@8bytes.org
Subject: Re: [PATCH v1 3/4] KVM: MMU: Add 5 level EPT & Shadow page table support.
Date: Mon, 14 Aug 2017 19:37:20 +0800 [thread overview]
Message-ID: <22052f76-f8b3-d18c-f21a-4cb367f90993@linux.intel.com> (raw)
In-Reply-To: <04271af0-e735-022b-fb22-4d39bf32b01b@redhat.com>
Thanks a lot for your comments, Paolo. :-)
On 8/14/2017 3:31 PM, Paolo Bonzini wrote:
> On 12/08/2017 15:35, Yu Zhang wrote:
>> struct rsvd_bits_validate {
>> - u64 rsvd_bits_mask[2][4];
>> + u64 rsvd_bits_mask[2][5];
>> u64 bad_mt_xwr;
>> };
>
> Can you change this 4 to PT64_ROOT_MAX_LEVEL in patch 2?
Well, I had tried, but failed to find a neat approach to do so.
The difficulty I have met is that PT64_ROOT_MAX_LEVEL is defined
together with
PT64_ROOT_4LEVEL/PT32E_ROOT_LEVEL/PT32_ROOT_LEVEL in mmu.h, yet the
rsvd_bits_validate structure is defined in kvm_host.h, which are
included in quite
a lot .c files that do not include mmu.h or include the mmu.h after
kvm_host.h.
I guess that's the reason why the magic number 4 instead of PT64_ROOT_4LEVEL
is used in current definition of rsvd_bits_vadlidate. :-)
>
>> - if (vcpu->arch.mmu.shadow_root_level == PT64_ROOT_4LEVEL &&
>> - (vcpu->arch.mmu.root_level == PT64_ROOT_4LEVEL ||
>> - vcpu->arch.mmu.direct_map)) {
>> + if (vcpu->arch.mmu.root_level >= PT64_ROOT_4LEVEL ||
>> + vcpu->arch.mmu.direct_map) {
>> hpa_t root = vcpu->arch.mmu.root_hpa;
> You should keep the check on shadow_root_level (changing it to >= of
> course), otherwise you break the case where EPT is disabled, paging is
> disabled (so vcpu->arch.mmu.direct_map is true) and the host kernel is
> 32-bit. In that case shadow pages use PAE format, and entering this
> branch is incorrect.
Oh, right. Thanks!
>
>> @@ -4444,7 +4457,7 @@ void kvm_init_shadow_ept_mmu(struct kvm_vcpu *vcpu, bool execonly,
>>
>> MMU_WARN_ON(VALID_PAGE(context->root_hpa));
>>
>> - context->shadow_root_level = kvm_x86_ops->get_tdp_level();
>> + context->shadow_root_level = kvm_x86_ops->get_tdp_level(vcpu);
>>
>> context->nx = true;
>> context->ept_ad = accessed_dirty;
> Below, there is:
>
> context->root_level = context->shadow_root_level;
>
> this should be forced to PT64_ROOT_4LEVEL until there is support for
> nested EPT 5-level page tables.
So the context->shadow_root_level could be 5 or 4, and
context->root_level is always 4?
My understanding is that shadow ept level should be determined by the
width of ngpa,
and that if L1 guest is not exposed with EPT5 feature, it shall only use
4 level ept for L2
guest, and the shadow ept does not need a 5 level one. Is this
understanding correct?
And how about we set both values to PT64_ROOT_4LEVEL for now?
Besides, if we wanna support nested EPT5, what do you think we need to
do besides exposing
the EPT5 feature to L1 guest?
Thanks
Yu
>
> Thanks,
>
> Paolo
>
next prev parent reply other threads:[~2017-08-14 11:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-12 13:35 [PATCH v1 0/4] KVM: MMU: 5 level EPT/shadow support Yu Zhang
2017-08-12 13:35 ` [PATCH v1 1/4] KVM: MMU: check guest CR3 reserved bits based on its physical address width Yu Zhang
2017-08-14 7:36 ` Paolo Bonzini
2017-08-14 11:39 ` Yu Zhang
2017-08-14 16:13 ` Jim Mattson
2017-08-14 16:40 ` Paolo Bonzini
2017-08-15 7:50 ` Yu Zhang
2017-08-12 13:35 ` [PATCH v1 2/4] KVM: MMU: Rename PT64_ROOT_LEVEL to PT64_ROOT_4LEVEL Yu Zhang
2017-08-12 13:35 ` [PATCH v1 3/4] KVM: MMU: Add 5 level EPT & Shadow page table support Yu Zhang
2017-08-14 7:31 ` Paolo Bonzini
2017-08-14 11:37 ` Yu Zhang [this message]
2017-08-14 14:13 ` Paolo Bonzini
2017-08-14 14:32 ` Yu Zhang
2017-08-14 15:02 ` Paolo Bonzini
2017-08-14 14:55 ` Yu Zhang
2017-08-12 13:35 ` [PATCH v1 4/4] KVM: MMU: Expose the LA57 feature to VM Yu Zhang
2017-08-17 11:57 ` Paolo Bonzini
2017-08-17 11:53 ` Yu Zhang
2017-08-17 14:29 ` Paolo Bonzini
2017-08-18 8:28 ` Yu Zhang
2017-08-18 12:50 ` Paolo Bonzini
2017-08-21 7:27 ` Yu Zhang
2017-08-21 10:12 ` Paolo Bonzini
2017-08-21 12:11 ` Yu Zhang
2017-08-14 7:32 ` [PATCH v1 0/4] KVM: MMU: 5 level EPT/shadow support Paolo Bonzini
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=22052f76-f8b3-d18c-f21a-4cb367f90993@linux.intel.com \
--to=yu.c.zhang@linux.intel.com \
--cc=hpa@zytor.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=xiaoguangrong@tencent.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.