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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MSGID_FROM_MTA_HEADER,SPF_HELO_NONE,SPF_PASS 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 ADE4CC43467 for ; Mon, 19 Oct 2020 17:00:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 56CFC222EC for ; Mon, 19 Oct 2020 17:00:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="lCn/SDs7" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730834AbgJSRAj (ORCPT ); Mon, 19 Oct 2020 13:00:39 -0400 Received: from hqnvemgate25.nvidia.com ([216.228.121.64]:3503 "EHLO hqnvemgate25.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730645AbgJSRAj (ORCPT ); Mon, 19 Oct 2020 13:00:39 -0400 Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate25.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Mon, 19 Oct 2020 09:59:51 -0700 Received: from HQMAIL109.nvidia.com (172.20.187.15) by HQMAIL109.nvidia.com (172.20.187.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 19 Oct 2020 17:00:32 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.171) by HQMAIL109.nvidia.com (172.20.187.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 19 Oct 2020 17:00:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ao5g7wQ5l4KdEVVjatUuiUzF1HR9QQGQEdAULXVahcoU1VMPDUvLlSDogC49gjQJMGySQhXO4tvG/gxk3mdiq5Rme61SZ/aw4l3EanmjbA3MFO4AlCoHcacWPciiSYVkmVtg74n+dRo7LInfgi5esyooXotBqustwfa6HX63oA1yMiOPJcZQmc+a6ZehY+uDxuuQdKGjyV8OU1e9W8B+wC6KQqVLgrwlPk+7bqNchctyJj7moEEcrQ+fxeLddYcsv74y5nbndyH10TJnmUIkFN7PU8ksIlgQ7zmB51LH435T4gH34QvY9LkYFM2JKnmg5DsIpfW3/GKuAKbiSHfzSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pdcSjjWZePS0hH/ubWLT74o1FPXKYWW71rD9/WjGt00=; b=SmowLsGN0KAXz8sVtXfP4ihgWSt4t0gPYutDeOU2QiSyI8TOSUp2VvyV71pCEsZWxbpZmk9CVg2HyHU6eEpSTuKoFEmtYW5EUFJ9tiuRK1CYxz3xO3K86yLS1hnScud9+1+2PAZUce9T/x5VCxDJuD+1Kse3zYbxX9/v5hY9ZCabrOq2nafXaggvN+Fl/UnsMSpMUaeFP4lZHUOyQiQqUDBB+UAaaIbM5pYlj147v9Vb22AmkpsaXTAPaWeCNo0ThBOKzkECcs6WBMillRRfutR2P3XQodQKcQrZezLTWeICin6nVns4UntoBO4UHkkvF3CtknfSDQ4lfkvuOaWwgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none Received: from DM6PR12MB3834.namprd12.prod.outlook.com (2603:10b6:5:14a::12) by DM6PR12MB3116.namprd12.prod.outlook.com (2603:10b6:5:38::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.20; Mon, 19 Oct 2020 17:00:31 +0000 Received: from DM6PR12MB3834.namprd12.prod.outlook.com ([fe80::cdbe:f274:ad65:9a78]) by DM6PR12MB3834.namprd12.prod.outlook.com ([fe80::cdbe:f274:ad65:9a78%7]) with mapi id 15.20.3477.028; Mon, 19 Oct 2020 17:00:31 +0000 Date: Mon, 19 Oct 2020 14:00:29 -0300 From: Jason Gunthorpe To: Tom Lendacky CC: , , , , , Radim =?utf-8?B?S3LEjW3DocWZ?= , Arnd Bergmann , Matt Fleming , "Konrad Rzeszutek Wilk" , Andrey Ryabinin , Ingo Molnar , Borislav Petkov , "Andy Lutomirski" , "H. Peter Anvin" , "Paolo Bonzini" , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov , Rik van Riel , Larry Woodman , "Dave Young" , Toshimitsu Kani , "Michael S. Tsirkin" , Brijesh Singh Subject: Re: AMD SME encrpytion and PCI BAR pages to user space Message-ID: <20201019170029.GU6219@nvidia.com> References: <20201019152556.GA560082@nvidia.com> <4b9f13bf-3f82-1aed-c7be-0eaecebc5d82@amd.com> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4b9f13bf-3f82-1aed-c7be-0eaecebc5d82@amd.com> X-ClientProxiedBy: YT1PR01CA0096.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:2d::35) To DM6PR12MB3834.namprd12.prod.outlook.com (2603:10b6:5:14a::12) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from mlx.ziepe.ca (206.223.160.26) by YT1PR01CA0096.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:2d::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Mon, 19 Oct 2020 17:00:31 +0000 Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kUYWL-002OXy-Ml; Mon, 19 Oct 2020 14:00:29 -0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1603126791; bh=pdcSjjWZePS0hH/ubWLT74o1FPXKYWW71rD9/WjGt00=; h=ARC-Seal:ARC-Message-Signature:ARC-Authentication-Results:Date: From:To:CC:Subject:Message-ID:References:Content-Type: Content-Disposition:In-Reply-To:X-ClientProxiedBy:MIME-Version: X-MS-Exchange-MessageSentRepresentingType; b=lCn/SDs70aiXrQpWqP/anl+ViQ+NtikaVW6bkKMcpy+6HB+KCpnl84LqvuulOO6iZ wfS1BMN1l7eOSf/3JujExDLUZiqfrSyjQhSpQcUsMhMEh0dqWQwF2Ip8gaqnhOarkI ti5jdkn6JuJSw92F3krnj3df63pzVw8NgzrpsU7rg3XIqnDLbob7DoP642Bkb2hO5H 7/GvBqm2PBKX2PhMkkZEovBLhDDySpmfzo6YcWJM3QeuiGe6NoUCca8Cd1+czhKw2z tTyiW9JRfpsPlCVramEfX758UhYYYjgcobLOqma1CTxJ3m93GQBuJewyrdadh6rQ9O AdHMVtrOm7PSA== Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, Oct 19, 2020 at 11:36:16AM -0500, Tom Lendacky wrote: > > Is RDMA missing something? I don't see anything special in VFIO for > > instance and the two are very similar - does VFIO work with SME, eg > > DPDK or something unrelated to virtualization? > > If user space is mapping un-encrypted memory, then, yes, it would seem > that there is a gap in the support where the pgprot_decrypted() would be > needed in order to override the protection map. It isn't "memory" it is PCI BAR pages, eg memory mapped IO > > Is there a reason not to just add prot_decrypted() to > > io_remap_pfn_range()? Is there use cases where a caller actually wants > > encrypted io memory? > > As long as you never have physical memory / ram being mapped in this path, > it seems that applying pgprot_decrypted() would be ok. I think the word 'io' implies this is the case.. Let me make a patch for this avenue then, I think it is not OK to add pgprot_decrypted to every driver.. We already have the special distinction with io and non-io remap, that seems better. > > I saw your original patch series edited a few drivers this way, but > > not nearly enough. So I feel like I'm missing something.. Does vfio > > work with SME? I couldn't find any sign of it calling prot_decrypted() > > either? > > I haven't tested SME with VFIO/DPDK. Hum, I assume it is broken also. Actually quite a swath of drivers and devices will be broken under this :\ Jason