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.
