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

Re: xen-swiotlb vs phys_to_dma


  • To: Christoph Hellwig <hch@xxxxxx>
  • From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
  • Date: Fri, 2 Oct 2020 13:21:25 -0700 (PDT)
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 149.199.60.83) smtp.rcpttodomain=lists.linux-foundation.org smtp.mailfrom=xilinx.com; dmarc=bestguesspass action=none header.from=xilinx.com; dkim=none (message not signed); 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:X-MS-Exchange-SenderADCheck; bh=K1sKfjfl6E0C1MGRjLxW/Z7cSOfeqva3SvzEf9ONgak=; b=Hu5/wln1emNdkIv6dZeGB8NgW7baZojPzkqUXGGmiI7xrFkH+1oK0G/l4aVYRqPBDNcZ6kjkB7lh7SRe8ph1THx23dRIPQl98Iw4t40MpiQJbc8w3OfD2++BTA+1a9jIJje81MVN7nRxrLHVAzDyVeC+6/XhPH8pEiLgP8qhLmTis8ay2M9ufbNsrInX8gpFNNoGjLmQJa5aYOMUXYvf8LPlgIwu5FXVFC9JNxJMet4YsOLEQlhxLSDdtbrW0vpbStc6w6EbGwWx0QFT0ArNack4Q5T7iftx1UHsUm9+8XBmrcY3KCk13UKEVFuWMWyxfcwSUYqfBcA86xkJ7aladw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CZOZ9C0uzv7vemfT0tAlbIYPqmCxa5zYSQG2pY0cdAkoCx715LErsisi+UJh256chVRvtOAxpAbKpRj8E4C4HhXSdCXJHWo2kYz/qV2ZlRDC+XTqagGjJL0MgxmE8yS2oEj2cACZPZuunraj4oOlOcu8zofeDk+HD9FBRsR+QpbywcppfnwpYed8Ed6aB96m0Feo1FWp5DQwvTCi4+a8gxqd2bep736t6SFSV03B1fqRW1406kX3b1KjLw8WGal5XFceR30OcrLHLPN56/b6GgnTdKu+gGJf1UEKAMhWzpxiYQagPkwcLY+V3H3Aj4MXstziwKszYy4i9w/PsMyfBg==
  • Cc: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 02 Oct 2020 20:21:58 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, 2 Oct 2020, Christoph Hellwig wrote:
> Hi Stefano,
> 
> I've looked over xen-swiotlb in linux-next, that is with your recent
> changes to take dma offsets into account.  One thing that puzzles me
> is that xen_swiotlb_map_page passes virt_to_phys(xen_io_tlb_start) as
> the tbl_dma_addr argument to swiotlb_tbl_map_single, despite the fact
> that the argument is a dma_addr_t and both other callers translate
> from a physical to the dma address.  Was this an oversight?

Hi Christoph,

It was not an oversight, it was done on purpose, although maybe I could
have been wrong. There was a brief discussion on this topic here: 

https://marc.info/?l=linux-kernel&m=159011972107683&w=2
https://marc.info/?l=linux-kernel&m=159018047129198&w=2

I'll repeat and summarize here for convenience. 

swiotlb_init_with_tbl is called by xen_swiotlb_init, passing a virtual
address (xen_io_tlb_start), which gets converted to phys and stored in
io_tlb_start as a physical address at the beginning of swiotlb_init_with_tbl.

Afterwards, xen_swiotlb_map_page calls swiotlb_tbl_map_single. The
second parameter, dma_addr_t tbl_dma_addr, is used to calculate the
right slot in the swiotlb buffer to use, comparing it against
io_tlb_start.

Thus, I think it makes sense for xen_swiotlb_map_page to call
swiotlb_tbl_map_single passing an address meant to be compared with
io_tlb_start, which is __pa(xen_io_tlb_start), so
virt_to_phys(xen_io_tlb_start) seems to be what we want.

However, you are right that it is strange that tbl_dma_addr is a
dma_addr_t, and maybe it shouldn't be? Maybe the tbl_dma_addr parameter
to swiotlb_tbl_map_single should be a phys address instead?
Or it could be swiotlb_init_with_tbl to be wrong and it should take a
dma address to initialize the swiotlb buffer.



 


Rackspace

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