On 02/11/2012 06:35 PM, Christoffer Dall wrote:
> On Sat, Feb 11, 2012 at 7:00 AM, Antonios Motakis
> <a.motakis at virtualopensystems.com> wrote:
>> On 02/10/2012 11:22 PM, Marc Zyngier wrote:
>>> +ENTRY(__kvm_tlb_flush_vmid)
>>> + hvc #0 @ Switch to Hyp mode
>>> + push {r2, r3}
>>>
>>> + ldrd r2, r3, [r0, #KVM_VTTBR]
>>> + mcrr p15, 6, r2, r3, c2 @ Write VTTBR
>>> + isb
>>> + mcr p15, 0, r0, c8, c7, 0 @ TBLIALL
>>> + dsb
>>> + isb
>>> + mov r2, #0
>>> + mov r3, #0
>>> + mcrr p15, 6, r2, r3, c2 @ Back to VMID #0
>>> + isb
>>> +
>>> + pop {r2, r3}
>>> + hvc #0 @ Back to SVC
>>> + mov pc, lr
>>> +ENDPROC(__kvm_tlb_flush_vmid)
>>
>> With the last VMID implementation, you could get the equivalent effect of a
>> per-VMID flush, by just getting a new VMID for the current VM. So you could
>> do a (kvm->arch.vmid = 0) to force a new VMID when the guest reruns, and
>> save the overhead of that flush (you will do a complete flush every 255
>> times instead of a small one every single time).
>>
> to do this you would need to send an IPI if the guest is currently
> executing on another CPU and make it exit the guest, so that the VMID
> assignment will run before the guest potentially accesses that TLB
> entry that points to the page that was just reclaimed - which I am not
> sure will be better than this solution.
Don't you have to do this anyway? You'd want the flush to be effective
on all CPUs before proceeding.
