All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	jgross@suse.com, boris.ostrovsky@oracle.com,
	konrad.wilk@oracle.com, xen-devel@lists.xenproject.org,
	linux-kernel@vger.kernel.org, tamas@tklengyel.com,
	roman@zededa.com,
	Stefano Stabellini <stefano.stabellini@xilinx.com>
Subject: Re: [PATCH v2 10/11] xen/arm: introduce phys/dma translations in xen_dma_sync_for_*
Date: Mon, 8 Jun 2020 17:38:28 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2006081614530.2815@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <20200608071221.GF15742@infradead.org>

On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> On Wed, Jun 03, 2020 at 03:22:46PM -0700, Stefano Stabellini wrote:
> > From: Stefano Stabellini <stefano.stabellini@xilinx.com>
> > 
> > xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are
> > getting called passing dma addresses. On some platforms dma addresses
> > could be different from physical addresses. Before doing any operations
> > on these addresses we need to convert them back to physical addresses
> > using dma_to_phys.
> > 
> > Add dma_to_phys calls to xen_dma_sync_for_cpu, xen_dma_sync_for_device,
> > and xen_arch_need_swiotlb.
> > 
> > dma_cache_maint is fixed by the next patch.
> 
> The calling conventions because really weird now because
> xen_dma_sync_for_{device,cpu} already get both a phys_addr_t and
> a dma_addr_t.  
> 
> > 
> > -	if (pfn_valid(PFN_DOWN(handle)))
> > +	if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle))))
> 
> But here we translate the dma address to a phys addr
> 
> >  		arch_sync_dma_for_cpu(paddr, size, dir);
> 
> While this still uses the passed in paddr.  I think the uses of
> addresses in this code really needs a major rethink.


Yeah, the pfn_valid check is a bit weird by definition because we are
using it to understand whether the address belong to us or to another
VM. To do the pfn_valid check we need to translate the dma address into
something the CPU understands, hence, the dma_to_phys call.

Why can't we use the already-provided paddr? Because paddr has been
translated twice:
1) from dma to maybe-foreign phys address (could be ours, or another VM)
2) from maybe-foreign address to local (using our local mapping of the foreign page)

In fact, it would be clearer if we had all three addresses as parameters
of xen_dma_sync_for_cpu: the dma address, the maybe-foreign physical
address (we tend to call it xenbus address, baddr), the local physical
address. Something like:


void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle,
			  phys_addr_t baddr, phys_addr_t paddr, size_t size,
			  enum dma_data_direction dir)
{
	if (pfn_valid(baddr))
		arch_sync_dma_for_cpu(paddr, size, dir);
	else if (dir != DMA_TO_DEVICE)
		dma_cache_maint(dev, handle, size, GNTTAB_CACHE_INVAL);
}

WARNING: multiple messages have this Message-ID (diff)
From: Stefano Stabellini <sstabellini@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: jgross@suse.com, Stefano Stabellini <sstabellini@kernel.org>,
	konrad.wilk@oracle.com, roman@zededa.com,
	linux-kernel@vger.kernel.org, tamas@tklengyel.com,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	Stefano Stabellini <stefano.stabellini@xilinx.com>
Subject: Re: [PATCH v2 10/11] xen/arm: introduce phys/dma translations in xen_dma_sync_for_*
Date: Mon, 8 Jun 2020 17:38:28 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2006081614530.2815@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <20200608071221.GF15742@infradead.org>

On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> On Wed, Jun 03, 2020 at 03:22:46PM -0700, Stefano Stabellini wrote:
> > From: Stefano Stabellini <stefano.stabellini@xilinx.com>
> > 
> > xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are
> > getting called passing dma addresses. On some platforms dma addresses
> > could be different from physical addresses. Before doing any operations
> > on these addresses we need to convert them back to physical addresses
> > using dma_to_phys.
> > 
> > Add dma_to_phys calls to xen_dma_sync_for_cpu, xen_dma_sync_for_device,
> > and xen_arch_need_swiotlb.
> > 
> > dma_cache_maint is fixed by the next patch.
> 
> The calling conventions because really weird now because
> xen_dma_sync_for_{device,cpu} already get both a phys_addr_t and
> a dma_addr_t.  
> 
> > 
> > -	if (pfn_valid(PFN_DOWN(handle)))
> > +	if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle))))
> 
> But here we translate the dma address to a phys addr
> 
> >  		arch_sync_dma_for_cpu(paddr, size, dir);
> 
> While this still uses the passed in paddr.  I think the uses of
> addresses in this code really needs a major rethink.


Yeah, the pfn_valid check is a bit weird by definition because we are
using it to understand whether the address belong to us or to another
VM. To do the pfn_valid check we need to translate the dma address into
something the CPU understands, hence, the dma_to_phys call.

Why can't we use the already-provided paddr? Because paddr has been
translated twice:
1) from dma to maybe-foreign phys address (could be ours, or another VM)
2) from maybe-foreign address to local (using our local mapping of the foreign page)

In fact, it would be clearer if we had all three addresses as parameters
of xen_dma_sync_for_cpu: the dma address, the maybe-foreign physical
address (we tend to call it xenbus address, baddr), the local physical
address. Something like:


