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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9BB99C07E97 for ; Tue, 5 Dec 2023 15:41:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D26C86B0071; Tue, 5 Dec 2023 10:41:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CD6B76B0072; Tue, 5 Dec 2023 10:41:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B77ED6B0074; Tue, 5 Dec 2023 10:41:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A7FB86B0071 for ; Tue, 5 Dec 2023 10:41:28 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 509D51401A7 for ; Tue, 5 Dec 2023 15:41:28 +0000 (UTC) X-FDA: 81533179056.06.A1E6CE6 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf23.hostedemail.com (Postfix) with ESMTP id 437E8140011 for ; Tue, 5 Dec 2023 15:41:26 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf23.hostedemail.com: domain of joey.gouly@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=joey.gouly@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701790886; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uRqxEhEWHkjXWHZR1LyVQvsDsSWOknYnJWaewUjGcgA=; b=21E1vDSa+o62YFSrPgMim179zSfIVR0/55gf0NDOP0sUT9juRUP3/ng6iozXskEfiAzDLd t+KenHb5AeXE99vF5rbt7ahA/wTRlh5zSAwxRgrZa/mIH3ijKMRjaXPOALsbsPQKf1S0jE iWM1+8+EvToRGrTBDULtbd6eagnR3EM= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf23.hostedemail.com: domain of joey.gouly@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=joey.gouly@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701790886; a=rsa-sha256; cv=none; b=UDuM+5wnF6VoonVNrhV31JSmbDoFyyJW3K3AoOrxE14kH8MMcQh0BzQ/R/3m4aJ6DGxgtm Q95kiqaa2C0QgbxjVOm6jbWWymTssDE+JkY7qkTwvC98EVg7+Zey3XeAT9bE62k9JxeNvJ 9l+jZOxvw4d1sCLaRddZheHN8eBSUec= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ADFB6139F; Tue, 5 Dec 2023 07:42:11 -0800 (PST) Received: from e124191.cambridge.arm.com (e124191.cambridge.arm.com [10.1.197.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1501B3F6C4; Tue, 5 Dec 2023 07:41:22 -0800 (PST) Date: Tue, 5 Dec 2023 15:41:16 +0000 From: Joey Gouly To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, aneesh.kumar@linux.ibm.com, broonie@kernel.org, catalin.marinas@arm.com, dave.hansen@linux.intel.com, oliver.upton@linux.dev, shuah@kernel.org, will@kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, James Morse , Suzuki K Poulose , Zenghui Yu Subject: Re: [PATCH v3 00/25] Permission Overlay Extension Message-ID: <20231205154116.GA3613610@e124191.cambridge.arm.com> References: <20231124163510.1835740-1-joey.gouly@arm.com> <86jzpub56r.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86jzpub56r.wl-maz@kernel.org> X-Rspamd-Queue-Id: 437E8140011 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: ozxnogncm6571ycgwykwpr5dizrc9s3z X-HE-Tag: 1701790886-10810 X-HE-Meta: U2FsdGVkX1+iC8Rl9VDlJnaGEj3cTXtKNcBSER2DWlZWSl/Bof3rEB+qcQKgheneN9MU0wrFtXJjqnKQp+dJYDCIEUmJgGNBUfksFNyHwd2QgdEOHONQxQaS2q79C8Nj6EmMtys2P9QxYDs+1sdoT679RsDKHyFij3B6MjTPyO8N23PYCuvwcbgVt2GfMI7GyRqnh6IcR/GMSBoykiXcN7D6wxHu/rkhr3mQKx84IKt90k93/CGMqQSWcoobnH49+RL2SJ1TFDko7Ehv5C7hsBpKK3Y9vF7WlCqbT6aOmgRK40WS3W4AOHMi43qbu3G7p5TQrxWRquDTNtDIEYjwWS5jQgQasywOgSC2q0hZFA2xTTObjADk7v2kcBaZpWsu7VzyjF4l2pRoVX8TdAF32jtpzHYljyaBf0cpBNerThlkKyiUBFQ8cOBfA6Z+5DckdP3oF7pUzsfGcr3rArrUVd9SJtx7oJ6ycOpGv1GTc8H7QBHkaa/PrLcVfRr9VSj1WbMyKmQKamrrn09aDskNggWePMKilwOdcWvZo7PGm5PED1zA1xxALxbzG92EPOR/5RCqAGci2C9uvho6K4fmvzt5++k1Aca0qiJsMEUixkJOTuzmNdcLLB0FxcyYizndW3uhtAMEEM6xe7uKUhEvWUWr7QJ0t1h7ebEgmwTkfmP8i1k9t1EZYCAubgWCpDOA+U1+E6+SJzcN36BxMapY0uHyoY6Enwge3zZ/ZgSYPETSKKiazEqbbkAEviCGL0KazH2ccwzuUbQ9gAKZg3XFftkcfqlb7zA5hT4qGAcMf2NQNQMbBtx2pAHeV0uFXJS+n58QhxTBGqeKlAxhUUia7wNQ212ZlIIO7790Y1+8BhHGJ4HufQJOmGT9Qp4RNiBDaMGjuDGhIKxDjRK9m31PQ5PrspK0chlQ0Z84n0Y0AwMKoeRt0BfjUIAVOQ1IS6E/UGND+HjI+PdvNmvd8qv SkN8nNUA iFzJUnAAP41W6yqKUTNJYiB5PutGwMpmsOm4aFOQoG2ox8UmelSkWTFyDg1UOxNAGUhW3YIF65Du6OK40LNsCFLhPmk5pbVrote1P8KgQQcjT1jGHTxtjN2Vm3q3MjEgk0XAGYPhtuKOc4ex4FGGa2JfIcQH//qmw4NU8VwrPxnHkfg4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Marc, On Mon, Dec 04, 2023 at 11:03:24AM +0000, Marc Zyngier wrote: > Hi Joey, > > On Fri, 24 Nov 2023 16:34:45 +0000, > Joey Gouly wrote: > > > > Hello everyone, > > > > This series implements the Permission Overlay Extension introduced in 2022 > > VMSA enhancements [1]. It is based on v6.7-rc2. > > > > Changes since v2[2]: > > # Added ptrace support and selftest > > # Add missing POR_EL0 initialisation in fork/clone > > # Rebase onto v6.7-rc2 > > # Add r-bs > > > > The Permission Overlay Extension allows to constrain permissions on memory > > regions. This can be used from userspace (EL0) without a system call or TLB > > invalidation. > > I have given this series a few more thoughts, and came to the > conclusion that is it still incomplete on the KVM front: > > * FEAT_S1POE often comes together with FEAT_S2POE. For obvious > reasons, we cannot afford to let the guest play with S2POR_EL1, nor > do we want to advertise FEAT_S2POE to the guest. > > You will need to add some additional FGT for this, and mask out > FEAT_S2POE from the guest's view of the ID registers. I found out last week that I had misunderstood S2POR_EL1, so yes looks like we need to trap that. I will add that in. > > * letting the guest play with POE comes with some interesting strings > attached: a guest that has started on a POE-enabled host cannot be > migrated to one that doesn't have POE. which means that the POE > registers should only be visible to the host userspace if enabled in > the guest's ID registers, and thus only context-switched in these > conditions. They should otherwise UNDEF. Can you give me some clarification here? - By visible to the host userspace do you mean via the GET_ONE_REG API? - Currently the ID register (ID_AA64MMFR3_EL1) is not ID_WRITABLE, should this series or another make it so? Currently if the host had POE it's enabled in the guest, so I believe migration to a non-POE host will fail? - For the context switch, do you mean something like: if (system_supports_poe() && ID_REG(MMFR3_EL1) & S1POE) ctxt_sys_reg(ctxt, POR_EL0) = read_sysreg_s(SYS_POR_EL0); That would need some refactoring, since I don't see how to access id_regs from struct kvm_cpu_context. Thanks, Joey