Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp5827903ybf; Thu, 5 Mar 2020 07:46:41 -0800 (PST) X-Google-Smtp-Source: ADFU+vuVXxMpNLyDQplhjWHnfx7JM9V2Lp1COQ3PtbYRr6Mg2sDjFsaT+bRhgMxH48lCEsxPHuQd X-Received: by 2002:aca:f5c7:: with SMTP id t190mr5926102oih.36.1583423201047; Thu, 05 Mar 2020 07:46:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583423201; cv=none; d=google.com; s=arc-20160816; b=TxnW+jknwXHeKtsjyXiYn5vVVHttbC/Ya0yURRUa9jLSeWEInrfCavW91/pNAZk6Ng g031VHTNe4GcyAMeH3F+oZYlR2utH3C61nK8si5q6nnRyB6AbThrc7Rua404ZMDvH5Xd 7TF1FIClB/UDLa9/IxELrlrGSGRb9RXX4M95cZQP6vuqIRYmOwhz2NmR1RapVPtiB4aN E67Xq0Y54Lu05z9BqMsjEIJ7WtqJJJXyrnXxp9NJxMDzWEHAh2w99EfvpUV/0IcfSGQ0 IPb53uJT0pMIGpiUSlb+FyzXd/AiuBcHYjJWnflW1bWoCODppSPprnAMNibAf2tUB3zD HJKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Lv0CpU8bhyMnSMiIic1UrHvdGAT8vy6D0b70Jhq8OaM=; b=AZ47IcTO+J6aEkqaBp0cNhY1cGWXpTMfVuRUGkX115wSMhXYhECU7VLMVZoy94Cp7e ZUPasA8aeCO1723DkUfMD0cQPZwVgDjoNIPxqv2gu3VpncKsJBhA2x61vCAvRReLEaPf QyCI+gXNpbl4uoS8uJsVwoUuPjXTQUpEhMub12arIe1V1B3fK19bOlVOixdTTlnyn4Qm tC6oN0G331oXT8TcNAwAJ5L4lBuveEUFCOpBjRt49ZfAcaARdZsSnL9gNZJW+ionIRKj e/BWbmFVdUA478wWUOkA6VScyS36IbwTGN7B77KiRC1PyE0q/TgX3HHnrxzT/KqVajUC eNHw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j2si3336051otr.255.2020.03.05.07.46.28; Thu, 05 Mar 2020 07:46:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726533AbgCEPpA (ORCPT + 99 others); Thu, 5 Mar 2020 10:45:00 -0500 Received: from verein.lst.de ([213.95.11.211]:60028 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725989AbgCEPo7 (ORCPT ); Thu, 5 Mar 2020 10:44:59 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id C4FC168B05; Thu, 5 Mar 2020 16:44:56 +0100 (CET) Date: Thu, 5 Mar 2020 16:44:56 +0100 From: Christoph Hellwig To: David Rientjes Cc: Christoph Hellwig , Tom Lendacky , "Singh, Brijesh" , "Grimm, Jon" , Joerg Roedel , baekhw@google.com, "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" Subject: Re: [rfc 5/6] dma-direct: atomic allocations must come from unencrypted pools Message-ID: <20200305154456.GC5332@lst.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 01, 2020 at 04:05:23PM -0800, David Rientjes wrote: > When AMD memory encryption is enabled, all non-blocking DMA allocations > must originate from the atomic pools depending on the device and the gfp > mask of the allocation. > > Keep all memory in these pools unencrypted. > > Signed-off-by: David Rientjes > --- > arch/x86/Kconfig | 1 + > kernel/dma/direct.c | 9 ++++----- > kernel/dma/remap.c | 2 ++ > 3 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1523,6 +1523,7 @@ config X86_CPA_STATISTICS > config AMD_MEM_ENCRYPT > bool "AMD Secure Memory Encryption (SME) support" > depends on X86_64 && CPU_SUP_AMD > + select DMA_DIRECT_REMAP I think we need to split the pool from remapping so that we don't drag in the remap code for x86. > if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && > - dma_alloc_need_uncached(dev, attrs) && We still need a check here for either uncached or memory encryption. > @@ -141,6 +142,7 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size, > if (!addr) > goto free_page; > > + set_memory_decrypted((unsigned long)page_to_virt(page), nr_pages); This probably warrants a comment. Also I think the infrastructure changes should be split from the x86 wire up.