Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3215661yba; Mon, 8 Apr 2019 13:43:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqwci7/136JRSW8MDQrBcfQ1eJ+BFp8aOEwXj1JdcUdtDrC+OUMMIzv9pfOlH3onuy+f1K4+ X-Received: by 2002:a17:902:8a8b:: with SMTP id p11mr32446011plo.227.1554756223321; Mon, 08 Apr 2019 13:43:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554756223; cv=none; d=google.com; s=arc-20160816; b=Jk+BKZpDkMprFhVs5WjqWQkKymr46UZpRvhdLHoc/gm9j4VqqQfZRRpi2R7FrukPSJ fZ9XVju+wH+KZRonj8maMfICcJ9ji+5IaMeudTiG2J2uwBS8gBqNIWLVWNpjYBobZiwl 3KNzRQo1+xc+2vyZFHr31/5Aurht2ymDvVk13qmEJT7VhdsJJz+5RMcc0Zr+8O0GMYVW OEx6SIE8kpXGxBCUe0MI82GcilESGLJqzHt4GUF2bYVbeeZ1/6qwMEqKiVQysgLb2xiA +MLuC/2DlAfNj4A3BRvnSRmMOK3Xu8O25ZPL32Vu1ghk/Xl6N4WURTFSPBPWAibZ80/z LeyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:subject:from; bh=trGaCc2ZPOcyr1czCtZzfI4GWWqWcivjGqdq1wQ4Xc0=; b=KrbmkZwQ6qY+99ZsjMrlFpFYWXDenMdpHCSkwL7IvHuBDILMKGbrlXfHn4do33yqqs t5D0Z0qNHEw8DWZE/63FAbwQC3GOHMlFkVXTDBS5cB1/iu7nqDrlqmqX4yKE6IsJtUJh TzpyJNJzCmNIpJ5joecJgqwND8Du3MYXAOOuXC3LiFpxPwXRkDLnJaD3BhQwQQILk2m7 Meo6RNWzkSzxyPygrM6+7gXOf/ROqGg9WETD8u0cMgyCGnUpUIJ/txnAyJYsKtKwEMvu 7Xtk97PUMs3IM4l41YJzPaekiTBnJishpZ/KYLKMu3dVPQdL0x4lQhDred8znhqP+t9g hmSw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i96si7492439plb.331.2019.04.08.13.43.27; Mon, 08 Apr 2019 13:43:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727258AbfDHSjX (ORCPT + 99 others); Mon, 8 Apr 2019 14:39:23 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:54480 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726464AbfDHSjX (ORCPT ); Mon, 8 Apr 2019 14:39:23 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0056B15BE; Mon, 8 Apr 2019 11:39:23 -0700 (PDT) Received: from [10.1.197.21] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BC9F43F718; Mon, 8 Apr 2019 11:39:20 -0700 (PDT) From: Kristina Martsenko Subject: Re: [PATCH v8 4/9] KVM: arm/arm64: preserve host HCR_EL2 value To: Amit Daniel Kachhap , James Morse , linux-arm-kernel@lists.infradead.org Cc: Christoffer Dall , Marc Zyngier , Catalin Marinas , Will Deacon , Andrew Jones , Dave Martin , Ramana Radhakrishnan , kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, Mark Rutland , Julien Thierry References: <1554172037-4516-1-git-send-email-amit.kachhap@arm.com> <1554172037-4516-5-git-send-email-amit.kachhap@arm.com> <6131d2cb-1062-6331-c2c3-7026081c458a@arm.com> Message-ID: <9a373ede-cdf8-c992-6f4b-352e46e0030a@arm.com> Date: Mon, 8 Apr 2019 19:39:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6131d2cb-1062-6331-c2c3-7026081c458a@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/04/2019 14:05, Amit Daniel Kachhap wrote: > Hi James, > > On 4/6/19 4:07 PM, James Morse wrote: >> Hi Amit, >> >> On 02/04/2019 03:27, Amit Daniel Kachhap wrote: >>> From: Mark Rutland >>> >>> When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which >>> is a constant value. This works today, as the host HCR_EL2 value is >>> always the same, but this will get in the way of supporting extensions >>> that require HCR_EL2 bits to be set conditionally for the host. >>> >>> To allow such features to work without KVM having to explicitly handle >>> every possible host feature combination, this patch has KVM save/restore >>> for the host HCR when switching to/from a guest HCR. The saving of the >>> register is done once during cpu hypervisor initialization state and is >>> just restored after switch from guest. >>> >>> For fetching HCR_EL2 during kvm initialisation, a hyp call is made using >>> kvm_call_hyp and is helpful in non-VHE case. >>> >>> For the hyp TLB maintenance code, __tlb_switch_to_host_vhe() is updated >>> to toggle the TGE bit with a RMW sequence, as we already do in >>> __tlb_switch_to_guest_vhe(). >>> >>> The value of hcr_el2 is now stored in struct kvm_cpu_context as both host >>> and guest can now use this field in a common way. >> >> These HCR_EL2 flags have had me confused for quite a while. >> I thought this was preserving the value that head.S or cpufeature.c had set, and with >> ptrauth we couldn't know what this register should be anymore, the host flags has to vary. >> >> Kristina's explanation of it[0], clarified things, and with a bit more digging it appears >> we always set API/APK, even if the hardware doesn't support the feature (as its harmless). >> So we don't need to vary the host flags... > > API/APK is always set for NVHE host mode. >> >> My question is, what breaks if this patch isn't merged? (the MDCR change is cleanup we can >> do because of this HCR change), is this HCR change just cleanup too? If so, can we merge >> ptrauth without either, so we only make the change when its needed? (it will cause some >> changes in your patch 7, but I can't see where you depend on the host flags). > > Yes you are right that this patch does not directly effect pointer authentication functionality but contains several optimizations and cleanups such as, > > * Removes assigning static flags HCR_HOST_VHE_FLAGS/HCR_HOST_NVHE_FLAGS from switch.c so switching functions now are more generic in nature. > * Currently the variation in hcr_el2 flags is across modes (VHE/NVHE). Any future conditional change within those modes in host HCR_EL2 may not effect code changes in switch.c > * Save of hcr_el2 done at hyp init time so not expensive switching wise. > > I am fine on posting it separately also. FWIW I think it makes sense to post the HCR and MDCR patches separately from this series. That should make it clear that pointer auth does not depend on these changes, and should make it easier to evaluate the changes on their own. Others' opinions are welcome as well. >> I recall Christoffer wanting to keep the restored DAIF register value on guest-exit static >> to avoid extra loads/stores when we know what the value would be. I think the same logic >> applies here. > Yes the saving of host registers once was suggested by Christoffer. I'm not familiar with this, but James may be referring to kvm_arm_vhe_guest_exit, which restores DAIF to a constant value. It seems like originally the patch saved/restored DAIF [1], but it was decided that a constant value was better. Thanks, Kristina [1] https://www.spinics.net/lists/arm-kernel/msg599798.html >> You mentioned in the cover letter the series has some history to it! >> >> >> Thanks, >> >> James >> >> [0] http://lore.kernel.org/r/7ec2f950-7587-5ecd-6caa-c2fd091ad22c@arm.com >>