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>,
	virtio-comment@lists.linux.dev, mst@redhat.com,
	"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: Mon, 7 Apr 2025 00:34:26 -0700	[thread overview]
Message-ID: <Z_OAAthpLmmyKsXM@infradead.org> (raw)
In-Reply-To: <3251F79D-4838-4C89-80BF-6EB19076833A@infradead.org>

On Fri, Apr 04, 2025 at 10:39:35AM +0100, David Woodhouse wrote:
> >> So "for the emulated devices, just use a device model that doesn't do
> >> arbitrary DMA to system memory" is a nice simple answer, and keeps the
> >> guest support restricted to its *own* standalone driver.
> >
> >It's also one that completely breaks the abstraction. 
> 
> Hm? Having a device that simply doesn't *do* any DMA surely doesn't break
> any system DMA / IOMMU abstractions because it's no longer even relevant
> to them, which is kind of the point.
> 
> Which abstraction did you mean?

Implementing a DMA less device is fine.  Implementing a DMA less virtual
device to work around the lack of CoCo shared bounce buffers in the
system is.

> 
> 
> > I still don't
> >understand what the problem is with having the paravirtualized devices
> >on a different part of the virtual PCIe topology so that the stage2
> >IOMMU isn't used for them, but instead just the direct mapping or a
> >stub viommu that blocks all access.
> 
> It can't have a direct mapping because the VMM can't access guest
> memory. It has to be blocked, which is fine.

I only mentioned direct mapping in not having an IOMMU.  I fully expect
it not to work.

> But that's only part of the picture — then how do you actually get data
> in/out of the device?
> 
> By having on-device memory and not attempting DMA to system memory,
> perhaps...? :)

By implementing the discovery of a shared pool in host memory as
discussed in another branch of this thread?

> >describe this limitation, which is much better than hacking around it
> >using an odd device model.
> 
> It still has the problem that existing drivers in all operating systems
> produced before 2030 will see the device and try to use it as-is, with
> no comprehension of this new thing.

Given how much enablement the various CoCo schemes need it won't work
anyway.

Btw, you mail formatting in the last days went completely crazy.

  reply	other threads:[~2025-04-07  7:34 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
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 [this message]
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_OAAthpLmmyKsXM@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).