From: Christoph Hellwig <hch@infradead.org> To: Stefano Stabellini <sstabellini@kernel.org> Cc: Christoph Hellwig <hch@infradead.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: Mon, 8 Jun 2020 22:32:40 -0700 [thread overview] Message-ID: <20200609053240.GA3015@infradead.org> (raw) In-Reply-To: <alpine.DEB.2.21.2006081558400.2815@sstabellini-ThinkPad-T480s> 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? Also we probably don't need the extra local variable. > 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.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org> To: Stefano Stabellini <sstabellini@kernel.org> Cc: jgross@suse.com, tamas@tklengyel.com, konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, Christoph Hellwig <hch@infradead.org>, 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: Mon, 8 Jun 2020 22:32:40 -0700 [thread overview] Message-ID: <20200609053240.GA3015@infradead.org> (raw) In-Reply-To: <alpine.DEB.2.21.2006081558400.2815@sstabellini-ThinkPad-T480s> 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? Also we probably don't need the extra local variable. > 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.
next prev parent reply other threads:[~2020-06-09 5:32 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 [this message] 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 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=20200609053240.GA3015@infradead.org \ --to=hch@infradead.org \ --cc=boris.ostrovsky@oracle.com \ --cc=jgross@suse.com \ --cc=konrad.wilk@oracle.com \ --cc=linux-kernel@vger.kernel.org \ --cc=roman@zededa.com \ --cc=sstabellini@kernel.org \ --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: linkBe 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.