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.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 C29CAC07E9B for ; Wed, 21 Jul 2021 00:38:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 456106101E for ; Wed, 21 Jul 2021 00:38:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 456106101E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C70C16B0011; Tue, 20 Jul 2021 20:38:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C21496B0036; Tue, 20 Jul 2021 20:38:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC17B6B006C; Tue, 20 Jul 2021 20:38:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0205.hostedemail.com [216.40.44.205]) by kanga.kvack.org (Postfix) with ESMTP id 83C4D6B0011 for ; Tue, 20 Jul 2021 20:38:59 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 12FBD1846CAB7 for ; Wed, 21 Jul 2021 00:38:58 +0000 (UTC) X-FDA: 78384735156.35.1637E59 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf02.hostedemail.com (Postfix) with ESMTP id 5203270024E5 for ; Wed, 21 Jul 2021 00:38:57 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10051"; a="198621157" X-IronPort-AV: E=Sophos;i="5.84,256,1620716400"; d="scan'208";a="198621157" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2021 17:38:55 -0700 X-IronPort-AV: E=Sophos;i="5.84,256,1620716400"; d="scan'208";a="415424790" Received: from tassilo.jf.intel.com ([10.54.74.11]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2021 17:38:55 -0700 Date: Tue, 20 Jul 2021 17:38:54 -0700 From: Andi Kleen To: Erdem Aktas Cc: Andy Lutomirski , Joerg Roedel , David Rientjes , Borislav Petkov , Sean Christopherson , Andrew Morton , Vlastimil Babka , "Kirill A. Shutemov" , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , "Kaplan, David" , Varad Gautam , Dario Faggioli , x86 , linux-mm@kvack.org, linux-coco@lists.linux.dev Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP Message-ID: <20210721003854.GD535804@tassilo.jf.intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf02.hostedemail.com; dkim=none; spf=none (imf02.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=ak@linux.intel.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none) X-Stat-Signature: agscd9t9akhfzpk896886dfdr7g8fa3x X-Rspamd-Queue-Id: 5203270024E5 X-Rspamd-Server: rspam01 X-HE-Tag: 1626827937-864198 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > > > >> Also in general i don't think it will really happen, at least > > > initially. > > > >> All the shared buffers we use are allocated and never freed. So such a > > > >> problem could be deferred. > > > > > > Does it not depend on kernel configs? Currently, there is a valid > > > control path in dma_alloc_coherent which might alloc and free shared > > > pages. > > > > If the device filter is active it won't. > > > > If I am not missing something, I do not see that the device filter > checks for CONFIG_DMA_COHERENT_POOL and if it is not enabled, > dma_alloc_coherent will allocate a regular memory, convert it to > shared and convert it back to private when it is freed. What I meant is that the only devices that will be supported (mainly virtio) initially don't ever free coherent memory And the device filter enforces that. Now we probably want to support freeing anyways just to be able to run without device filter, but it definitely doesn't have to be fast or efficient. If there's a problem with it it would be a quite reasonable implementation to keep it in a pool. -Andi