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 5C78AC25B75 for ; Wed, 15 May 2024 11:01: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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fo0K1k+6uCUcZYG5vz5i6dMVk27l2dMyQFMdGaCnh34=; b=yIheu2s3FJu16w Q6k6UV2Mna/dBfELIyy2Zq6xWaqmTobXYdVTDkL9NsXHMRgr4NjoCVKb8WLAGmcbOFAVYvjFs6lt2 sRFK4rSDlSc3CQJdeI11Oq4wQrYG+iVhziy/53RR9RPlJojTbvIZ2GF6Cha3JLsKnwx313fNH2F2h 3IqfaOo5cw9X9E4OFWKGQeczS47B3QnAtMIRVjFBJ7/C5lJi3Zk3Kh5YTmNBXhTxeFgbw7epemse0 7+INSOE3fbqTeC3TzG1CjK5NEPdZ+886Umfn+dCaGSdYs/oTfQ7Ydxk3F8ljEmplItMqJslqRo954 f58429yqygHZktsgtIww==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7CNW-00000001IfU-1Fuk; Wed, 15 May 2024 11:00:58 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7CNT-00000001Iev-36Q6 for linux-arm-kernel@lists.infradead.org; Wed, 15 May 2024 11:00:57 +0000 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 56E141042; Wed, 15 May 2024 04:01:18 -0700 (PDT) Received: from [10.57.34.212] (unknown [10.57.34.212]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AC2293F762; Wed, 15 May 2024 04:00:50 -0700 (PDT) Message-ID: <4e89f047-ae70-43a8-a459-e375ca05b2c2@arm.com> Date: Wed, 15 May 2024 12:00:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/14] arm64: Force device mappings to be non-secure shared Content-Language: en-GB To: Catalin Marinas , Steven Price Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, 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 References: <20240412084213.1733764-1-steven.price@arm.com> <20240412084213.1733764-11-steven.price@arm.com> From: Suzuki K Poulose In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240515_040056_001460_563F905E X-CRM114-Status: GOOD ( 21.98 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 15/05/2024 10:01, Catalin Marinas wrote: > 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? Arm CCA plans to add support for passing through real devices, which support PCI-TDISP protocol. This would involve the Realm authenticating the device and explicitly requesting "protected" mapping *after* the verification (with the help of RMM). > >> 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. Agree. I have been exploring hooking this into ioremap_prot() where we could apply the attribute accordingly. We will change it in the next version. > > Can the DT actually place those emulated ranges in the higher IPA space > so that we avoid randomly adding this attribute for devices? It can, but then we kind of break the "Realm" view of the IPA space. i.e., right now it only knows about the "lower IPA" half and uses the top bit as a protection attr to access the IPA as shared. Expanding IPA size view kind of breaks "sharing memory", where, we must "use a different PA" for a page that is now shared. Suzuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel