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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19549C43461 for ; Fri, 11 Sep 2020 07:14:38 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7E2C4221F0 for ; Fri, 11 Sep 2020 07:14:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7E2C4221F0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 297AF86DD6; Fri, 11 Sep 2020 07:14:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhNC2IJNzH9W; Fri, 11 Sep 2020 07:14:36 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by fraxinus.osuosl.org (Postfix) with ESMTP id A8EBB86DA1; Fri, 11 Sep 2020 07:14:36 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8D84DC0052; Fri, 11 Sep 2020 07:14:36 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3518BC0051 for ; Fri, 11 Sep 2020 07:14:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 3050C8773D for ; Fri, 11 Sep 2020 07:14:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qb9Er6hWE+Le for ; Fri, 11 Sep 2020 07:14:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by whitealder.osuosl.org (Postfix) with ESMTPS id 9CE3287739 for ; Fri, 11 Sep 2020 07:14:33 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 016DC68BFE; Fri, 11 Sep 2020 09:14:29 +0200 (CEST) Date: Fri, 11 Sep 2020 09:14:29 +0200 From: Christoph Hellwig To: Robin Murphy Subject: Re: [PATCH 09/12] dma-direct: remove __dma_to_phys Message-ID: <20200911071429.GE22394@lst.de> References: <20200908164758.3177341-1-hch@lst.de> <20200908164758.3177341-10-hch@lst.de> <5d797c06-401d-62b1-f144-ea6e9a5144dd@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5d797c06-401d-62b1-f144-ea6e9a5144dd@arm.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Fenghua Yu , Tony Luck , linux-ia64@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Thomas Bogendoerfer , linux-mips@vger.kernel.org, Christoph Hellwig X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Thu, Sep 10, 2020 at 02:26:03PM +0100, Robin Murphy wrote: > On 2020-09-08 17:47, Christoph Hellwig wrote: >> There is no harm in just always clearing the SME encryption bit, while >> significantly simplifying the interface. > > After a 10-minute diversion into "but hang on, force_dma_unencrypted() is > meaningful on PPC and S390 too..." before realising that it all does just > come back to __sme_clr(), which is indeed a no-op for everyone other than > AMD, any simplification of this mess is indeed welcome :) > > Unless I've massively misunderstood how SME is supposed to work, Exactly. This weird encryption bit in AMD SME causes all kinds of harm, and I'm glad no one picked it up. I've also been wondering if we should change the interface to explicit set/clear the bit, but I'll leave that for another pass as fixing up the SME interfaces would turn into a massive disgression. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu