Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp3207640imc; Wed, 13 Mar 2019 11:33:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqxZeEkZqQYizSD9/x8Ssr2bsKj5xfJMqpraP55uFwQGJnQbFKBEMZMBx//WmDM/PHjMLPvZ X-Received: by 2002:a17:902:b416:: with SMTP id x22mr47510288plr.285.1552502027386; Wed, 13 Mar 2019 11:33:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552502027; cv=none; d=google.com; s=arc-20160816; b=OppOzjF73TCXdtVzvZJiiunYrXnPPkxuN6x79MQdtmBLzzHQ/Lb6xvnXBK3Fm+i6oh Vj6yu6YvzdP1lZmz6nJBM4Lw1xfl/Qz9MAbsgzH5sn+gw/yTi3ghgpjMQ6qJ5C6d4A/i aT+DpSB72vpAovi7ptQtaHlH/txrMu8z2eFLZihBrTaG8sccsf0JGM2v1xMftfl81jlE g82oaGunJfs6/VtiMKZnTaW/plg1Pyr4T22xSzj9r5pGc5kpe694BtwwVSAN26EBTfew XdwQem+NYLVKiUC43e8Dwzj5D4Mkn4xCmrisAAEm/beUfEr0Ibjiv5fwC9xvyNSHYHh9 TBpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=+GSZfPxUUia5YDp9WmP3XAWsXtQZZlh9d9Afq3jyg4g=; b=WYzDUkvDIhRNut0qouTL0Gumhg1ZK6ACAzP6vn5Era8Akek2FNDcMTOHSnLTVoHkLf +khFOJ9FH157kTi+YKr6ZkKsQLDeN9HS2AikpQiyS8X/B/1Q0ZOcf7IWeuMAQCjgTzPY XWxEPM2wjAjdfJvzzoYt+YH5GmWTPmhPtHgYSWq4Jj6JeyX0wkn7XfbrtR81vuSM1I/J VAqZKH3yrPtLg6oADlhD3GoejzRck80+ViTO/DyXfoNpVs7N5jRrgH8ZKFaNVFbBbdaM /QqsmZrM3Y+hENx+Cznev+u2WHA3wVrH59jEcGXelnltBeutDaOQEzt0aISNx8i++inN v6xA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d4si11394729pla.112.2019.03.13.11.33.30; Wed, 13 Mar 2019 11:33:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726627AbfCMSdB (ORCPT + 99 others); Wed, 13 Mar 2019 14:33:01 -0400 Received: from verein.lst.de ([213.95.11.211]:53262 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726033AbfCMSdB (ORCPT ); Wed, 13 Mar 2019 14:33:01 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id 7D86368B05; Wed, 13 Mar 2019 19:32:54 +0100 (CET) Date: Wed, 13 Mar 2019 19:32:54 +0100 From: Christoph Hellwig To: Julien Grall Cc: Christoph Hellwig , Arnd Bergmann , Robin Murphy , Juergen Gross , Stefano Stabellini , Andrew Morton , Konrad Rzeszutek Wilk , Linux Kernel Mailing List , Mike Rapoport , "open list:IOMMU DRIVERS" , Joerg Roedel , xen-devel , Boris Ostrovsky , Marek Szyprowski Subject: Re: [Xen-devel] [PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR" Message-ID: <20190313183254.GC4926@lst.de> References: <20190304195951.1118807-1-arnd@arndb.de> <957e168a-2589-89c7-3a72-5071a7b6c65a@arm.com> <20190308152355.GA20230@lst.de> <124f4e49-9eb1-99d9-35f4-c2ef3dff8415@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <124f4e49-9eb1-99d9-35f4-c2ef3dff8415@arm.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 08, 2019 at 05:25:57PM +0000, Julien Grall wrote: > In the common case, Dom0 also contains the PV backend drivers. Those > drivers may directly use the guest buffer in the DMA request (so a copy is > avoided). To avoid using a bounce buffer too much, xen-swiotlb will find > the host physical address associated to the guest buffer and will use it to > compute the DMA address. > > While Dom0 kernel may only deal with 32-bit physical address, the > hypervisor can still deal with up to 40-bit physical address. This means > the guest memory can be allocated above the 4GB threshold. Hence why the > dma_addr_t is always 64-bit with CONFIG_XEN=y. This at least makes some sense. But is it really so much better to avoid having a 64-bit phys_addr_t?