Re: [PATCH] KVM: selftests: Create memslot 0 at GPA 0x100000000 on x86_64

From: Sean Christopherson <seanjc@google.com>
To: David Matlack <dmatlack@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Fuad Tabba <tabba@google.com>,  Peter Gonda <pgonda@google.com>,
	Ackerley Tng <ackerleytng@google.com>,
	 Chao Peng <chao.p.peng@linux.intel.com>,
	Vishal Annapurve <vannapurve@google.com>,
	 Michael Roth <michael.roth@amd.com>,
	Andrew Jones <ajones@ventanamicro.com>,
	kvm@vger.kernel.org,  nrb@linux.ibm.com
Subject: Re: [PATCH] KVM: selftests: Create memslot 0 at GPA 0x100000000 on x86_64
Date: Fri, 15 Mar 2024 10:25:42 -0700	[thread overview]
Message-ID: <ZfSEliJnY5u7y5uT@google.com> (raw)
In-Reply-To: <CALzav=cLRJOtCyY+DVRWBxBMaV5S8Cy9bBKxmfdUhGLwS0+_6A@mail.gmail.com>

On Fri, Mar 15, 2024, David Matlack wrote:
> On Thu, Mar 14, 2024 at 4:14 PM Sean Christopherson <seanjc@google.com> wrote:
> > > >   5. Use separate memslots for CODE, DATA, and PT by default.  This will allow
> > > >      for more precise sizing of the CODE and DATA slots.
> > >
> > > What do you mean by "[separate memslots] will allow for more precise sizing"?
> >
> > I suspect there is a _lot_ of slop in the arbitrary 512 pages that are tacked on
> > by vm_nr_pages_required().  Those 2MiBs probably don't matter, I just don't like
> > completely magical numbers.
> 
> That makes sense, we can probably tighten up those heuristics and
> maybe even get rid of the magic numbers. But I wasn't following what
> _separate memslots_ has to do with it?

Ah, don't dwell on that too much, it was somewhat of a passing thought.

My thinking was that the gorilla math for the page tables makes it hard to determine
how much of those 512 pages is actually for DATA, versus how much is actually a
weird recursive calculation for the page tables themselves.  I.e. it's hard to
trim down @nr_pages, because it might no be easy to tell if DATA shrank too much,
or if it actually caused to PT to shrink too much, and so no one touches that mess.