Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <e84d46e860bf2575564bb144eeb57230405ad36e.camel@redhat.com>
Subject: Re: [PATCH v2 09/11] KVM: x86: emulator/smm: use smram struct for
 64 bit smram load/restore
From:   Maxim Levitsky <mlevitsk@redhat.com>
To:     Sean Christopherson <seanjc@google.com>
Cc:     kvm@vger.kernel.org, x86@kernel.org,
        Kees Cook <keescook@chromium.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
        Borislav Petkov <bp@alien8.de>, Joerg Roedel <joro@8bytes.org>,
        Ingo Molnar <mingo@redhat.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>
Date:   Thu, 21 Jul 2022 14:54:15 +0300
In-Reply-To: <YtigALu4ccTi4/v0@google.com>
References: <20220621150902.46126-1-mlevitsk@redhat.com>
         <20220621150902.46126-10-mlevitsk@redhat.com> <YtigALu4ccTi4/v0@google.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Thu, 2022-07-21 at 00:38 +0000, Sean Christopherson wrote:
> On Tue, Jun 21, 2022, Maxim Levitsky wrote:
> > Use kvm_smram_state_64 struct to save/restore the 64 bit SMM state
> > (used when X86_FEATURE_LM is present in the guest CPUID,
> > regardless of 32-bitness of the guest).
> > 
> > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> > ---
> > @@ -9814,7 +9805,7 @@ static void enter_smm(struct kvm_vcpu *vcpu)
> >  	memset(buf, 0, 512);
> >  #ifdef CONFIG_X86_64
> >  	if (guest_cpuid_has(vcpu, X86_FEATURE_LM))
> > -		enter_smm_save_state_64(vcpu, buf);
> > +		enter_smm_save_state_64(vcpu, (struct kvm_smram_state_64 *)buf);
> >  	else
> >  #endif
> >  		enter_smm_save_state_32(vcpu, (struct kvm_smram_state_32 *)buf);
> 
> Hrm, I _love_ the approach overall, but I really dislike having to cast an
> arbitrary buffer, especially in the SVM code.
> 
> Aha!  Rather than keeping a buffer and casting, create a union to hold everything:
> 
> 	union kvm_smram {
> 		struct kvm_smram_state_64 smram64;
> 		struct kvm_smram_state_32 smram32;
> 		u8 bytes[512];
> 	};

Great idea, will do in v3.

> 
> and then enter_smm() becomes:
> 
>   static void enter_smm(struct kvm_vcpu *vcpu)
>   {
> 	struct kvm_segment cs, ds;
> 	struct desc_ptr dt;
> 	unsigned long cr0;
> 
> 	union kvm_smram smram;
> 
> 	BUILD_BUG_ON(sizeof(smram) != 512);
> 
> 	memset(smram.bytes, 0, sizeof(smram));
> #ifdef CONFIG_X86_64
> 	if (guest_cpuid_has(vcpu, X86_FEATURE_LM))
> 		enter_smm_save_state_64(vcpu, &smram.smram64);
> 	else
> #endif
> 		enter_smm_save_state_32(vcpu, &smram.smram32);
> 
> 	/*
> 	 * Give enter_smm() a chance to make ISA-specific changes to the vCPU
> 	 * state (e.g. leave guest mode) after we've saved the state into the
> 	 * SMM state-save area.
> 	 */
> 	static_call(kvm_x86_enter_smm)(vcpu, &smram);
> 
> 	kvm_smm_changed(vcpu, true);
> 	kvm_vcpu_write_guest(vcpu, vcpu->arch.smbase + 0xfe00, smram.bytes, sizeof(smram));
> 
> and em_rsm() gets similar treatment.  Then the vendor code doesn't have to cast,
> e.g. SVM can do:
> 
> 	smram->smram64.svm_guest_flag = 1;
> 	smram->smram64.svm_guest_vmcb_gpa = svm->nested.vmcb12_gpa;
> 
> That way we don't have to refactor this all again if we want to use SMRAM to save
> something on Intel for VMX (though I agree with Jim that that's probably a bad idea).
> 

Best regards,
	Maxim Levitsky