From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marc Zyngier <marc.zyngier@arm.com>
Subject: Re: [Android-virt] [PATCH v5 00/13] KVM/ARM Implementation
Date: Wed, 01 Feb 2012 13:40:33 +0000
Message-ID: <4F2940D1.4040505@arm.com>
References: <20111211102403.21693.6887.stgit@localhost> <CAFEAcA-Fur5rKym9o0=EkcWDmfRvUZ7xqDfy4aoT_SRbA-iNQA@mail.gmail.com> <CANM98qLeBtaghw8rdLJ1DOorjwK8tWAyy3aa11pEj+ivFrGAhg@mail.gmail.com> <CAFEAcA8U2Kp9oEyKznNK0mDX8p4T_bR6RF6T-3jHgqpsJRs5Dg@mail.gmail.com> <3C7074CA-31A8-4395-933E-65587D2D2C55@virtualopensystems.com> <CAFEAcA-t=VHgBKBS3AaECK3RgTii-fQogb8Dn4fnkCdSwADTAA@mail.gmail.com> <CAEDV+g+Kd5iFWc2qT==q8WvADa+kqQEDJo4vKe4WCgm3jo7cqA@mail.gmail.com> <CANM98q+MtZEsP7w+7rtFRXx4oCYpoBAaz4t0yuDuOWs54wrYcA@mail.gmail.com> <CAFEAcA--RzLJsBdFBGNViexQAsYiHa39NCwN9cFndgD44GcX+g@mail.gmail.com> <4F292BEE.5030906@arm.com> <CAFEAcA97AOHsDOKsa12_wjDi46MjmfH1qzcFJFcLYLNEAhS+gw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Cc: Christoffer Dall <c.dall@virtualopensystems.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"avi@redhat.com" <avi@redhat.com>,
	"android-virt@lists.cs.columbia.edu"
	<android-virt@lists.cs.columbia.edu>,
	"tech@virtualopensystems.com" <tech@virtualopensystems.com>
To: Peter Maydell <peter.maydell@linaro.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from service87.mimecast.com ([91.220.42.44]:56829 "EHLO
	service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754307Ab2BANks convert rfc822-to-8bit (ORCPT
	<rfc822;kvm@vger.kernel.org>); Wed, 1 Feb 2012 08:40:48 -0500
In-Reply-To: <CAFEAcA97AOHsDOKsa12_wjDi46MjmfH1qzcFJFcLYLNEAhS+gw@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 01/02/12 12:20, Peter Maydell wrote:
> On 1 February 2012 12:11, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> The obvious fix would be to test for the virt extensions in ID_PFR1
>> before enabling KVM, and mask out the virt extensions from the same
>> register in the guest by trapping CP15-c0. But c0 is used by cache
>> maintenance operations, and trapping would lead to unacceptable
>> performance degradation.
> 
> You can just set HCR.TID3 to get hyp traps on only the feature
> ID registers, right? (traps access to only ID_PFR0, ID_PFR1, ID_DFR0,
> ID_AFR0, ID_MMFR0, ID_MMFR1, ID_MMFR2, ID_MMFR3, ID_ISAR0, ID_ISAR1,
> ID_ISAR2, ID_ISAR3, ID_ISAR4, ID_ISAR5, MVFR0, and MVFR1, none
> of which should be on performance-critical paths I hope.)

Good catch. It looks much better, except that ID_MMFR3 is used in
cpu_v7_set_pte_ext(), which is called each time you map a page. Ouch.

I'm not even sure we can the cache ID_MMFR3 in the kernel (multi-cluster
systems may have different features).

	M.
-- 
Jazz is not dead. It just smells funny...