From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F24BC4332F for ; Wed, 21 Dec 2022 17:46:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9A7B14B8A9; Wed, 21 Dec 2022 12:46:32 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@linux.dev Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvkMdSytUuzX; Wed, 21 Dec 2022 12:46:31 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 745F34B8AA; Wed, 21 Dec 2022 12:46:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0EDA04B8A6 for ; Wed, 21 Dec 2022 12:46:30 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QetQKUUxz3B7 for ; Wed, 21 Dec 2022 12:46:28 -0500 (EST) Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id CCBFB4B7F7 for ; Wed, 21 Dec 2022 12:46:28 -0500 (EST) Date: Wed, 21 Dec 2022 17:46:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1671644788; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lq0/8mv7tU3gkv2tPiEwF0HZqzKvAv+MhTUPgiXCBig=; b=BAHGWDxCiyH5CBuau1zbxP1aS3Nr/dlcsmE6N41OxCbyOrAoBs1dvdD4dkxNQ9kGfEhDEJ hMjnzKwzTaX1ELWgQn6MkBecf0shN38nKabz4kcn7hb1MWroIJDVsTs3ErL/A/Llv19dUO bEGY77OWkXqds/w8vnUhdgA5sFtyYik= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Ricardo Koller Subject: Re: [PATCH 2/3] KVM: arm64: Handle S1PTW translation with TCR_HA set as a write Message-ID: References: <20221220200923.1532710-1-maz@kernel.org> <20221220200923.1532710-3-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT Cc: kvm@vger.kernel.org, Marc Zyngier , kvmarm@lists.linux.dev, Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Wed, Dec 21, 2022 at 08:46:06AM -0800, Ricardo Koller wrote: [...] > > - return false; > > + /* Can't introspect TCR_EL1 with pKVM */ > > + if (kvm_vm_is_protected(vcpu->kvm)) > > + return false; > > + > > + mmfr1 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR1_EL1); > > + afdb = cpuid_feature_extract_unsigned_field(mmfr1, ID_AA64MMFR1_EL1_HAFDBS_SHIFT); > > + > > + if (afdb == ID_AA64MMFR1_EL1_HAFDBS_NI) > > + return false; > > + > > + return (vcpu_read_sys_reg(vcpu, TCR_EL1) & TCR_HA); > > Also tested this specific case using page_fault_test when the PT page is > marked for dirty logging with and without AF. In both cases there's a > single _FSC_FAULT (no PERM_FAUT) as expected, and the PT page is marked dirty > in the AF case. The RO and UFFD cases also work as expected. > > Need to send some changes for page_fault_test as many tests assume that > any S1PTW is always a PT write, and are failing. Also need to add some new > tests for PTs in RO memslots (as it didn't make much sense before this > change). So I actually wanted to bring up the issue of user visibility, glad your test picked up something. This has two implications, which are rather odd. - When UFFD is in use, translation faults are reported to userspace as writes when from a RW memslot and reads when from an RO memslot. - S1 page table memory is spuriously marked as dirty, as we presume a write immediately follows the translation fault. That isn't entirely senseless, as it would mean both the target page and the S1 PT that maps it are both old. This is nothing new I suppose, just weird. Marc, do you have any concerns about leaving this as-is for the time being? At least before we were doing the same thing (write fault) every time. -- Thanks, Oliver _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BEFD128FC for ; Wed, 21 Dec 2022 17:46:29 +0000 (UTC) Date: Wed, 21 Dec 2022 17:46:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1671644788; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lq0/8mv7tU3gkv2tPiEwF0HZqzKvAv+MhTUPgiXCBig=; b=BAHGWDxCiyH5CBuau1zbxP1aS3Nr/dlcsmE6N41OxCbyOrAoBs1dvdD4dkxNQ9kGfEhDEJ hMjnzKwzTaX1ELWgQn6MkBecf0shN38nKabz4kcn7hb1MWroIJDVsTs3ErL/A/Llv19dUO bEGY77OWkXqds/w8vnUhdgA5sFtyYik= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Ricardo Koller Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Will Deacon Subject: Re: [PATCH 2/3] KVM: arm64: Handle S1PTW translation with TCR_HA set as a write Message-ID: References: <20221220200923.1532710-1-maz@kernel.org> <20221220200923.1532710-3-maz@kernel.org> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT Message-ID: <20221221174624.LyZZj1ZVlXL0g6UPOPI-ulLHy5IGsG_9xGzG-ujAMm8@z> On Wed, Dec 21, 2022 at 08:46:06AM -0800, Ricardo Koller wrote: [...] > > - return false; > > + /* Can't introspect TCR_EL1 with pKVM */ > > + if (kvm_vm_is_protected(vcpu->kvm)) > > + return false; > > + > > + mmfr1 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR1_EL1); > > + afdb = cpuid_feature_extract_unsigned_field(mmfr1, ID_AA64MMFR1_EL1_HAFDBS_SHIFT); > > + > > + if (afdb == ID_AA64MMFR1_EL1_HAFDBS_NI) > > + return false; > > + > > + return (vcpu_read_sys_reg(vcpu, TCR_EL1) & TCR_HA); > > Also tested this specific case using page_fault_test when the PT page is > marked for dirty logging with and without AF. In both cases there's a > single _FSC_FAULT (no PERM_FAUT) as expected, and the PT page is marked dirty > in the AF case. The RO and UFFD cases also work as expected. > > Need to send some changes for page_fault_test as many tests assume that > any S1PTW is always a PT write, and are failing. Also need to add some new > tests for PTs in RO memslots (as it didn't make much sense before this > change). So I actually wanted to bring up the issue of user visibility, glad your test picked up something. This has two implications, which are rather odd. - When UFFD is in use, translation faults are reported to userspace as writes when from a RW memslot and reads when from an RO memslot. - S1 page table memory is spuriously marked as dirty, as we presume a write immediately follows the translation fault. That isn't entirely senseless, as it would mean both the target page and the S1 PT that maps it are both old. This is nothing new I suppose, just weird. Marc, do you have any concerns about leaving this as-is for the time being? At least before we were doing the same thing (write fault) every time. -- Thanks, Oliver From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1646EC4332F for ; Wed, 21 Dec 2022 17:48:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Od2yflGeGsK7pURl6YLRqkbvBM5G+khGdlliPxqhocY=; b=k2DyepRtprSEhW 3MKipthGq7dSfB6oxXJ8kiO1sugfSjB9WLA2kT4/cqljVcLVx6yn0LwfJCzowXCIU8HB8sou99wb9 kLeKAA45TCPoYo6VkAua9Q+3W8Eoy/aKLFMkqLvuB3yl4+2AuiIbboDpi1b4VUG6t7mlg68IIdp0F NfSQ/mOPWrNQtAHpJuTWVbj/vdik813c0ZzaDgPT+P5eMdqGk319bZIsd3Yci/vOg1W9+GOIqok2N eTy+V3/zLkN6v71mW9VfcobRlGVEqmk84vCDNFw0bwzyVX3LYM6DoK8PzF62pGJpagqRo87T6GwDF OMRQBEmeiglJEeFiYrAw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p83BJ-0004XJ-6i; Wed, 21 Dec 2022 17:47:05 +0000 Received: from out2.migadu.com ([2001:41d0:2:aacc::]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p83Ak-00049E-Du for linux-arm-kernel@lists.infradead.org; Wed, 21 Dec 2022 17:46:33 +0000 Date: Wed, 21 Dec 2022 17:46:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1671644788; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lq0/8mv7tU3gkv2tPiEwF0HZqzKvAv+MhTUPgiXCBig=; b=BAHGWDxCiyH5CBuau1zbxP1aS3Nr/dlcsmE6N41OxCbyOrAoBs1dvdD4dkxNQ9kGfEhDEJ hMjnzKwzTaX1ELWgQn6MkBecf0shN38nKabz4kcn7hb1MWroIJDVsTs3ErL/A/Llv19dUO bEGY77OWkXqds/w8vnUhdgA5sFtyYik= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Ricardo Koller Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Will Deacon Subject: Re: [PATCH 2/3] KVM: arm64: Handle S1PTW translation with TCR_HA set as a write Message-ID: References: <20221220200923.1532710-1-maz@kernel.org> <20221220200923.1532710-3-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221221_094631_188292_D7AF5F9D X-CRM114-Status: GOOD ( 16.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Dec 21, 2022 at 08:46:06AM -0800, Ricardo Koller wrote: [...] > > - return false; > > + /* Can't introspect TCR_EL1 with pKVM */ > > + if (kvm_vm_is_protected(vcpu->kvm)) > > + return false; > > + > > + mmfr1 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR1_EL1); > > + afdb = cpuid_feature_extract_unsigned_field(mmfr1, ID_AA64MMFR1_EL1_HAFDBS_SHIFT); > > + > > + if (afdb == ID_AA64MMFR1_EL1_HAFDBS_NI) > > + return false; > > + > > + return (vcpu_read_sys_reg(vcpu, TCR_EL1) & TCR_HA); > > Also tested this specific case using page_fault_test when the PT page is > marked for dirty logging with and without AF. In both cases there's a > single _FSC_FAULT (no PERM_FAUT) as expected, and the PT page is marked dirty > in the AF case. The RO and UFFD cases also work as expected. > > Need to send some changes for page_fault_test as many tests assume that > any S1PTW is always a PT write, and are failing. Also need to add some new > tests for PTs in RO memslots (as it didn't make much sense before this > change). So I actually wanted to bring up the issue of user visibility, glad your test picked up something. This has two implications, which are rather odd. - When UFFD is in use, translation faults are reported to userspace as writes when from a RW memslot and reads when from an RO memslot. - S1 page table memory is spuriously marked as dirty, as we presume a write immediately follows the translation fault. That isn't entirely senseless, as it would mean both the target page and the S1 PT that maps it are both old. This is nothing new I suppose, just weird. Marc, do you have any concerns about leaving this as-is for the time being? At least before we were doing the same thing (write fault) every time. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel