devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: "Christoph Hellwig" <hch@infradead.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	virtio-comment@lists.linux.dev,
	"Claire Chang" <tientzu@chromium.org>,
	linux-devicetree <devicetree@vger.kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Jörg Roedel" <joro@8bytes.org>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	graf@amazon.de
Subject: Re: [RFC PATCH 1/3] content: Add VIRTIO_F_SWIOTLB to negotiate use of SWIOTLB bounce buffers
Date: Thu, 3 Apr 2025 23:44:40 -0700	[thread overview]
Message-ID: <Z-9_2IDmEWLKDKgj@infradead.org> (raw)
In-Reply-To: <488D32C6-77FA-4CC8-988F-CD4D14548D4B@infradead.org>

On Fri, Apr 04, 2025 at 07:39:02AM +0100, David Woodhouse wrote:
> Plumbing a 65th address space bit through all descriptors seems impractical. Would it suffice for the driver to *specify* the location in the device's DMA address space that the on-device buffer appears, to allow it to avoid conflicts with system memory addresses? Better ideas?

That's what NVMe currently does in it's second attempt to get things
wrong.  It mostly works for the current use cases, but there might
actually not be a single canonical address where it is mapped.  This
was mostly theoretical, but with SVM and especially SIOV it is becoming
a real thing now.

In the worst case you might have to limit yourself to one address space
per request.  Or have a bitmap which buffer in the request uses which
address space.

  reply	other threads:[~2025-04-04  6:44 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-02 11:04 [RFC PATCH 0/3] Add Software IOTLB bounce buffer support David Woodhouse
2025-04-02 11:04 ` [RFC PATCH 1/3] content: Add VIRTIO_F_SWIOTLB to negotiate use of SWIOTLB bounce buffers David Woodhouse
2025-04-02 14:54   ` Michael S. Tsirkin
2025-04-02 15:12     ` David Woodhouse
2025-04-02 15:20       ` Michael S. Tsirkin
2025-04-02 15:47         ` David Woodhouse
2025-04-02 15:51           ` Michael S. Tsirkin
2025-04-02 16:16             ` David Woodhouse
2025-04-02 16:43               ` Michael S. Tsirkin
2025-04-02 17:10                 ` David Woodhouse
2025-04-03  7:29                   ` Christoph Hellwig
2025-04-03  7:37                     ` David Woodhouse
2025-04-03  7:39                       ` Christoph Hellwig
2025-04-03  7:43                         ` Michael S. Tsirkin
2025-04-03  7:44                           ` Christoph Hellwig
2025-04-03  8:10                         ` David Woodhouse
2025-04-04  6:29                           ` Christoph Hellwig
2025-04-04  6:39                             ` David Woodhouse
2025-04-04  6:44                               ` Christoph Hellwig [this message]
2025-04-04  6:45                                 ` Christoph Hellwig
2025-04-03  7:41                       ` Michael S. Tsirkin
2025-04-03  7:31                   ` Michael S. Tsirkin
2025-04-03  7:45                     ` David Woodhouse
2025-04-03  8:06                       ` Michael S. Tsirkin
2025-04-03  7:13   ` Zhu Lingshan
2025-04-03  7:24     ` David Woodhouse
2025-04-03  7:31       ` Zhu Lingshan
2025-04-04 10:27         ` David Woodhouse
2025-04-03  7:34     ` Michael S. Tsirkin
2025-04-03  7:54       ` David Woodhouse
2025-04-03  8:13         ` Michael S. Tsirkin
2025-04-03  8:22           ` David Woodhouse
2025-04-03  8:34             ` Zhu Lingshan
2025-04-03  8:57               ` David Woodhouse
2025-04-06  6:23                 ` Zhu Lingshan
2025-04-03 13:19             ` Michael S. Tsirkin
2025-04-03  7:24   ` Christoph Hellwig
2025-04-03  7:28     ` David Woodhouse
2025-04-03  7:35       ` Christoph Hellwig
2025-04-03  8:06         ` David Woodhouse
2025-04-04  6:35           ` Christoph Hellwig
2025-04-04  7:50             ` David Woodhouse
2025-04-04  8:09               ` Michael S. Tsirkin
2025-04-04  8:16                 ` David Woodhouse
2025-04-04  8:32                   ` Michael S. Tsirkin
2025-04-04  9:27                     ` David Woodhouse
2025-04-04 10:15                       ` David Woodhouse
2025-04-04 10:37                         ` Michael S. Tsirkin
2025-04-04 11:15                           ` David Woodhouse
2025-04-06 18:28                             ` Michael S. Tsirkin
2025-04-06 18:47                               ` David Woodhouse
2025-04-07  7:30                             ` Christoph Hellwig
2025-04-07  7:54                               ` David Woodhouse
2025-04-07  9:05                                 ` Christoph Hellwig
2025-04-07 10:09                                   ` David Woodhouse
2025-04-07 14:06                                     ` Christoph Hellwig
2025-04-07 14:59                                       ` David Woodhouse
2025-04-07 12:14                             ` Michael S. Tsirkin
2025-04-07 12:46                               ` David Woodhouse
2025-04-07  7:26                           ` Christoph Hellwig
2025-04-07  7:23                         ` Christoph Hellwig
2025-04-07  7:19                   ` Christoph Hellwig
2025-04-04  8:23               ` Christoph Hellwig
2025-04-04  9:39                 ` David Woodhouse
2025-04-07  7:34                   ` Christoph Hellwig
2025-04-07  9:40                     ` David Woodhouse
2025-04-02 11:04 ` [RFC PATCH 2/3] transport-mmio: Document restricted-dma-pool SWIOTLB bounce buffer David Woodhouse
2025-04-02 11:04 ` [RFC PATCH 3/3] transport-pci: Add SWIOTLB bounce buffer capability David Woodhouse
2025-04-02 14:58   ` Michael S. Tsirkin
2025-04-02 15:21     ` David Woodhouse
2025-04-03  7:27   ` Michael S. Tsirkin
2025-04-03  7:36     ` Zhu Lingshan
2025-04-03  7:37       ` Michael S. Tsirkin
2025-04-03  8:12         ` Zhu Lingshan
2025-04-03  8:16           ` Michael S. Tsirkin
2025-04-03  8:37             ` Zhu Lingshan
2025-04-03  8:44     ` David Woodhouse

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=Z-9_2IDmEWLKDKgj@infradead.org \
    --to=hch@infradead.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=graf@amazon.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=tientzu@chromium.org \
    --cc=virtio-comment@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).