On Mon, Feb 13, 2012 at 5:13 AM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
> On 12/02/12 01:12, Christoffer Dall wrote:
>> 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.
>
> If we forget about the 11MPCore (which doesn't broadcast the TLB
> invalidation in hardware), the TLBIALLIS operation makes sure all cores
> belonging to the same inner shareable domain will see the TLB
> invalidation at the same time. If they don't, this is a hardware bug.
>
> Now, I do not have an example of a system where two CPUs are not part of
> the same IS domain. Even big.LITTLE has all of the potential 8 cores in
> an IS domain. If such a system exists one of these days, then it will be
> worth considering having a separate method to cope with the case. Until
> then, my opinion is to keep it as simple as possible.
>
ok, sounds good to me. Although, perhaps keep this as a comment somewhere...
--
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
