[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <263f5485-7e99-3db0-3234-f5ea02d1e119@redhat.com>
Date: Mon, 30 Nov 2020 19:16:18 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <sean.j.christopherson@...el.com>,
Tom Lendacky <thomas.lendacky@....com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, x86@...nel.org,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Brijesh Singh <brijesh.singh@....com>
Subject: Re: [RFC PATCH 23/35] KVM: SVM: Add support for CR4 write traps for
an SEV-ES guest
On 15/09/20 00:16, Sean Christopherson wrote:
>> +int kvm_track_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
>> +{
>> + unsigned long old_cr4 = kvm_read_cr4(vcpu);
>> + unsigned long pdptr_bits = X86_CR4_PGE | X86_CR4_PSE | X86_CR4_PAE |
>> + X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_PKE;
>> +
>> + if (kvm_x86_ops.set_cr4(vcpu, cr4))
>> + return 1;
> Pretty much all the same comments as EFER and CR0, e.g. call svm_set_cr4()
> directly instead of bouncing through kvm_x86_ops. And with that, this can
> be called __kvm_set_cr4() to be consistent with __kvm_set_cr0().
I agree with calling svm_set_cr4 directly, but then this should be
kvm_post_set_cr4.
Paolo
>> +
>> + if (((cr4 ^ old_cr4) & pdptr_bits) ||
>> + (!(cr4 & X86_CR4_PCIDE) && (old_cr4 & X86_CR4_PCIDE)))
>> + kvm_mmu_reset_context(vcpu);
>> +
>> + if ((cr4 ^ old_cr4) & (X86_CR4_OSXSAVE | X86_CR4_PKE))
>> + kvm_update_cpuid_runtime(vcpu);
>> +
>> + return 0;
>> +}
Powered by blists - more mailing lists