Re: [PATCH 1/5] KVM: VMX: Open code writing vCPU's PAT in VMX's MSR handler

["Huang, Kai" <kai.huang@intel.com>]

On Wed, 2023-05-03 at 16:25 -0700, Sean Christopherson wrote:
> On Wed, May 03, 2023, Kai Huang wrote:
> > On Wed, 2023-05-03 at 11:28 -0700, Sean Christopherson wrote:
> > > From: Wenyao Hai <haiwenyao@uniontech.com>
> > > 
> > > Open code setting "vcpu->arch.pat" in vmx_set_msr() instead of bouncing
> > > through kvm_set_msr_common() to get to the same code in kvm_mtrr_set_msr().
> > 
> > What's the value of doing so, besides saving a function of kvm_set_msr_common()?
> 
> To avoid complicating a very simple operation (writing vcpu->arch.pat), and to
> align with SVM.
> 
> > PAT change shouldn't be something frequent so shouldn't in a performance
> > critical path.  Given the PAT logic on Intel and AMD are basically the same ,
> > isn't it better to do in kvm_set_msr_common()?
> 
> I could go either way on calling into kvm_set_msr_common().  I agree that
> performance isn't a concern.  Hmm, and kvm_set_msr_common() still has a case
> statement for MSR_IA32_CR_PAT, so handling the write fully in vendor code won't
> impact the code generation for other MSRs.
> 
> Though I am leaning towards saying we should either handle loads and stores to
> vcpu->arch.pat in common code _or_ vendor code, i.e. either teach VMX and SVM to
> handle reads of PAT, or have their write paths call kvm_set_msr_common().  A mix
> of both is definitely odd.

Agreed.  Alternatively we can move SVM's setting vcpu->arch.pat to common code.

> 
> I don't have strong preference on which of those two we choose.  I dislike duplicating
> logic across VMX and SVM, but on the other hands it's so little code.  I think
> I'd vote for handling everything in vendor code, mostly because this gives the
> appearance that the write can fail, which is silly and misleading.
> 
> 		ret = kvm_set_msr_common(vcpu, msr_info);

No opinion either.  First glance is having 

	case MSR_IA32_CR_PAT:
		vcpu->arch.pat = data;

in kvm_set_msr_common() is clearer because it is symmetrical to the read path.

Anyway your decision :)

> 
> > For instance, given mtrr code is also in common x86, if we ever want to add some
> > additional logic to, i.e. calculate effective memtype, isn't better to do handle
> > pat in common code too?
> 
> FWIW, I highly doubt we'll ever have code like that.  The truly effective memtype
> calculations are too different between Intel and AMD, and doing anything useful
> with the guest's effective memtype is likely a fool's errand.

I thought the logic of getting effective memtype should be just the same between
Intel and AMD but it seems there's slight difference.  I agree with you it's
unlikely to have such code in common.

But looks setting vcpu->arch.pat in common code is more flexible.  Anyway no
opinion here.

> 
> > > Note, MSR_IA32_CR_PAT is 0x277, and is very subtly handled by
> > > 
> > > 	case 0x200 ... MSR_IA32_MC0_CTL2 - 1:
> > > 
> > > in kvm_set_msr_common().
> > > 
> > > Signed-off-by: Wenyao Hai <haiwenyao@uniontech.com>
> > > [sean: massage changelog]
> > > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > > ---
> > >  arch/x86/kvm/vmx/vmx.c | 8 +++-----
> > >  1 file changed, 3 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > > index 44fb619803b8..53e249109483 100644
> > > --- a/arch/x86/kvm/vmx/vmx.c
> > > +++ b/arch/x86/kvm/vmx/vmx.c
> > > @@ -2294,12 +2294,10 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> > >  		    get_vmcs12(vcpu)->vm_exit_controls & VM_EXIT_SAVE_IA32_PAT)
> > >  			get_vmcs12(vcpu)->guest_ia32_pat = data;
> > >  
> > > -		if (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PAT) {
> > > +		if (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PAT)
> > >  			vmcs_write64(GUEST_IA32_PAT, data);
> > > -			vcpu->arch.pat = data;
> > > -			break;
> > > -		}
> > > -		ret = kvm_set_msr_common(vcpu, msr_info);
> > > +
> > > +		vcpu->arch.pat = data;
> > >  		break;
> > >  	case MSR_IA32_MCG_EXT_CTL:
> > >  		if ((!msr_info->host_initiated &&