public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	 "hao.p.peng@linux.intel.com" <hao.p.peng@linux.intel.com>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Isaku Yamahata <isaku.yamahata@intel.com>
Subject: Re: [PATCH] KVM: x86/mmu: x86: Don't overflow lpage_info when checking attributes
Date: Wed, 13 Mar 2024 14:11:59 -0700	[thread overview]
Message-ID: <ZfIWnykN1XG-8TlC@google.com> (raw)
In-Reply-To: <a5fd2f03c453962bd54db81ae18d3c2b8b7cf7b1.camel@intel.com>

On Wed, Mar 13, 2024, Rick P Edgecombe wrote:
> 2. lpage_info doesn't need to keep track of unaligned heads and tails
> because the unaligned part can never be huge. lpage_info_slot() can
> skip checking the array based on the slot, GFN and page size which it
> already has. Allocating kvm_lpage_info's for those and then carefully
> making sure they are always disabled adds complexity (especially with
> KVM_LPAGE_MIXED_FLAG in the mix) and uses extra memory. Whether it's a
> tiny bit faster that a conditional in a helper, I don't know.

I wouldn't prioritize speed, I would prioritize overall complexity.  And my gut
reaction is that the overall complexity would go up because we'd need to make
multiple paths aware that lpage_info could be NULL.  There are other side effects
to making something conditionally valid too, e.g. in the unlikely scenario where
we mucked up the allocation, KVM would silently fall back to 4KiB mappings, versus
today KVM would explode (bad for production, but good for development).

  reply	other threads:[~2024-03-13 21:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-12 17:33 [PATCH] KVM: x86/mmu: x86: Don't overflow lpage_info when checking attributes Rick Edgecombe
2024-03-13  9:49 ` Dongli Zhang
2024-03-13 16:25   ` Edgecombe, Rick P
2024-03-13 21:27     ` Dongli Zhang
2024-03-13 19:55 ` Sean Christopherson
2024-03-13 20:17   ` Edgecombe, Rick P
2024-03-13 21:11     ` Sean Christopherson [this message]
2024-03-13 21:23       ` Edgecombe, Rick P

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=ZfIWnykN1XG-8TlC@google.com \
    --to=seanjc@google.com \
    --cc=hao.p.peng@linux.intel.com \
    --cc=isaku.yamahata@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rick.p.edgecombe@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