All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, mlevitsk@redhat.com
Subject: Re: [PATCH v3] KVM: MMU: update comment on the number of page role combinations
Date: Thu, 18 Nov 2021 16:49:40 +0000	[thread overview]
Message-ID: <YZaEJDRXrN5W20sk@google.com> (raw)
In-Reply-To: <20211118114039.1733976-1-pbonzini@redhat.com>

On Thu, Nov 18, 2021, Paolo Bonzini wrote:
> Fix the number of bits in the role, and simplify the explanation of
> why several bits or combinations of bits are redundant.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  arch/x86/include/asm/kvm_host.h | 32 ++++++++++++++++++++------------
>  1 file changed, 20 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 6ac61f85e07b..55f280e96b59 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -291,19 +291,27 @@ struct kvm_kernel_irq_routing_entry;
>   * the number of unique SPs that can theoretically be created is 2^n, where n
>   * is the number of bits that are used to compute the role.
>   *
> - * But, even though there are 18 bits in the mask below, not all combinations
> - * of modes and flags are possible.  The maximum number of possible upper-level
> - * shadow pages for a single gfn is in the neighborhood of 2^13.
> + * There are 19 bits in the mask below, and the page tracking code only uses
> + * 16 bits per gfn in kvm_arch_memory_slot to count whether a page is tracked.
> + * However, not all combinations of modes and flags are possible.  First
> + * of all, invalid shadow pages pages are not accounted, and "smm" is constant
> + * in a given memslot (because memslots are per address space, and SMM uses
> + * a separate address space).  Of the remaining 2^17 possibilities:
>   *
> - *   - invalid shadow pages are not accounted.
> - *   - level is effectively limited to four combinations, not 16 as the number
> - *     bits would imply, as 4k SPs are not tracked (allowed to go unsync).
> - *   - level is effectively unused for non-PAE paging because there is exactly
> - *     one upper level (see 4k SP exception above).
> - *   - quadrant is used only for non-PAE paging and is exclusive with
> - *     gpte_is_8_bytes.
> - *   - execonly and ad_disabled are used only for nested EPT, which makes it
> - *     exclusive with quadrant.
> + *   - quadrant will only be used if gpte_is_8_bytes=0 (non-PAE paging);
> + *     execonly and ad_disabled are only used for nested EPT which has
> + *     gpte_is_8_bytes=1.  Therefore, 2 bits are always unused.

Since we're already out behind the bikeshed... :-) 

Maybe instead of "always unused", pharse it as "Therefore, 2 bits (quadrant or
execonly+ad_disabled) are constant".  The bits are still used in the sense that
they do key the role, they're just guaranteed to be zero.

> + *   - the 4 bits of level are effectively limited to the values 2/3/4/5,
> + *     as 4k SPs are not tracked (allowed to go unsync).  In addition non-PAE
> + *     paging has exactly one upper level, making level completely redundant
> + *     when gpte_is_8_bytes=0.
> + *
> + *   - on top of this, smep_andnot_wp and smap_andnot_wp are only set if
> + *     cr0_wp=0, therefore these three bits only give rise to 5 possibilities.

Ah, I missed the opportunity to shave those bits.  Nice!

> + *
> + * Therefore, the maximum number of possible upper-level shadow pages for a
> + * given (as_id, gfn) pair is a bit less than 2^12.

With the unused/constant change,

Reviewed-by: Sean Christopherson <seanjc@google.com>

>   */
>  union kvm_mmu_page_role {
>  	u32 word;
> -- 
> 2.27.0
> 

      reply	other threads:[~2021-11-18 16:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-18 11:40 [PATCH v3] KVM: MMU: update comment on the number of page role combinations Paolo Bonzini
2021-11-18 16:49 ` Sean Christopherson [this message]

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=YZaEJDRXrN5W20sk@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlevitsk@redhat.com \
    --cc=pbonzini@redhat.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.