From mboxrd@z Thu Jan  1 00:00:00 1970
From: Antonios Motakis <a.motakis@virtualopensystems.com>
Subject: Re: [Android-virt] [PATCH RFC v2 3/3] ARM: KVM: Add support for MMU
 notifiers
Date: Sat, 11 Feb 2012 19:33:14 +0100
Message-ID: <4F36B46A.1030805@virtualopensystems.com>
References: <1328912534-28888-1-git-send-email-marc.zyngier@arm.com> <1328912534-28888-3-git-send-email-marc.zyngier@arm.com> <4F3682A8.2060006@virtualopensystems.com> <CANM98qKqC6kByFabQqorDzLoNv=Kzx8oZ5OoeFUkELO4yLZqRg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Marc Zyngier <marc.zyngier@arm.com>,
	android-virt@lists.cs.columbia.edu, kvm@vger.kernel.org
To: Christoffer Dall <c.dall@virtualopensystems.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-ww0-f44.google.com ([74.125.82.44]:45210 "EHLO
	mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754390Ab2BKSdT (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sat, 11 Feb 2012 13:33:19 -0500
Received: by wgbdt10 with SMTP id dt10so3718473wgb.1
        for <kvm@vger.kernel.org>; Sat, 11 Feb 2012 10:33:18 -0800 (PST)
In-Reply-To: <CANM98qKqC6kByFabQqorDzLoNv=Kzx8oZ5OoeFUkELO4yLZqRg@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 02/11/2012 06:35 PM, Christoffer Dall wrote:
> On Sat, Feb 11, 2012 at 7:00 AM, Antonios Motakis
> <a.motakis@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.
Don't you have to do this anyway? You'd want the flush to be effective 
on all CPUs before proceeding.