Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Kenta Akagi" <k@mgml.me>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 5.15.y v4 03/11] KVM: MMU: update comment on the number of page role combinations
Date: Mon, 28 Sep 2026 16:52:12 +0000	[thread overview]
Message-ID: <20260928165213.054851F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260928164427.4699-4-k@mgml.me>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] kvm: mmu: incorrect comment on page role bit count
--

commit e43e6a4b81c3f6c9da7c094b704c3a172f16148a
Author: Paolo Bonzini <pbonzini@redhat.com>

KVM: MMU: update comment on the number of page role combinations

This commit updates the comment explaining the kvm_mmu_page_role bitmask
to clarify why certain bit combinations are redundant.

> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 710c9c87cdf2e..2c378064a1db9 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -292,19 +292,25 @@ 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.
> + * But, even though there are 19 bits in the mask below, not all combinations
> + * of modes and flags are possible:
>   *
> - *   - 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.
> + *   - invalid shadow pages are not accounted, so the bits are effectively 18
> + *
> + *   - 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.

[Severity: Low]
Is this updated comment accurate for the current struct definition? The text
claims there are 19 bits in the mask and references an execonly bit.

However, looking at the union kvm_mmu_page_role definition immediately
following this comment:

union kvm_mmu_page_role {
	u32 word;
	struct {
		unsigned level:4;
		unsigned gpte_is_8_bytes:1;
		unsigned quadrant:2;
		unsigned direct:1;
		unsigned access:3;
		unsigned invalid:1;
		unsigned efer_nx:1;
		unsigned cr0_wp:1;
		unsigned smep_andnot_wp:1;
		unsigned smap_andnot_wp:1;
		unsigned ad_disabled:1;
		unsigned guest_mode:1;
        ...

Summing these bitfields yields exactly 18 bits, and the execonly bit appears
to be missing, having been moved to kvm_mmu_extended_role.

Could the mathematical breakdown in the comment be adjusted to reflect the
actual 18 bits present in the structure?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928164427.4699-1-k@mgml.me?part=3

  reply	other threads:[~2026-09-28 16:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28 16:44 [PATCH 5.15.y v4 00/11] KVM: fixes for CVE-2026-46113 and related issues Kenta Akagi
2026-09-28 16:44 ` [PATCH 5.15.y v4 01/11] KVM: x86/mmu: Use a bool for direct Kenta Akagi
2026-09-28 16:44 ` [PATCH 5.15.y v4 02/11] KVM: x86/mmu: Stop passing "direct" to mmu_alloc_root() Kenta Akagi
2026-09-28 16:44 ` [PATCH 5.15.y v4 03/11] KVM: MMU: update comment on the number of page role combinations Kenta Akagi
2026-09-28 16:52   ` sashiko-bot [this message]
2026-09-28 16:44 ` [PATCH 5.15.y v4 04/11] KVM: X86: Remove useless code to set role.gpte_is_8_bytes when role.direct Kenta Akagi
2026-09-28 16:44 ` [PATCH 5.15.y v4 05/11] KVM: X86: Calculate quadrant when !role.gpte_is_8_bytes Kenta Akagi
2026-09-28 16:44 ` [PATCH 5.15.y v4 06/11] KVM: X86: Rename gpte_is_8_bytes to has_4_byte_gpte and invert the direction Kenta Akagi
2026-09-28 16:55   ` sashiko-bot
2026-09-28 16:44 ` [PATCH 5.15.y v4 07/11] KVM: x86/mmu: Derive shadow MMU page role from parent Kenta Akagi
2026-09-28 16:44 ` [PATCH 5.15.y v4 08/11] KVM: x86/mmu: Always pass 0 for @quadrant when gptes are 8 bytes Kenta Akagi
2026-09-28 16:44 ` [PATCH 5.15.y v4 09/11] KVM: x86/mmu: pull call to drop_large_spte() into __link_shadow_page() Kenta Akagi
2026-09-28 16:44 ` [PATCH 5.15.y v4 10/11] KVM: x86: Fix shadow paging use-after-free due to unexpected GFN Kenta Akagi
2026-09-28 16:44 ` [PATCH 5.15.y v4 11/11] KVM: x86: Fix shadow paging use-after-free due to unexpected role Kenta Akagi
2026-09-28 18:28 ` [PATCH 5.15.y v4 00/11] KVM: fixes for CVE-2026-46113 and related issues Sean Christopherson
2026-09-28 22:39 ` Sasha Levin

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=20260928165213.054851F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=k@mgml.me \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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