Received-SPF: pass (google.com: domain of linux-kernel+bounces-180326-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Wed, 15 May 2024 12:48:22 -0700
In-Reply-To: <77ae4629139784e7239ce7c03db2c2db730ab4e9.camel@intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240515005952.3410568-1-rick.p.edgecombe@intel.com>
 <20240515005952.3410568-9-rick.p.edgecombe@intel.com> <ZkTWDfuYD-ThdYe6@google.com>
 <f64c7da52a849cd9697b944769c200dfa3ee7db7.camel@intel.com>
 <747192d5fe769ae5d28bbb6c701ee9be4ad09415.camel@intel.com>
 <ZkTcbPowDSLVgGft@google.com> <de3cb02ae9e639f423ae47ef2fad1e89aa9dd3d8.camel@intel.com>
 <ZkT4RC_l_F_9Rk-M@google.com> <77ae4629139784e7239ce7c03db2c2db730ab4e9.camel@intel.com>
Message-ID: <ZkURaxF57kybgMm0@google.com>
Subject: Re: [PATCH 08/16] KVM: x86/mmu: Bug the VM if kvm_zap_gfn_range() is
 called for TDX
From: Sean Christopherson <seanjc@google.com>
To: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "sagis@google.com" <sagis@google.com>, 
	"isaku.yamahata@gmail.com" <isaku.yamahata@gmail.com>, Erdem Aktas <erdemaktas@google.com>, 
	Yan Zhao <yan.y.zhao@intel.com>, "dmatlack@google.com" <dmatlack@google.com>, 
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, "pbonzini@redhat.com" <pbonzini@redhat.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 15, 2024, Rick P Edgecombe wrote:
> On Wed, 2024-05-15 at 11:09 -0700, Sean Christopherson wrote:
> > On Wed, May 15, 2024, Rick P Edgecombe wrote:
> > > On Wed, 2024-05-15 at 09:02 -0700, Sean Christopherson wrote:
> > > > > Or most specifically, we only need this zapping if we *try* to ha=
ve
> > > > > consistent cache attributes between private and shared. In the
> > > > > non-coherent DMA case we can't have them be consistent because TD=
X
> > > > > doesn't support changing the private memory in this way.
> > > >=20
> > > > Huh?=C2=A0 That makes no sense.=C2=A0 A physical page can't be simu=
ltaneously mapped
> > > > SHARED and PRIVATE, so there can't be meaningful cache attribute al=
iasing
> > > > between private and shared EPT entries.
> > > >=20
> > > > Trying to provide consistency for the GPA is like worrying about ha=
ving
> > > > matching PAT entires for the virtual address in two different proce=
sses.
> > >=20
> > > No, not matching between the private and shared mappings of the same =
page.
> > > The
> > > whole private memory will be WB, and the whole shared half will honor=
 PAT.
> >=20
> > I'm still failing to see why that's at all interesting.=C2=A0 The non-c=
oherent DMA
> > trainwreck is all about KVM worrying about the guest and host having di=
fferent
> > memtypes for the same physical page.
>=20
> Ok. The split seemed a little odd and special. I'm not sure it's the most
> interesting thing in the world, but there was some debate internally abou=
t it.
>=20
> >=20
> > If the host is accessing TDX private memory, we have far, far bigger pr=
oblems
> > than aliased memtypes.
>=20
> This wasn't the concern.
>=20
> > =C2=A0 And so the fact that TDX private memory is forced WB is
> > interesting only to the guest, not KVM.
>=20
> It's just another little quirk in an already complicated solution. They t=
hird
> thing we discussed was somehow rejecting or not supporting non-coherent D=
MA.
> This seemed simpler than that.

Again, huh?  This has _nothing_ to do with non-coherent DMA.  Devices can't=
 DMA
into TDX private memory.