Re: [RFC PATCH 2/2] KVM: x86: Enable guest SSP read/write interface with new uAPIs

[Sean Christopherson <seanjc@google.com>]

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):
> > 
> > static int kvm_translate_synthetic_reg(struct kvm_x86_reg_id *reg)
> > {
> > 	switch (reg->index) {
> > 	case MSR_KVM_GUEST_SSP:
> > 		reg->type = KVM_X86_REG_MSR;
> > 		reg->index = MSR_KVM_INTERNAL_GUEST_SSP;
> > 		break;
> > 	default:
> > 		return -EINVAL;
> > 	}
> > 	return 0;
> > }
> > 
> > and then the caller would have slightly different ordering:
> > 
> >          if (id->type == KVM_X86_REG_SYNTHETIC_MSR) {
> >                  r = kvm_translate_synthetic_msr(&id->index);
> >                  if (r)
> >                          break;
> >          }
> > 
> >          r = -EINVAL;
> >          if (id->type != 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 through
> 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.:
> 
> if (id->type == KVM_X86_REG_MSR)
>         go through MSR framework;
> else
>         go through other new handling;
> 
> 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.