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 C2822C433F5 for ; Mon, 28 Feb 2022 11:30:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232386AbiB1Lb2 (ORCPT ); Mon, 28 Feb 2022 06:31:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231290AbiB1Lb2 (ORCPT ); Mon, 28 Feb 2022 06:31:28 -0500 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46C8D51E42; Mon, 28 Feb 2022 03:30:49 -0800 (PST) Received: by verein.lst.de (Postfix, from userid 2407) id 1E95C68AFE; Mon, 28 Feb 2022 12:30:43 +0100 (CET) Date: Mon, 28 Feb 2022 12:30:42 +0100 From: Christoph Hellwig To: "Michael Kelley (LINUX)" Cc: Christoph Hellwig , "iommu@lists.linux-foundation.org" , "x86@kernel.org" , Anshuman Khandual , Konrad Rzeszutek Wilk , Stefano Stabellini , Boris Ostrovsky , Juergen Gross , Joerg Roedel , David Woodhouse , Lu Baolu , Robin Murphy , "linux-arm-kernel@lists.infradead.org" , "xen-devel@lists.xenproject.org" , "linux-ia64@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-riscv@lists.infradead.org" , "linux-s390@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "tboot-devel@lists.sourceforge.net" , "linux-pci@vger.kernel.org" Subject: Re: [PATCH 08/11] swiotlb: make the swiotlb_init interface more useful Message-ID: <20220228113042.GA10570@lst.de> References: <20220227143055.335596-1-hch@lst.de> <20220227143055.335596-9-hch@lst.de> 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-s390@vger.kernel.org On Mon, Feb 28, 2022 at 02:53:39AM +0000, Michael Kelley (LINUX) wrote: > From: Christoph Hellwig Sent: Sunday, February 27, 2022 6:31 AM > > > > Pass a bool to pass if swiotlb needs to be enabled based on the > > addressing needs and replace the verbose argument with a set of > > flags, including one to force enable bounce buffering. > > > > Note that this patch removes the possibility to force xen-swiotlb > > use using swiotlb=force on the command line on x86 (arm and arm64 > > never supported that), but this interface will be restored shortly. > > > > Signed-off-by: Christoph Hellwig > > --- > > arch/arm/mm/init.c | 6 +---- > > arch/arm64/mm/init.c | 6 +---- > > arch/ia64/mm/init.c | 4 +-- > > arch/mips/cavium-octeon/dma-octeon.c | 2 +- > > arch/mips/loongson64/dma.c | 2 +- > > arch/mips/sibyte/common/dma.c | 2 +- > > arch/powerpc/include/asm/swiotlb.h | 1 + > > arch/powerpc/mm/mem.c | 3 ++- > > arch/powerpc/platforms/pseries/setup.c | 3 --- > > arch/riscv/mm/init.c | 8 +----- > > arch/s390/mm/init.c | 3 +-- > > arch/x86/kernel/cpu/mshyperv.c | 8 ------ > > arch/x86/kernel/pci-dma.c | 15 ++++++----- > > arch/x86/mm/mem_encrypt_amd.c | 3 --- > > drivers/xen/swiotlb-xen.c | 4 +-- > > include/linux/swiotlb.h | 15 ++++++----- > > include/trace/events/swiotlb.h | 29 ++++++++------------- > > kernel/dma/swiotlb.c | 35 ++++++++++++++------------ > > 18 files changed, 56 insertions(+), 93 deletions(-) > > [snip] > > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > > index 5a99f993e6392..568274917f1cd 100644 > > --- a/arch/x86/kernel/cpu/mshyperv.c > > +++ b/arch/x86/kernel/cpu/mshyperv.c > > @@ -336,14 +336,6 @@ static void __init ms_hyperv_init_platform(void) > > swiotlb_unencrypted_base = ms_hyperv.shared_gpa_boundary; > > #endif > > } > > - > > -#ifdef CONFIG_SWIOTLB > > - /* > > - * Enable swiotlb force mode in Isolation VM to > > - * use swiotlb bounce buffer for dma transaction. > > - */ > > - swiotlb_force = SWIOTLB_FORCE; > > -#endif > > With this code removed, it's not clear to me what forces the use of the > swiotlb in a Hyper-V isolated VM. The code in pci_swiotlb_detect_4g() doesn't > catch this case because cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) > returns "false" in a Hyper-V guest. In the Hyper-V guest, it's only > cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) that returns "true". I'm > looking more closely at the meaning of the CC_ATTR_* values, and it may > be that Hyper-V should also return "true" for CC_ATTR_MEM_ENCRYPT, > but I don't think CC_ATTR_HOST_MEM_ENCRYPT should return "true". Ok, I assumed that CC_ATTR_HOST_MEM_ENCRYPT returned true in this case. I guess we just need to check for CC_ATTR_GUEST_MEM_ENCRYPT as well there? 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 128D7C433F5 for ; Mon, 28 Feb 2022 11:31:18 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4K6dVr5m95z3bfc for ; Mon, 28 Feb 2022 22:31:16 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lst.de (client-ip=213.95.11.211; helo=verein.lst.de; envelope-from=hch@lst.de; receiver=) Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4K6dVM4jgSz2xDv for ; Mon, 28 Feb 2022 22:30:50 +1100 (AEDT) Received: by verein.lst.de (Postfix, from userid 2407) id 1E95C68AFE; Mon, 28 Feb 2022 12:30:43 +0100 (CET) Date: Mon, 28 Feb 2022 12:30:42 +0100 From: Christoph Hellwig To: "Michael Kelley (LINUX)" Subject: Re: [PATCH 08/11] swiotlb: make the swiotlb_init interface more useful Message-ID: <20220228113042.GA10570@lst.de> References: <20220227143055.335596-1-hch@lst.de> <20220227143055.335596-9-hch@lst.de> 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) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-hyperv@vger.kernel.org" , "x86@kernel.org" , "linux-ia64@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-riscv@lists.infradead.org" , Christoph Hellwig , "linux-s390@vger.kernel.org" , Stefano Stabellini , Joerg Roedel , Konrad Rzeszutek Wilk , "tboot-devel@lists.sourceforge.net" , "xen-devel@lists.xenproject.org" , David Woodhouse , Anshuman Khandual , Boris Ostrovsky , "linux-arm-kernel@lists.infradead.org" , Juergen Gross , "linuxppc-dev@lists.ozlabs.org" , "linux-mips@vger.kernel.org" , "iommu@lists.linux-foundation.org" , Robin Murphy , Lu Baolu Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Feb 28, 2022 at 02:53:39AM +0000, Michael Kelley (LINUX) wrote: > From: Christoph Hellwig Sent: Sunday, February 27, 2022 6:31 AM > > > > Pass a bool to pass if swiotlb needs to be enabled based on the > > addressing needs and replace the verbose argument with a set of > > flags, including one to force enable bounce buffering. > > > > Note that this patch removes the possibility to force xen-swiotlb > > use using swiotlb=force on the command line on x86 (arm and arm64 > > never supported that), but this interface will be restored shortly. > > > > Signed-off-by: Christoph Hellwig > > --- > > arch/arm/mm/init.c | 6 +---- > > arch/arm64/mm/init.c | 6 +---- > > arch/ia64/mm/init.c | 4 +-- > > arch/mips/cavium-octeon/dma-octeon.c | 2 +- > > arch/mips/loongson64/dma.c | 2 +- > > arch/mips/sibyte/common/dma.c | 2 +- > > arch/powerpc/include/asm/swiotlb.h | 1 + > > arch/powerpc/mm/mem.c | 3 ++- > > arch/powerpc/platforms/pseries/setup.c | 3 --- > > arch/riscv/mm/init.c | 8 +----- > > arch/s390/mm/init.c | 3 +-- > > arch/x86/kernel/cpu/mshyperv.c | 8 ------ > > arch/x86/kernel/pci-dma.c | 15 ++++++----- > > arch/x86/mm/mem_encrypt_amd.c | 3 --- > > drivers/xen/swiotlb-xen.c | 4 +-- > > include/linux/swiotlb.h | 15 ++++++----- > > include/trace/events/swiotlb.h | 29 ++++++++------------- > > kernel/dma/swiotlb.c | 35 ++++++++++++++------------ > > 18 files changed, 56 insertions(+), 93 deletions(-) > > [snip] > > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > > index 5a99f993e6392..568274917f1cd 100644 > > --- a/arch/x86/kernel/cpu/mshyperv.c > > +++ b/arch/x86/kernel/cpu/mshyperv.c > > @@ -336,14 +336,6 @@ static void __init ms_hyperv_init_platform(void) > > swiotlb_unencrypted_base = ms_hyperv.shared_gpa_boundary; > > #endif > > } > > - > > -#ifdef CONFIG_SWIOTLB > > - /* > > - * Enable swiotlb force mode in Isolation VM to > > - * use swiotlb bounce buffer for dma transaction. > > - */ > > - swiotlb_force = SWIOTLB_FORCE; > > -#endif > > With this code removed, it's not clear to me what forces the use of the > swiotlb in a Hyper-V isolated VM. The code in pci_swiotlb_detect_4g() doesn't > catch this case because cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) > returns "false" in a Hyper-V guest. In the Hyper-V guest, it's only > cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) that returns "true". I'm > looking more closely at the meaning of the CC_ATTR_* values, and it may > be that Hyper-V should also return "true" for CC_ATTR_MEM_ENCRYPT, > but I don't think CC_ATTR_HOST_MEM_ENCRYPT should return "true". Ok, I assumed that CC_ATTR_HOST_MEM_ENCRYPT returned true in this case. I guess we just need to check for CC_ATTR_GUEST_MEM_ENCRYPT as well there? 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 smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3E5C0C433EF for ; Mon, 28 Feb 2022 11:30:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id DC705819B8; Mon, 28 Feb 2022 11:30:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po9TD9OrCTbv; Mon, 28 Feb 2022 11:30:51 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp1.osuosl.org (Postfix) with ESMTPS id AC014819C8; Mon, 28 Feb 2022 11:30:50 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6270BC0077; Mon, 28 Feb 2022 11:30:50 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7DAC8C001A for ; Mon, 28 Feb 2022 11:30:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5CBF940979 for ; Mon, 28 Feb 2022 11:30:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pr-I_KCgCdJ for ; Mon, 28 Feb 2022 11:30:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by smtp4.osuosl.org (Postfix) with ESMTPS id 79A614090A for ; Mon, 28 Feb 2022 11:30:48 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 1E95C68AFE; Mon, 28 Feb 2022 12:30:43 +0100 (CET) Date: Mon, 28 Feb 2022 12:30:42 +0100 From: Christoph Hellwig To: "Michael Kelley (LINUX)" Subject: Re: [PATCH 08/11] swiotlb: make the swiotlb_init interface more useful Message-ID: <20220228113042.GA10570@lst.de> References: <20220227143055.335596-1-hch@lst.de> <20220227143055.335596-9-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: "linux-hyperv@vger.kernel.org" , "x86@kernel.org" , "linux-ia64@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-riscv@lists.infradead.org" , Christoph Hellwig , "linux-s390@vger.kernel.org" , Stefano Stabellini , Konrad Rzeszutek Wilk , "tboot-devel@lists.sourceforge.net" , "xen-devel@lists.xenproject.org" , David Woodhouse , Anshuman Khandual , Boris Ostrovsky , "linux-arm-kernel@lists.infradead.org" , Juergen Gross , "linuxppc-dev@lists.ozlabs.org" , "linux-mips@vger.kernel.org" , "iommu@lists.linux-foundation.org" , Robin Murphy 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 Mon, Feb 28, 2022 at 02:53:39AM +0000, Michael Kelley (LINUX) wrote: > From: Christoph Hellwig Sent: Sunday, February 27, 2022 6:31 AM > > > > Pass a bool to pass if swiotlb needs to be enabled based on the > > addressing needs and replace the verbose argument with a set of > > flags, including one to force enable bounce buffering. > > > > Note that this patch removes the possibility to force xen-swiotlb > > use using swiotlb=force on the command line on x86 (arm and arm64 > > never supported that), but this interface will be restored shortly. > > > > Signed-off-by: Christoph Hellwig > > --- > > arch/arm/mm/init.c | 6 +---- > > arch/arm64/mm/init.c | 6 +---- > > arch/ia64/mm/init.c | 4 +-- > > arch/mips/cavium-octeon/dma-octeon.c | 2 +- > > arch/mips/loongson64/dma.c | 2 +- > > arch/mips/sibyte/common/dma.c | 2 +- > > arch/powerpc/include/asm/swiotlb.h | 1 + > > arch/powerpc/mm/mem.c | 3 ++- > > arch/powerpc/platforms/pseries/setup.c | 3 --- > > arch/riscv/mm/init.c | 8 +----- > > arch/s390/mm/init.c | 3 +-- > > arch/x86/kernel/cpu/mshyperv.c | 8 ------ > > arch/x86/kernel/pci-dma.c | 15 ++++++----- > > arch/x86/mm/mem_encrypt_amd.c | 3 --- > > drivers/xen/swiotlb-xen.c | 4 +-- > > include/linux/swiotlb.h | 15 ++++++----- > > include/trace/events/swiotlb.h | 29 ++++++++------------- > > kernel/dma/swiotlb.c | 35 ++++++++++++++------------ > > 18 files changed, 56 insertions(+), 93 deletions(-) > > [snip] > > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > > index 5a99f993e6392..568274917f1cd 100644 > > --- a/arch/x86/kernel/cpu/mshyperv.c > > +++ b/arch/x86/kernel/cpu/mshyperv.c > > @@ -336,14 +336,6 @@ static void __init ms_hyperv_init_platform(void) > > swiotlb_unencrypted_base = ms_hyperv.shared_gpa_boundary; > > #endif > > } > > - > > -#ifdef CONFIG_SWIOTLB > > - /* > > - * Enable swiotlb force mode in Isolation VM to > > - * use swiotlb bounce buffer for dma transaction. > > - */ > > - swiotlb_force = SWIOTLB_FORCE; > > -#endif > > With this code removed, it's not clear to me what forces the use of the > swiotlb in a Hyper-V isolated VM. The code in pci_swiotlb_detect_4g() doesn't > catch this case because cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) > returns "false" in a Hyper-V guest. In the Hyper-V guest, it's only > cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) that returns "true". I'm > looking more closely at the meaning of the CC_ATTR_* values, and it may > be that Hyper-V should also return "true" for CC_ATTR_MEM_ENCRYPT, > but I don't think CC_ATTR_HOST_MEM_ENCRYPT should return "true". Ok, I assumed that CC_ATTR_HOST_MEM_ENCRYPT returned true in this case. I guess we just need to check for CC_ATTR_GUEST_MEM_ENCRYPT as well there? _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 60905C433EF for ; Mon, 28 Feb 2022 12:11:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=T0RzakHhwbypTt4UMRRqyKvugdUjc1NhyZyGf5uVrZQ=; b=MvcR+cs58ZdJA7 ufa1B3G+feKlsx5/XWPpQbDgrhTXIhspER9DyKjktMGv4NCol42u/OnW/fgTCMSnWAVTLy48ROYp/ MHVmlDYHbcnOMPa7CuVNeOp5EwsSQLPkHlBWEr3R2KqrwM+md3eCIj4Yyqe3VojfUf3k7mCOH4aXs loh5v51xoWZTaR7NuVJVzmU+nd+F8Pfe5+xBmyZX8MSmYrVsIFjgRce0v+s82jeDD7HagqMuPtwhC T68SDVfHu6pvKei4wj/N5IyBEyLP3J77hgdgrvF2fCZbL/uMObe74PHQ4rZSjwckXgqiqW+Rmjd+O 4aESk0rbsBSyAio+j0BA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nOesI-00C69H-B3; Mon, 28 Feb 2022 12:11:34 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nOeEr-00BtAy-1r; Mon, 28 Feb 2022 11:30:50 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id 1E95C68AFE; Mon, 28 Feb 2022 12:30:43 +0100 (CET) Date: Mon, 28 Feb 2022 12:30:42 +0100 From: Christoph Hellwig To: "Michael Kelley (LINUX)" Cc: Christoph Hellwig , "iommu@lists.linux-foundation.org" , "x86@kernel.org" , Anshuman Khandual , Konrad Rzeszutek Wilk , Stefano Stabellini , Boris Ostrovsky , Juergen Gross , Joerg Roedel , David Woodhouse , Lu Baolu , Robin Murphy , "linux-arm-kernel@lists.infradead.org" , "xen-devel@lists.xenproject.org" , "linux-ia64@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-riscv@lists.infradead.org" , "linux-s390@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "tboot-devel@lists.sourceforge.net" , "linux-pci@vger.kernel.org" Subject: Re: [PATCH 08/11] swiotlb: make the swiotlb_init interface more useful Message-ID: <20220228113042.GA10570@lst.de> References: <20220227143055.335596-1-hch@lst.de> <20220227143055.335596-9-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220228_033049_425652_3C94A888 X-CRM114-Status: GOOD ( 31.82 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Mon, Feb 28, 2022 at 02:53:39AM +0000, Michael Kelley (LINUX) wrote: > From: Christoph Hellwig Sent: Sunday, February 27, 2022 6:31 AM > > > > Pass a bool to pass if swiotlb needs to be enabled based on the > > addressing needs and replace the verbose argument with a set of > > flags, including one to force enable bounce buffering. > > > > Note that this patch removes the possibility to force xen-swiotlb > > use using swiotlb=force on the command line on x86 (arm and arm64 > > never supported that), but this interface will be restored shortly. > > > > Signed-off-by: Christoph Hellwig > > --- > > arch/arm/mm/init.c | 6 +---- > > arch/arm64/mm/init.c | 6 +---- > > arch/ia64/mm/init.c | 4 +-- > > arch/mips/cavium-octeon/dma-octeon.c | 2 +- > > arch/mips/loongson64/dma.c | 2 +- > > arch/mips/sibyte/common/dma.c | 2 +- > > arch/powerpc/include/asm/swiotlb.h | 1 + > > arch/powerpc/mm/mem.c | 3 ++- > > arch/powerpc/platforms/pseries/setup.c | 3 --- > > arch/riscv/mm/init.c | 8 +----- > > arch/s390/mm/init.c | 3 +-- > > arch/x86/kernel/cpu/mshyperv.c | 8 ------ > > arch/x86/kernel/pci-dma.c | 15 ++++++----- > > arch/x86/mm/mem_encrypt_amd.c | 3 --- > > drivers/xen/swiotlb-xen.c | 4 +-- > > include/linux/swiotlb.h | 15 ++++++----- > > include/trace/events/swiotlb.h | 29 ++++++++------------- > > kernel/dma/swiotlb.c | 35 ++++++++++++++------------ > > 18 files changed, 56 insertions(+), 93 deletions(-) > > [snip] > > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > > index 5a99f993e6392..568274917f1cd 100644 > > --- a/arch/x86/kernel/cpu/mshyperv.c > > +++ b/arch/x86/kernel/cpu/mshyperv.c > > @@ -336,14 +336,6 @@ static void __init ms_hyperv_init_platform(void) > > swiotlb_unencrypted_base = ms_hyperv.shared_gpa_boundary; > > #endif > > } > > - > > -#ifdef CONFIG_SWIOTLB > > - /* > > - * Enable swiotlb force mode in Isolation VM to > > - * use swiotlb bounce buffer for dma transaction. > > - */ > > - swiotlb_force = SWIOTLB_FORCE; > > -#endif > > With this code removed, it's not clear to me what forces the use of the > swiotlb in a Hyper-V isolated VM. The code in pci_swiotlb_detect_4g() doesn't > catch this case because cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) > returns "false" in a Hyper-V guest. In the Hyper-V guest, it's only > cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) that returns "true". I'm > looking more closely at the meaning of the CC_ATTR_* values, and it may > be that Hyper-V should also return "true" for CC_ATTR_MEM_ENCRYPT, > but I don't think CC_ATTR_HOST_MEM_ENCRYPT should return "true". Ok, I assumed that CC_ATTR_HOST_MEM_ENCRYPT returned true in this case. I guess we just need to check for CC_ATTR_GUEST_MEM_ENCRYPT as well there? _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 78B8AC433F5 for ; Mon, 28 Feb 2022 12:12:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=v2UMq+oopm6gNvrNtJAuXdkTZ2ph9S2vhn62ga7sf4E=; b=hmsDdoD7jFpIqE hzkFY/NHFgAIamQkFD0Buo+kDKCO0Un8E1kjEiG1aXAwZZG1G0QhtA+e0XimJwxSCH3RpKLqiNHFw LVmn/xzmwDkU2z130f5BvcV25dQYPp34FSX7Fsu32JR8gi7f3Z9ZGKkJUj64V8McpyGzWVIeXdPv4 IxQRsrPey+SDpnnDN8kuU7+vp1TyIxJzqjflcHfk3Ol0S6x/q5StIEcuyEDqqfts3vY/Pa7jLPKRl LsG/cMq3q6GxfUvGO3MYdn5dpjvRmBYOI52CTtbLff71RD2O3EypgE8c2+YvzoRrhh3PLl78G6HBR 8nH9KOl8WqwENoCJe3Eg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nOer6-00C5ks-JG; Mon, 28 Feb 2022 12:10:22 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nOeEr-00BtAy-1r; Mon, 28 Feb 2022 11:30:50 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id 1E95C68AFE; Mon, 28 Feb 2022 12:30:43 +0100 (CET) Date: Mon, 28 Feb 2022 12:30:42 +0100 From: Christoph Hellwig To: "Michael Kelley (LINUX)" Cc: Christoph Hellwig , "iommu@lists.linux-foundation.org" , "x86@kernel.org" , Anshuman Khandual , Konrad Rzeszutek Wilk , Stefano Stabellini , Boris Ostrovsky , Juergen Gross , Joerg Roedel , David Woodhouse , Lu Baolu , Robin Murphy , "linux-arm-kernel@lists.infradead.org" , "xen-devel@lists.xenproject.org" , "linux-ia64@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-riscv@lists.infradead.org" , "linux-s390@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "tboot-devel@lists.sourceforge.net" , "linux-pci@vger.kernel.org" Subject: Re: [PATCH 08/11] swiotlb: make the swiotlb_init interface more useful Message-ID: <20220228113042.GA10570@lst.de> References: <20220227143055.335596-1-hch@lst.de> <20220227143055.335596-9-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220228_033049_425652_3C94A888 X-CRM114-Status: GOOD ( 31.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Feb 28, 2022 at 02:53:39AM +0000, Michael Kelley (LINUX) wrote: > From: Christoph Hellwig Sent: Sunday, February 27, 2022 6:31 AM > > > > Pass a bool to pass if swiotlb needs to be enabled based on the > > addressing needs and replace the verbose argument with a set of > > flags, including one to force enable bounce buffering. > > > > Note that this patch removes the possibility to force xen-swiotlb > > use using swiotlb=force on the command line on x86 (arm and arm64 > > never supported that), but this interface will be restored shortly. > > > > Signed-off-by: Christoph Hellwig > > --- > > arch/arm/mm/init.c | 6 +---- > > arch/arm64/mm/init.c | 6 +---- > > arch/ia64/mm/init.c | 4 +-- > > arch/mips/cavium-octeon/dma-octeon.c | 2 +- > > arch/mips/loongson64/dma.c | 2 +- > > arch/mips/sibyte/common/dma.c | 2 +- > > arch/powerpc/include/asm/swiotlb.h | 1 + > > arch/powerpc/mm/mem.c | 3 ++- > > arch/powerpc/platforms/pseries/setup.c | 3 --- > > arch/riscv/mm/init.c | 8 +----- > > arch/s390/mm/init.c | 3 +-- > > arch/x86/kernel/cpu/mshyperv.c | 8 ------ > > arch/x86/kernel/pci-dma.c | 15 ++++++----- > > arch/x86/mm/mem_encrypt_amd.c | 3 --- > > drivers/xen/swiotlb-xen.c | 4 +-- > > include/linux/swiotlb.h | 15 ++++++----- > > include/trace/events/swiotlb.h | 29 ++++++++------------- > > kernel/dma/swiotlb.c | 35 ++++++++++++++------------ > > 18 files changed, 56 insertions(+), 93 deletions(-) > > [snip] > > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > > index 5a99f993e6392..568274917f1cd 100644 > > --- a/arch/x86/kernel/cpu/mshyperv.c > > +++ b/arch/x86/kernel/cpu/mshyperv.c > > @@ -336,14 +336,6 @@ static void __init ms_hyperv_init_platform(void) > > swiotlb_unencrypted_base = ms_hyperv.shared_gpa_boundary; > > #endif > > } > > - > > -#ifdef CONFIG_SWIOTLB > > - /* > > - * Enable swiotlb force mode in Isolation VM to > > - * use swiotlb bounce buffer for dma transaction. > > - */ > > - swiotlb_force = SWIOTLB_FORCE; > > -#endif > > With this code removed, it's not clear to me what forces the use of the > swiotlb in a Hyper-V isolated VM. The code in pci_swiotlb_detect_4g() doesn't > catch this case because cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) > returns "false" in a Hyper-V guest. In the Hyper-V guest, it's only > cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) that returns "true". I'm > looking more closely at the meaning of the CC_ATTR_* values, and it may > be that Hyper-V should also return "true" for CC_ATTR_MEM_ENCRYPT, > but I don't think CC_ATTR_HOST_MEM_ENCRYPT should return "true". Ok, I assumed that CC_ATTR_HOST_MEM_ENCRYPT returned true in this case. I guess we just need to check for CC_ATTR_GUEST_MEM_ENCRYPT as well there? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Mon, 28 Feb 2022 11:30:42 +0000 Subject: Re: [PATCH 08/11] swiotlb: make the swiotlb_init interface more useful Message-Id: <20220228113042.GA10570@lst.de> List-Id: References: <20220227143055.335596-1-hch@lst.de> <20220227143055.335596-9-hch@lst.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Michael Kelley (LINUX)" Cc: Christoph Hellwig , "iommu@lists.linux-foundation.org" , "x86@kernel.org" , Anshuman Khandual , Konrad Rzeszutek Wilk , Stefano Stabellini , Boris Ostrovsky , Juergen Gross , Joerg Roedel , David Woodhouse , Lu Baolu , Robin Murphy , "linux-arm-kernel@lists.infradead.org" , "xen-devel@lists.xenproject.org" , "linux-ia64@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-riscv@lists.infradead.org" , "linux-s390@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "tboot-devel@lists.sourceforge.net" , "linux-pci@vger.kernel.org" On Mon, Feb 28, 2022 at 02:53:39AM +0000, Michael Kelley (LINUX) wrote: > From: Christoph Hellwig Sent: Sunday, February 27, 2022 6:31 AM > > > > Pass a bool to pass if swiotlb needs to be enabled based on the > > addressing needs and replace the verbose argument with a set of > > flags, including one to force enable bounce buffering. > > > > Note that this patch removes the possibility to force xen-swiotlb > > use using swiotlb=force on the command line on x86 (arm and arm64 > > never supported that), but this interface will be restored shortly. > > > > Signed-off-by: Christoph Hellwig > > --- > > arch/arm/mm/init.c | 6 +---- > > arch/arm64/mm/init.c | 6 +---- > > arch/ia64/mm/init.c | 4 +-- > > arch/mips/cavium-octeon/dma-octeon.c | 2 +- > > arch/mips/loongson64/dma.c | 2 +- > > arch/mips/sibyte/common/dma.c | 2 +- > > arch/powerpc/include/asm/swiotlb.h | 1 + > > arch/powerpc/mm/mem.c | 3 ++- > > arch/powerpc/platforms/pseries/setup.c | 3 --- > > arch/riscv/mm/init.c | 8 +----- > > arch/s390/mm/init.c | 3 +-- > > arch/x86/kernel/cpu/mshyperv.c | 8 ------ > > arch/x86/kernel/pci-dma.c | 15 ++++++----- > > arch/x86/mm/mem_encrypt_amd.c | 3 --- > > drivers/xen/swiotlb-xen.c | 4 +-- > > include/linux/swiotlb.h | 15 ++++++----- > > include/trace/events/swiotlb.h | 29 ++++++++------------- > > kernel/dma/swiotlb.c | 35 ++++++++++++++------------ > > 18 files changed, 56 insertions(+), 93 deletions(-) > > [snip] > > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > > index 5a99f993e6392..568274917f1cd 100644 > > --- a/arch/x86/kernel/cpu/mshyperv.c > > +++ b/arch/x86/kernel/cpu/mshyperv.c > > @@ -336,14 +336,6 @@ static void __init ms_hyperv_init_platform(void) > > swiotlb_unencrypted_base = ms_hyperv.shared_gpa_boundary; > > #endif > > } > > - > > -#ifdef CONFIG_SWIOTLB > > - /* > > - * Enable swiotlb force mode in Isolation VM to > > - * use swiotlb bounce buffer for dma transaction. > > - */ > > - swiotlb_force = SWIOTLB_FORCE; > > -#endif > > With this code removed, it's not clear to me what forces the use of the > swiotlb in a Hyper-V isolated VM. The code in pci_swiotlb_detect_4g() doesn't > catch this case because cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) > returns "false" in a Hyper-V guest. In the Hyper-V guest, it's only > cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) that returns "true". I'm > looking more closely at the meaning of the CC_ATTR_* values, and it may > be that Hyper-V should also return "true" for CC_ATTR_MEM_ENCRYPT, > but I don't think CC_ATTR_HOST_MEM_ENCRYPT should return "true". Ok, I assumed that CC_ATTR_HOST_MEM_ENCRYPT returned true in this case. I guess we just need to check for CC_ATTR_GUEST_MEM_ENCRYPT as well there?