Received-SPF: pass (google.com: domain of linux-kernel+bounces-210569-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Tue, 11 Jun 2024 13:18:59 -0700
In-Reply-To: <f2cd7136-889d-4a3c-b029-07a8c18ef589@intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240509075423.156858-1-weijiang.yang@intel.com>
 <20240509075423.156858-2-weijiang.yang@intel.com> <ZmelpPm5YfGifhIj@google.com>
 <f2cd7136-889d-4a3c-b029-07a8c18ef589@intel.com>
Message-ID: <ZmixMxni_YOysAuz@google.com>
Subject: Re: [RFC PATCH 2/2] KVM: x86: Enable guest SSP read/write interface
 with new uAPIs
From: Sean Christopherson <seanjc@google.com>
To: Weijiang Yang <weijiang.yang@intel.com>
Cc: pbonzini@redhat.com, mlevitsk@redhat.com, kvm@vger.kernel.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 11, 2024, Weijiang Yang wrote:
> On 6/11/2024 9:17 AM, Sean Christopherson wrote:
> > On Thu, May 09, 2024, Yang Weijiang wrote:
> > Aha!  And then to prepare for a future where we add synthetic registers=
 that
> > aren't routed through the MSR framework (which seems unlikely, but its =
trivially
> > easy to handle, so why not):
> >=20
> > static int kvm_translate_synthetic_reg(struct kvm_x86_reg_id *reg)
> > {
> > 	switch (reg->index) {
> > 	case MSR_KVM_GUEST_SSP:
> > 		reg->type =3D KVM_X86_REG_MSR;
> > 		reg->index =3D MSR_KVM_INTERNAL_GUEST_SSP;
> > 		break;
> > 	default:
> > 		return -EINVAL;
> > 	}
> > 	return 0;
> > }
> >=20
> > and then the caller would have slightly different ordering:
> >=20
> >          if (id->type =3D=3D KVM_X86_REG_SYNTHETIC_MSR) {
> >                  r =3D kvm_translate_synthetic_msr(&id->index);
> >                  if (r)
> >                          break;
> >          }
> >=20
> >          r =3D -EINVAL;
> >          if (id->type !=3D KVM_X86_REG_MSR)
> >                  break;
> I assume reg->type translation for GUEST_SSP is due to the fact it relies=
 on
> CET common checking stuffs underneath for the register, i.e., it goes thr=
ough
> existing MSR framework. But for future other synthetic MSRs, it needs to

Nit, other synthetic *registers*.

> refactor the code here so that it could be routed into new handling.  e.g=
.:
>=20
> if (id->type =3D=3D KVM_X86_REG_MSR)
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 go through MSR framework;
> else
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 go through other new handling;
>=20
> But currently the new uAPIs are only for GUEST_SSP, so above suggested
> id->type check works.  Does it make sense?

Yep, we're on the same page.