[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6795358b-90a3-7c54-b889-7508356c5f46@redhat.com>
Date: Fri, 13 Nov 2020 18:03:40 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <sean.j.christopherson@...el.com>,
Cathy Avery <cavery@...hat.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
vkuznets@...hat.com, wei.huang2@....com, mlevitsk@...hat.com
Subject: Re: [PATCH v2 1/2] KVM: SVM: Move asid to vcpu_svm
On 13/10/20 03:29, Sean Christopherson wrote:
>> @@ -3446,6 +3447,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu)
>>
>> sync_lapic_to_cr8(vcpu);
>>
>> + svm->vmcb->control.asid = svm->asid;
>
> Related to the above, handling this in vcpu_run() feels wrong. There really
> shouldn't be a need to track the ASID. vmcb01 will always exist if vmcb02
> exits, e.g. the ASID can be copied and marked dirty when loading vmcb02.
> For new_asid(), it can unconditionally update vmcb01 and conditionally update
> vmcb02.
Yeah, it is a bit ugly and it is only needed on processors without
flush-by-ASID. On those processors the ASID is used by KVM as a sort of
TLB flush generation count. A TLB flush should affect both VMCB01 and
VMCB02, and that's the reason to have a global ASID in struct vcpu_svm.
On processors with flush-by-ASID, currently we bump the ASID on every
physical CPU change. However even that is not needed, in principle
svm->asid should never change and we could also have different ASID01
and ASID02, similar to VMX. So: long term, svm->asid should only be
used only on processors without flush-by-ASID. kvm-amd however is not
quite ready for that.
Paolo
Powered by blists - more mailing lists