On Sat, Feb 11, 2012 at 10:33 AM, Antonios Motakis
<a.motakis@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> On 02/11/2012 06:35 PM, Christoffer Dall wrote:
>>
>> 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.
>
> Don't you have to do this anyway? You'd want the flush to be effective on
> all CPUs before proceeding.
hmm yeah, actually you do need this. Unless the -IS version of the
flush instruction covers all relevant cores in this case. Marc, I
don't think that the processor clearing out the page table entry will
necessarily belong to the same inner-shareable domain as the processor
potentially executing the VM, so therefore the -IS flushing version
would not be sufficient and we actually have to go and send an IPI.
So, it sounds to me like:
1) we have to signal all vcpus using the VMID for which we are
clearing page table entries
2) make sure that they, either
2a) flush their TLBs
2b) get a new VMID
seems like 2b might be slightly faster, but leaves more entries in the
TLB that are then unused - not sure if that's a bad thing considering
the replacement policy. Perhaps 2a is cleaner...
Thoughts anyone?
--
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
