On Sat, Feb 11, 2012 at 7:00 AM, Antonios Motakis
<a.motakis@xxxxxxxxxxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
