On 12.02.2012, at 02:12, Christoffer Dall <c.dall@xxxxxxxxxxxxxxxxxxxxxx> 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. > > 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... X86 basically does 2b, but has per-cpu tlb tags. On PPC, we statically map the guest id to a guest atm. Alex -- 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