From: Jason Gunthorpe <jgg@ziepe.ca>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Roman Kisel <romank@linux.microsoft.com>,
Robin Murphy <robin.murphy@arm.com>,
aleksander.lobakin@intel.com, andriy.shevchenko@linux.intel.com,
arnd@arndb.de, bp@alien8.de, catalin.marinas@arm.com,
corbet@lwn.net, dakr@kernel.org, dave.hansen@linux.intel.com,
decui@microsoft.com, gregkh@linuxfoundation.org,
haiyangz@microsoft.com, hch@lst.de, hpa@zytor.com,
James.Bottomley@hansenpartnership.com,
Jonathan.Cameron@huawei.com, kys@microsoft.com, leon@kernel.org,
lukas@wunner.de, luto@kernel.org, m.szyprowski@samsung.com,
martin.petersen@oracle.com, mingo@redhat.com,
peterz@infradead.org, quic_zijuhu@quicinc.com,
tglx@linutronix.de, wei.liu@kernel.org, will@kernel.org,
iommu@lists.linux.dev, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org, x86@kernel.org, apais@microsoft.com,
benhill@microsoft.com, bperkins@microsoft.com,
sunilmut@microsoft.com, Suzuki K Poulose <suzuki.poulose@arm.com>,
linux-coco@lists.linux.dev
Subject: Re: [PATCH hyperv-next 5/6] arch, drivers: Add device struct bitfield to not bounce-buffer
Date: Thu, 10 Apr 2025 20:50:08 -0300 [thread overview]
Message-ID: <20250410235008.GC63245@ziepe.ca> (raw)
In-Reply-To: <67f703099f124_71fe2949e@dwillia2-xfh.jf.intel.com.notmuch>
On Wed, Apr 09, 2025 at 04:30:17PM -0700, Dan Williams wrote:
> Like Christoph said, a driver really has no business opting itself into
> different DMA addressing domains. For TDISP we are also being careful to
> make sure that flipping a device from shared to private is a suitably
> violent event. This is because the Linux DMA layer does not have a
> concept of allowing a device to have mappings from two different
> addressing domains simultaneously.
And this is a very important point, several of the architectures have
two completely independent iommu tables, and maybe even completely
different IOMMU instances for trusted and non-trusted DMA traffic.
I expect configurations where trusted traffic is translated through
the vIOMMU while non-trusted traffic is locked to an identity
translation.
There are more issue here than just swiotlb :\
> A "private_capable" flag might also make sense, but that is really a
> property of a bus that need not be carried necessarily in 'struct
> device'.
However it works, it should be done before the driver is probed and
remain stable for the duration of the driver attachment. From the
iommu side the correct iommu domain, on the correct IOMMU instance to
handle the expected traffic should be setup as the DMA API's iommu
domain.
Jason
next prev parent reply other threads:[~2025-04-10 23:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 0:08 [PATCH hyperv-next 0/6] Confidential VMBus Roman Kisel
2025-04-09 0:08 ` [PATCH hyperv-next 1/6] Documentation: hyperv: " Roman Kisel
2025-04-10 16:54 ` ALOK TIWARI
2025-04-10 19:10 ` Roman Kisel
2025-04-25 6:31 ` Wei Liu
2025-04-09 0:08 ` [PATCH hyperv-next 2/6] drivers: hyperv: VMBus protocol version 6.0 Roman Kisel
2025-04-10 17:03 ` ALOK TIWARI
2025-04-09 0:08 ` [PATCH hyperv-next 3/6] arch: hyperv: Get/set SynIC synth.registers via paravisor Roman Kisel
2025-04-09 0:08 ` [PATCH hyperv-next 4/6] arch: x86, drivers: hyperv: Enable confidential VMBus Roman Kisel
2025-04-09 0:08 ` [PATCH hyperv-next 5/6] arch, drivers: Add device struct bitfield to not bounce-buffer Roman Kisel
2025-04-09 10:52 ` Christoph Hellwig
2025-04-09 15:27 ` Roman Kisel
2025-04-09 16:03 ` Robin Murphy
2025-04-09 16:44 ` Roman Kisel
2025-04-09 23:30 ` Dan Williams
2025-04-10 1:16 ` Michael Kelley
2025-04-11 0:03 ` Dan Williams
2025-04-10 7:23 ` Christoph Hellwig
2025-04-10 23:44 ` Jason Gunthorpe
2025-04-10 23:50 ` Jason Gunthorpe [this message]
2025-04-10 7:21 ` Christoph Hellwig
2025-04-10 15:16 ` Roman Kisel
2025-04-09 0:08 ` [PATCH hyperv-next 6/6] drivers: SCSI: Do not bounce-bufffer for the confidential VMBus Roman Kisel
2025-04-09 10:53 ` Christoph Hellwig
2025-04-09 15:36 ` Roman Kisel
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=20250410235008.GC63245@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=James.Bottomley@hansenpartnership.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=aleksander.lobakin@intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=apais@microsoft.com \
--cc=arnd@arndb.de \
--cc=benhill@microsoft.com \
--cc=bp@alien8.de \
--cc=bperkins@microsoft.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=gregkh@linuxfoundation.org \
--cc=haiyangz@microsoft.com \
--cc=hch@lst.de \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux.dev \
--cc=kys@microsoft.com \
--cc=leon@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=luto@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=martin.petersen@oracle.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=quic_zijuhu@quicinc.com \
--cc=robin.murphy@arm.com \
--cc=romank@linux.microsoft.com \
--cc=sunilmut@microsoft.com \
--cc=suzuki.poulose@arm.com \
--cc=tglx@linutronix.de \
--cc=wei.liu@kernel.org \
--cc=will@kernel.org \
--cc=x86@kernel.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 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).