void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle,
			  phys_addr_t baddr, phys_addr_t paddr, size_t size,
			  enum dma_data_direction dir)
{
	if (pfn_valid(baddr))
		arch_sync_dma_for_cpu(paddr, size, dir);
	else if (dir != DMA_TO_DEVICE)
		dma_cache_maint(dev, handle, size, GNTTAB_CACHE_INVAL);
}


  reply	other threads:[~2020-06-09  0:38 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03 22:22 [PATCH v2 00/11] fix swiotlb-xen for RPi4 Stefano Stabellini
2020-06-03 22:22 ` Stefano Stabellini
2020-06-03 22:22 ` [PATCH v2 01/11] swiotlb-xen: use vmalloc_to_page on vmalloc virt addresses Stefano Stabellini
2020-06-03 22:22   ` Stefano Stabellini
2020-06-08  7:04   ` Christoph Hellwig
2020-06-08  7:04     ` Christoph Hellwig
2020-06-08 22:53     ` Stefano Stabellini
2020-06-08 22:53       ` Stefano Stabellini
2020-06-03 22:22 ` [PATCH v2 02/11] swiotlb-xen: remove start_dma_addr Stefano Stabellini
2020-06-03 22:22   ` Stefano Stabellini
2020-06-03 22:22 ` [PATCH v2 03/11] swiotlb-xen: add struct device* parameter to xen_phys_to_bus Stefano Stabellini
2020-06-03 22:22   ` Stefano Stabellini
2020-06-08  7:05   ` Christoph Hellwig
2020-06-08  7:05     ` Christoph Hellwig
2020-06-08 22:55     ` Stefano Stabellini
2020-06-08 22:55       ` Stefano Stabellini
2020-06-03 22:22 ` [PATCH v2 04/11] swiotlb-xen: add struct device* parameter to xen_bus_to_phys Stefano Stabellini
2020-06-03 22:22   ` Stefano Stabellini
2020-06-08  7:05   ` Christoph Hellwig
2020-06-08  7:05     ` Christoph Hellwig
2020-06-03 22:22 ` [PATCH v2 05/11] swiotlb-xen: add struct device* parameter to xen_dma_sync_for_cpu Stefano Stabellini
2020-06-03 22:22   ` Stefano Stabellini
2020-06-03 22:22 ` [PATCH v2 06/11] swiotlb-xen: add struct device* parameter to xen_dma_sync_for_device Stefano Stabellini
2020-06-03 22:22   ` Stefano Stabellini
2020-06-03 22:22 ` [PATCH v2 07/11] swiotlb-xen: add struct device* parameter to is_xen_swiotlb_buffer Stefano Stabellini
2020-06-03 22:22   ` Stefano Stabellini
2020-06-03 22:22 ` [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations Stefano Stabellini
2020-06-03 22:22   ` Stefano Stabellini
2020-06-04 17:46   ` Boris Ostrovsky
2020-06-04 17:46     ` Boris Ostrovsky
2020-06-04 17:47     ` boris.ostrovsky
2020-06-04 17:47       ` boris.ostrovsky
2020-06-08  7:08   ` Christoph Hellwig
2020-06-08  7:08     ` Christoph Hellwig
2020-06-08 23:06     ` Stefano Stabellini
2020-06-08 23:06       ` Stefano Stabellini
2020-06-09  3:46       ` Stefano Stabellini
2020-06-09  3:46         ` Stefano Stabellini
2020-06-09  5:32       ` Christoph Hellwig
2020-06-09  5:32         ` Christoph Hellwig
2020-06-09 21:50         ` Stefano Stabellini
2020-06-09 21:50           ` Stefano Stabellini
2020-06-03 22:22 ` [PATCH v2 09/11] swiotlb-xen: rename xen_phys_to_bus to xen_phys_to_dma and xen_bus_to_phys to xen_dma_to_phys Stefano Stabellini
2020-06-03 22:22   ` Stefano Stabellini
2020-06-08  7:09   ` Christoph Hellwig
2020-06-08  7:09     ` Christoph Hellwig
2020-06-03 22:22 ` [PATCH v2 10/11] xen/arm: introduce phys/dma translations in xen_dma_sync_for_* Stefano Stabellini
2020-06-03 22:22   ` Stefano Stabellini
2020-06-08  7:12   ` Christoph Hellwig
2020-06-08  7:12     ` Christoph Hellwig
2020-06-09  0:38     ` Stefano Stabellini [this message]
2020-06-09  0:38       ` Stefano Stabellini
2020-06-09  5:38       ` Christoph Hellwig
2020-06-09  5:38         ` Christoph Hellwig
2020-06-09  5:39         ` Christoph Hellwig
2020-06-09  5:39           ` Christoph Hellwig
2020-06-09 21:50           ` Stefano Stabellini
2020-06-09 21:50             ` Stefano Stabellini
2020-06-03 22:22 ` [PATCH v2 11/11] xen/arm: call dma_to_phys on the dma_addr_t parameter of dma_cache_maint Stefano Stabellini
2020-06-03 22:22   ` Stefano Stabellini
2020-06-04 18:32 ` [PATCH v2 00/11] fix swiotlb-xen for RPi4 Boris Ostrovsky
2020-06-04 18:32   ` Boris Ostrovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.2006081614530.2815@sstabellini-ThinkPad-T480s \
    --to=sstabellini@kernel.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=hch@infradead.org \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roman@zededa.com \
    --cc=stefano.stabellini@xilinx.com \
    --cc=tamas@tklengyel.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.