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 6550CC25B75 for ; Wed, 15 May 2024 09:01:40 +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=7GWvIaflxKE+FSCe97aOIv3XBZyeDNd04Txa2BtnLuA=; b=YDL4WnpIodFsyA 8irXSJPGRszBzTCOT5lduIcTp+D2eif3YI1bP1JjjYS/LCLrVQbNMrHnXgGKDRNOh8wBKUjQjR26p euzCEGN1rWgNQvAQesY3uhIswMWHjK/Ce7qX3Vsig9Pj9Rq7VhunwpbUjEWcCYoYfJf6/IwlN7EiR avf9ICPFxA5gH65IQiED4rweNmn99qySD9mw3OcXB5L/OloqfZVO/EaNHfXr5jr+kRlV59WlFg1kY Biw6fA2lSQS5y0GvjruhD6u3L6v0Aj25D1BisSywsFfzfRwu/40ytjRzGMhQD8z/jIBvaDH8mFj+d wSoA+B4lKqqGrMzpx2EA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7AVs-000000011rS-2uwe; Wed, 15 May 2024 09:01:28 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7AVq-000000011qq-197l for linux-arm-kernel@lists.infradead.org; Wed, 15 May 2024 09:01:27 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7240E61480; Wed, 15 May 2024 09:01:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 26F46C32781; Wed, 15 May 2024 09:01:21 +0000 (UTC) Date: Wed, 15 May 2024 10:01:19 +0100 From: Catalin Marinas To: Steven Price Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, Suzuki K Poulose , Marc Zyngier , Will Deacon , James Morse , Oliver Upton , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni Subject: Re: [PATCH v2 10/14] arm64: Force device mappings to be non-secure shared Message-ID: References: <20240412084213.1733764-1-steven.price@arm.com> <20240412084213.1733764-11-steven.price@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240412084213.1733764-11-steven.price@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240515_020126_394477_9C7A75BD X-CRM114-Status: GOOD ( 17.90 ) 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 Fri, Apr 12, 2024 at 09:42:09AM +0100, Steven Price wrote: > From: Suzuki K Poulose > > Device mappings (currently) need to be emulated by the VMM so must be > mapped shared with the host. You say "currently". What's the plan when the device is not emulated? How would the guest distinguish what's emulated and what's not to avoid setting the PROT_NS_SHARED bit? > Signed-off-by: Suzuki K Poulose > Signed-off-by: Steven Price > --- > arch/arm64/include/asm/pgtable.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > index f5376bd567a1..db71c564ec21 100644 > --- a/arch/arm64/include/asm/pgtable.h > +++ b/arch/arm64/include/asm/pgtable.h > @@ -598,7 +598,7 @@ static inline void set_pud_at(struct mm_struct *mm, unsigned long addr, > #define pgprot_writecombine(prot) \ > __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN) > #define pgprot_device(prot) \ > - __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN) > + __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN | PROT_NS_SHARED) This pgprot_device() is not the only one used to map device resources. pgprot_writecombine() is another commonly macro. It feels like a hack to plug one but not the other and without any way for the guest to figure out what's emulated. Can the DT actually place those emulated ranges in the higher IPA space so that we avoid randomly adding this attribute for devices? -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel