Received-SPF: pass (google.com: domain of linux-kernel+bounces-149279-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Wed, 17 Apr 2024 15:26:36 -0700
In-Reply-To: <CABgObfaoVMzEhu6O5HPe=GXH-bCkpTwSy8Ji0a1=je6f3eSqRQ@mail.gmail.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240417153450.3608097-1-pbonzini@redhat.com> <20240417153450.3608097-6-pbonzini@redhat.com>
 <ZiA-DQi52hroCSZ8@google.com> <CABgObfaoVMzEhu6O5HPe=GXH-bCkpTwSy8Ji0a1=je6f3eSqRQ@mail.gmail.com>
Message-ID: <ZiBMnHoyMsoRhLAL@google.com>
Subject: Re: [PATCH 5/7] KVM: x86/mmu: Introduce kvm_tdp_map_page() to
 populate guest memory
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, 
	isaku.yamahata@intel.com, xiaoyao.li@intel.com, binbin.wu@linux.intel.com, 
	rick.p.edgecombe@intel.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 17, 2024, Paolo Bonzini wrote:
> On Wed, Apr 17, 2024 at 11:24=E2=80=AFPM Sean Christopherson <seanjc@goog=
le.com> wrote:
> > Do we want to restrict this to the TDP MMU?  Not for any particular rea=
son,
> > mostly just to keep moving towards officially deprecating/removing TDP
> > support from the shadow MMU.
>=20
> Heh, yet another thing I briefly thought about while reviewing Isaku's
> work. In the end I decided that, with the implementation being just a
> regular prefault, there's not much to save from keeping the shadow MMU
> away from this.

Yeah.

> The real ugly part is that if the memslots are zapped the
> pre-population effect basically goes away (damn
> kvm_arch_flush_shadow_memslot).=20

Ah, the eternal thorn in my side.=20

> This is the reason why I initially thought of KVM_CHECK_EXTENSION for the=
 VM
> file descriptor, to only allow this for TDX VMs.

I'm fairly certain memslot deletion is mostly a QEMU specific problem.  All=
egedly
(I haven't verified), our userspace+firmware doesn't delete any memslots du=
ring
boot.

And it might even be solvable for QEMU, at least for some configurations.  =
E.g.
during boot, my QEMU+OVMF setup creates and deletes the SMRAM memslot (desp=
ite my
KVM build not supporting SMM), and deletes the lower RAM memslot when reloc=
ating
BIOS.  The SMRAM is definitely solvable, and the BIOS relocation stuff seem=
s like
it's solvable too.