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 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations
Date: Tue, 9 Jun 2020 14:50:46 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.21.2006091246350.2815@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <20200609053240.GA3015@infradead.org>
On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> On Mon, Jun 08, 2020 at 04:06:57PM -0700, Stefano Stabellini wrote:
> > I understand what you are suggesting about having something like:
> >
> > xen_phys_to_dma(...)
> > {
> > phys_addr_t phys = xen_phys_to_bus(dev, paddr)
> > return phys_to_dma(phys);
> > }
> >
> > I thought about it myself. I'll do it.
>
> "something", yes. Except that I think the bus is a little confusing,
> isn't it? What is the Xen term for these addresses?
Xen reasons in terms of frame numbers. Xen calls them "dfn" for device
frame number. They were supposed to be called "bfn" but eventually they
settled for a different name when the series was committed.
I could s/bfn/dfn/g to match the terminology, if that helps.
> Also we probably don't need the extra local variable.
Sure
> > But I don't think I understood the comment about XEN_PFN_PHYS.
>
> There is a comment above xen_phys_to_bus that it avoids using
> XEN_PFN_PHYS because XEN_PFN_PHYS of the phys_addr_t vs dma_addr_t
> mismatch. But XEN_PFN_PHYS could just use a u64 instead of the
> phys_addr_t and then we could use it. Especially as XEN_PFN_PHYS
> isn't actually used anywhere except in swiotlb-xen.c. Or we could
> remove XEN_PFN_PHYS enirely, as it isn't all that useful to start
> with.
I'll remove it.
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 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations
Date: Tue, 9 Jun 2020 14:50:46 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.21.2006091246350.2815@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <20200609053240.GA3015@infradead.org>
On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> On Mon, Jun 08, 2020 at 04:06:57PM -0700, Stefano Stabellini wrote:
> > I understand what you are suggesting about having something like:
> >
> > xen_phys_to_dma(...)
> > {
> > phys_addr_t phys = xen_phys_to_bus(dev, paddr)
> > return phys_to_dma(phys);
> > }
> >
> > I thought about it myself. I'll do it.
>
> "something", yes. Except that I think the bus is a little confusing,
> isn't it? What is the Xen term for these addresses?
Xen reasons in terms of frame numbers. Xen calls them "dfn" for device
frame number. They were supposed to be called "bfn" but eventually they
settled for a different name when the series was committed.
I could s/bfn/dfn/g to match the terminology, if that helps.
> Also we probably don't need the extra local variable.
Sure
> > But I don't think I understood the comment about XEN_PFN_PHYS.
>
> There is a comment above xen_phys_to_bus that it avoids using
> XEN_PFN_PHYS because XEN_PFN_PHYS of the phys_addr_t vs dma_addr_t
> mismatch. But XEN_PFN_PHYS could just use a u64 instead of the
> phys_addr_t and then we could use it. Especially as XEN_PFN_PHYS
> isn't actually used anywhere except in swiotlb-xen.c. Or we could
> remove XEN_PFN_PHYS enirely, as it isn't all that useful to start
> with.
I'll remove it.
next prev parent reply other threads:[~2020-06-09 21:50 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 [this message]
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
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.2006091246350.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.