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.
