[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH 12/12] swiotlb-xen: this is PV-only on x86

  • To: Juergen Gross <jgross@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 7 Sep 2021 14:13:21 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • 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; bh=Oa3ZLU03Swba0gYvsSEjRU1XJu+IDpj/E8M5qxMYmhM=; b=JqLWdpRvPxsIWlGroRzDRKNQZLUS8rpC0Vt0vtXK9VxNpou54LoVMXTNImYpMRQsMha8Rnu0VWQu/QXCRXHObhYJf/5cVSuax64pcn4CdXJvC8tutebA/iyv3dHmt53PcQCAaU9jiVmnmLcTIxGdVKS4MVkkHCNFq/3WKbQqNGwFI2BkvLEbHty+BpXyG+1nyMntSXhfxiMfXt0jNTqAGgeUkzxX0zb8BZMQswUdfkIzmdJEQCuNjT/yjE1W2+Ww9jhD/V42Gy+RZ73oPjffsxbLGy1UoXVyvOK2fmCXIhRkZ9csNBnXLy4ilnn1SM8GGzLCc83VzFDfMlGMHABSwQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fNrCjBtaCc9xrRgcZFD6TBodIymGQhEGSbmgii+q0J6PhiCvr9GbbJuWLbKnB3UY3AiS6gQ5Am15OL6bQ72vSLi2Rl1pS8ygiZUy5fMJMJVBNo2vBeKgD6GNJIz3oOyzOaErWXlx6+qgAOHM/xHdcCyoRl6IYlrUuChkpjOj0n5Rj6KfDry0tDdAKzdxfTNdOb6dKDkyJxySSyrIBoIfwxRYutrJtc3Q/aK+iAzkkavz7qe9K0/tLz0FRWkwNU9FG9wpXeT5QPqJdyzA5QyvjxQjYwE6qAKcmugli7NzsvX4mPCPxSOQc5d4354ZWCK25rcy1PWGw0+gBnOwlHiiTw==
  • Authentication-results: alien8.de; dkim=none (message not signed) header.d=none;alien8.de; dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, lkml <linux-kernel@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>
  • Delivery-date: Tue, 07 Sep 2021 12:13:29 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

The code is unreachable for HVM or PVH, and it also makes little sense
in auto-translated environments. On Arm, with
xen_{create,destroy}_contiguous_region() both being stubs, I have a hard
time seeing what good the Xen specific variant does - the generic one
ought to be fine for all purposes there. Still Arm code explicitly
references symbols here, so the code will continue to be included there.

Instead of making PCI_XEN's "select" conditional, simply drop it -
SWIOTLB_XEN will be available unconditionally in the PV case anyway, and
is - as explained above - dead code in non-PV environments.

This in turn allows dropping the stubs for
xen_{create,destroy}_contiguous_region(), the former of which was broken
anyway - it failed to set the DMA handle output.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2605,7 +2605,6 @@ config PCI_OLPC
 config PCI_XEN
        def_bool y
        depends on PCI && XEN
-       select SWIOTLB_XEN
 config MMCONF_FAM10H
        def_bool y
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -177,6 +177,7 @@ config XEN_GRANT_DMA_ALLOC
        def_bool y
+       depends on XEN_PV || ARM || ARM64
        select DMA_OPS
        select SWIOTLB
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -46,19 +46,7 @@ extern unsigned long *xen_contiguous_bit
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
                                unsigned int address_bits,
                                dma_addr_t *dma_handle);
 void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order);
-static inline int xen_create_contiguous_region(phys_addr_t pstart,
-                                              unsigned int order,
-                                              unsigned int address_bits,
-                                              dma_addr_t *dma_handle)
-       return 0;
-static inline void xen_destroy_contiguous_region(phys_addr_t pstart,
-                                                unsigned int order) { }
 #if defined(CONFIG_XEN_PV)



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.