Received-SPF: pass (google.com: domain of linux-kernel+bounces-145990-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Mon, 15 Apr 2024 15:59:11 -0700
In-Reply-To: <8959c330e47aa78b97bdca6e8beae11697c15908.camel@intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <cover.1712785629.git.isaku.yamahata@intel.com>
 <2f1de1b7b6512280fae4ac05e77ced80a585971b.1712785629.git.isaku.yamahata@intel.com>
 <116179545fafbf39ed01e1f0f5ac76e0467fc09a.camel@intel.com>
 <Zh2ZTt4tXXg0f0d9@google.com> <8959c330e47aa78b97bdca6e8beae11697c15908.camel@intel.com>
Message-ID: <Zh2xPwGAMMgqKeYV@google.com>
Subject: Re: [PATCH v2 07/10] KVM: x86: Always populate L1 GPA for KVM_MAP_MEMORY
From: Sean Christopherson <seanjc@google.com>
To: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: Kai Huang <kai.huang@intel.com>, 
	"federico.parola@polito.it" <federico.parola@polito.it>, 
	"isaku.yamahata@gmail.com" <isaku.yamahata@gmail.com>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "dmatlack@google.com" <dmatlack@google.com>, 
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, Isaku Yamahata <isaku.yamahata@intel.com>, 
	"pbonzini@redhat.com" <pbonzini@redhat.com>, "michael.roth@amd.com" <michael.roth@amd.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 15, 2024, Rick P Edgecombe wrote:
> On Mon, 2024-04-15 at 14:17 -0700, Sean Christopherson wrote:
> > > But doesn't the fault handler need the vCPU state?
> >=20
> > Ignoring guest MTRRs, which will hopefully soon be a non-issue, no.=C2=
=A0 There are
> > only six possible roots if TDP is enabled:
> >=20
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1. 4-level !SMM !guest_mode
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2. 4-level=C2=A0 SMM !guest_mode
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3. 5-level !SMM !guest_mode
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4. 5-level=C2=A0 SMM !guest_mode
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5. 4-level !SMM guest_mode
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6. 5-level !SMM guest_mode
> >=20
> > 4-level vs. 5-level is a guest MAXPHYADDR thing, and swapping the MMU
> > eliminates the SMM and guest_mode issues.=C2=A0 If there is per-vCPU st=
ate that
> > makes its way into the TDP page tables, then we have problems, because =
it
> > means that there is per-vCPU state in per-VM structures that isn't
> > accounted for.
> >=20
> > There are a few edge cases where KVM treads carefully, e.g. if the faul=
t is
> > to the vCPU's APIC-access page, but KVM manually handles those to avoid
> > consuming per-vCPU state.
> >=20
> > That said, I think this option is effectively 1b, because dropping the =
SMM
> > vs.  guest_mode state has the same uAPI problems as forcibly swapping t=
he
> > MMU, it's just a different way of doing so.
> >=20
> > The first question to answer is, do we want to return an error or
> > "silently" install mappings for !SMM, !guest_mode.=C2=A0 And so this op=
tion
> > becomes relevant only _if_ we want to unconditionally install mappings =
for
> > the 'base" mode.
>=20
> Ah, I thought there was some logic around CR0.CD.

There is, but it's hopefully going the way of the dodo, along with full MTR=
R
virtualization:

https://lore.kernel.org/all/20240309010929.1403984-1-seanjc@google.com