From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B75803D6CA0 for ; Thu, 9 Jul 2026 09:10:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783588251; cv=none; b=o6wBd5SRJ+uxAapv25/vN15Rl1kOFrtGRdDVhqpoF+la4M8THe1W0M94zQXODbW2/uGaIx24KXQlfvYQROHvOiiTPM11seW0jnnXxBszPuM7tWqqyM7VuoR3lIOBj+puo/k82CKCz5v6LPcxguipxTls9++O9AFYwn1iRN4IIsw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783588251; c=relaxed/simple; bh=RfO6vOxvlqI8v4oqXlailBZAaEFV4XfG1mAigaiftxU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Em2iW4obNDo/x7ndl7mpgH9htCxDmxAW1yl13gT3Gtmhrj/AVjDf1f7mJ+zu8BkC5jX3HvhChbASXVRG+6ZIJPHC8eZpqo+iG30SJJ81IvDaCbUDs053trQBZdN7FIKkO36GaK53a2zFFcJl2udWdaNZ2JJh5V0r426jaJ4UCYg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=hdycN/bK; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="hdycN/bK" 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 DB8A225E9; Thu, 9 Jul 2026 02:10:44 -0700 (PDT) Received: from arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 20CDF3F66F; Thu, 9 Jul 2026 02:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1783588249; bh=RfO6vOxvlqI8v4oqXlailBZAaEFV4XfG1mAigaiftxU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hdycN/bKUzXJei67dfuvgObI+ubEd99X/hhUVqLAsyUaTd5InVPrLLRpJs7Nug8v6 MkBkf4v15ViLGh/u1jNarDYmoblbgoqi2YxYnINKbzpCpGtnAokxX+f8q72ornx378 LFM6DKglOD0vW96KxQxSmRAVpUIO6VdHdtBSfkrA= Date: Thu, 9 Jul 2026 10:10:45 +0100 From: Catalin Marinas To: "Aneesh Kumar K.V" Cc: Mostafa Saleh , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, will@kernel.org, rppt@kernel.org, maz@kernel.org Subject: Re: [PATCH 3/3] arm64/coco: Add pKVM as a CC platform Message-ID: References: <20260603110522.3331819-1-smostafa@google.com> <20260603110522.3331819-4-smostafa@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jun 12, 2026 at 08:37:42PM +0530, Aneesh Kumar K.V wrote: > Mostafa Saleh writes: > > > On Thu, Jun 04, 2026 at 02:29:00PM +0530, Aneesh Kumar K.V wrote: > >> Mostafa Saleh writes: > >> > >> > pKVM does support memory encryption, expose that to the rest of > >> > the kernel through cc_platform_has() > >> > > >> > At the moment, all devices inside the guest are emulated which > >> > requires its memory to be shared back to the host (decrypted), so > >> > set force_dma_unencrypted() to always return true. > >> > > >> > Although, typically pKVM guests rely on restricted-dma-pools to > >> > bounce traffic, with this change, it is possible to solely rely on > >> > the default SWIOTLB for that (assuming the appropriate size is set > >> > from the command line) > >> > > >> > Signed-off-by: Mostafa Saleh > >> > --- > >> > This change is critical for the ongoing refactoring of the DMA-API[1] > >> > that will break protected guests under pKVM with this patch. That is > >> > due to this rework will make the state of the SWIOTLB and restricted > >> > dma pools depends on the value returned by cc_platform_has() > >> > > >> > [1] https://lore.kernel.org/all/20260522042815.370873-1-aneesh.kumar@kernel.org/ > >> > --- > >> > arch/arm64/include/asm/hypervisor.h | 13 +++++++++++++ > >> > arch/arm64/include/asm/mem_encrypt.h | 3 ++- > >> > arch/arm64/kernel/rsi.c | 12 ------------ > >> > arch/arm64/mm/init.c | 15 ++++++++++++++- > >> > drivers/virt/coco/pkvm-guest/arm-pkvm-guest.c | 3 +++ > >> > 5 files changed, 32 insertions(+), 14 deletions(-) > >> > > >> > index d66291def0f4..26fe9c3f22e3 100644 > > [...] > >> > --- a/drivers/virt/coco/pkvm-guest/arm-pkvm-guest.c > >> > +++ b/drivers/virt/coco/pkvm-guest/arm-pkvm-guest.c > >> > @@ -17,6 +17,7 @@ > >> > #include > >> > > >> > static size_t pkvm_granule; > >> > +DEFINE_STATIC_KEY_FALSE_RO(pkvm_guest); > >> > > >> > >> Do we need EXPORT_SYMBOL on this? > > > > I was not sure about that, all users of this are in tree, I saw RME > > code have the EXPORT but did not know why? > > > > arm-cca-guest is one example. I was assuming is_protected_kvm_guest() > would be a helper that could get pulled into various code paths via > force_dma_unencrypted(). For now, the only callers of force_dma_unencrypted() I can see are in kernel/dma/*, so we can skip the exporting. -- Catalin