linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: virtio-comment@lists.linux.dev, hch@infradead.org,
	"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: Wed, 2 Apr 2025 12:43:47 -0400	[thread overview]
Message-ID: <20250402124131-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <965ccf2f972c5d5f1f4edacb227f03171f20e887.camel@infradead.org>

On Wed, Apr 02, 2025 at 05:16:28PM +0100, David Woodhouse wrote:
> On Wed, 2025-04-02 at 11:51 -0400, Michael S. Tsirkin wrote:
> > On Wed, Apr 02, 2025 at 04:47:18PM +0100, David Woodhouse wrote:
> > > On Wed, 2025-04-02 at 11:20 -0400, Michael S. Tsirkin wrote:
> > > > On Wed, Apr 02, 2025 at 04:12:39PM +0100, David Woodhouse wrote:
> > > > > On Wed, 2025-04-02 at 10:54 -0400, Michael S. Tsirkin wrote:
> > > > > > > +  If a the device transport provides a software IOTLB bounce buffer,
> > > > > > > +  addresses within its range are not subject to the requirements of
> > > > > > > +  VIRTIO_F_ACCESS_PLATFORM as they are considered to be ``on-device''
> 
> ...
> 
> > The text you wrote makes it seem that even if the platform says use
> > an IOMMU, it should be bypassed.
> 
> It was trying just to state the obvious, that addresses within the
> range of the *on-device* memory buffer are not handled by the IOMMU.
> 
> > I would drop this text, and maybe add some clarification in the mmio transport,
> > as needed.
> 
> It would be PCI too. I guess we could move the "obvious" comment that
> 'addresses within the range of the SWIOTLB bounce buffer region are
> considered to be "on-device" and are thus not affected by the
> requirements of VIRTIO_F_ACCESS_PLATFORM' into *both* the MMIO and PCI
> transport docs? But then it's basically just saying the same thing in
> two different locations?
> 
> I don't think we're debating what the actual implementations should
> *do* ...  are we? To me it's obvious that what I'm trying to say here
> *should* always be true.
> 
> We're just debating the wording and where to put it, yes?

yes.

I know a bit more about PCI, and for PCI I prefer just not saying
anything. The platform already defines whether it is behind an iommu
or not, and duplication is not good.

For mmio it is my understanding that the "restricted" does the same
already? or is it required in the spec for some reason?




  reply	other threads:[~2025-04-02 16:43 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 [this message]
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
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=20250402124131-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=graf@amazon.de \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).