Received-SPF: pass (google.com: domain of linux-kernel+bounces-85503-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Wed, 28 Feb 2024 10:04:47 -0800
In-Reply-To: <CABgObfaPRpEnndHwkZpOZ=JOZjJPyh2KXYLh5ZGMFMSboZqj9w@mail.gmail.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240227232100.478238-1-pbonzini@redhat.com> <Zd6LK7RpZZ8t-5CY@google.com>
 <CABgObfYpRJnDdQrxp=OgjhbT9A+LHK36MHjMvzcQJsHAmfX++w@mail.gmail.com>
 <Zd9hrfJ5xRI6HeZp@google.com> <CABgObfaPRpEnndHwkZpOZ=JOZjJPyh2KXYLh5ZGMFMSboZqj9w@mail.gmail.com>
Message-ID: <Zd91v2DeQmV0yQ1R@google.com>
Subject: Re: [PATCH 00/21] TDX/SNP part 1 of n, for 6.9
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, michael.roth@amd.com, 
	isaku.yamahata@intel.com, thomas.lendacky@amd.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 28, 2024, Paolo Bonzini wrote:
> On Wed, Feb 28, 2024 at 5:39=E2=80=AFPM Sean Christopherson <seanjc@googl=
e.com> wrote:
> > > > This doesn't work.  The ENC flag gets set on any SNP *capable* CPU,=
 which results
> > > > in false positives for SEV and SEV-ES guests[*].
> > >
> > > You didn't look at the patch did you? :)
> >
> > Guilty, sort of.  I looked (and tested) the patch from the TDX series, =
but I didn't
> > look at what you postd.  But it's a moot point, because now I did look =
at what you
> > posted, and it's still broken :-)
> >
> > > It does check for has_private_mem (alternatively I could have dropped=
 the bit
> > > in SVM code for SEV and SEV-ES guests).
> >
> > The problem isn't with *KVM* setting the bit, it's with *hardware* sett=
ing the
> > bit for SEV and SEV-ES guests.  That results in this:
> >
> >   .is_private =3D vcpu->kvm->arch.has_private_mem && (err & PFERR_GUEST=
_ENC_MASK),
> >
> > marking the fault as private.  Which, in a vacuum, isn't technically wr=
ong, since
> > from hardware's perspective the vCPU access was "private".  But from KV=
M's
> > perspective, SEV and SEV-ES guests don't have private memory
>=20
> vcpu->kvm->arch.has_private_mem is the flag from the SEV VM types
> series. It's false on SEV and SEV-ES VMs, therefore fault->is_private
> is going to be false as well. Is it ENOCOFFEE for you or ENODINNER for
> me? :)

*sigh*, ENOCOFFEE.