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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2E647C433EF for ; Tue, 31 May 2022 07:16:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244463AbiEaHQy (ORCPT ); Tue, 31 May 2022 03:16:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234371AbiEaHQu (ORCPT ); Tue, 31 May 2022 03:16:50 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A88B0433AD; Tue, 31 May 2022 00:16:48 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 42FE068B05; Tue, 31 May 2022 09:16:40 +0200 (CEST) Date: Tue, 31 May 2022 09:16:39 +0200 From: "hch@lst.de" To: "Michael Kelley (LINUX)" Cc: Christoph Hellwig , Tianyu Lan , "robin.murphy@arm.com" , "andi.kleen@intel.com" , "m.szyprowski@samsung.com" , KY Srinivasan , Tianyu Lan , "iommu@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , vkuznets , "brijesh.singh@amd.com" , "konrad.wilk@oracle.com" , "hch@lst.de" , "wei.liu@kernel.org" , "parri.andrea@gmail.com" , "thomas.lendacky@amd.com" , "linux-hyperv@vger.kernel.org" , "kirill.shutemov" Subject: Re: [RFC PATCH V2 1/2] swiotlb: Add Child IO TLB mem support Message-ID: <20220531071639.GA23482@lst.de> References: <20220502125436.23607-1-ltykernel@gmail.com> <20220502125436.23607-2-ltykernel@gmail.com> 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) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 30, 2022 at 01:52:37AM +0000, Michael Kelley (LINUX) wrote: > B) The contents of the memory buffer must transition between > encrypted and not encrypted. The hardware doesn't provide > any mechanism to do such a transition "in place". The only > way to transition is for the CPU to copy the contents between > an encrypted area and an unencrypted area of memory. > > Because of (B), we're stuck needing bounce buffers. There's no > way to avoid them with the current hardware. Tianyu also pointed > out not wanting to expose uninitialized guest memory to the host, > so, for example, sharing a read buffer with the host requires that > it first be initialized to zero. Ok, B is a deal breaker. I just brought this in because I've received review comments that state bouncing is just the easiest option for now and we could map it into the hypervisor in the future. But at least for SEV that does not seem like an option without hardware changes. > We should reset and make sure we agree on the top-level approach. > 1) We want general scalability improvements to swiotlb. These > improvements should scale to high CPUs counts (> 100) and for > multiple NUMA nodes. > 2) Drivers should not require any special knowledge of swiotlb to > benefit from the improvements. No new swiotlb APIs should be > need to be used by drivers -- the swiotlb scalability improvements > should be transparent. > 3) The scalability improvements should not be based on device > boundaries since a single device may have multiple channels > doing bounce buffering on multiple CPUs in parallel. Agreed to all counts. > The patch from Andi Kleen [3] (not submitted upstream, but referenced > by Tianyu as the basis for his patches) seems like a good starting point > for meeting the top-level approach. Yes, I think doing per-cpu and/or per-node scaling sounds like the right general approach. Why was this never sent out? > Andi and Robin had some > back-and-forth about Andi's patch that I haven't delved into yet, but > getting that worked out seems like a better overall approach. I had > an offline chat with Tianyu, and he would agree as well. Where was this discussion?