From: Christoph Hellwig <hch@infradead.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"Christoph Hellwig" <hch@infradead.org>,
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: Mon, 7 Apr 2025 00:30:20 -0700 [thread overview]
Message-ID: <Z_N_DNXq9VbPvTfA@infradead.org> (raw)
In-Reply-To: <7fd789b61a586417add2115f6752ebec5e7b81bf.camel@infradead.org>
On Fri, Apr 04, 2025 at 12:15:52PM +0100, David Woodhouse wrote:
> We could achieve that by presenting the device with a completely new
> PCI device/vendor ID so that old drivers don't match, or in the DT
> model you could make a new "compatible" string for it. I chose to use a
> VIRTIO_F_ bit for it instead, which seemed natural and allows the
> device model (under the influence of the system integrator) to *choose*
> whether a failure to negotiate such bit is fatal or not.
Stop thinking about devices. Your CoCo VM will have that exact same
limitation for all devices, because none of them can DMA into random
memory. The solution to the compatibility problem is to just not boot
an OS aware of the exact CoCo scheme into a CoCo VM. Bonus points
for figuring out something clever at the system level that let's the
boot fail gracefully early on for that case.
> The main thing in the CoCo case is that the range in question must not
> contain any memory which an unenlightened guest might treat as normal
> system RAM (because it has to be accessible by the VMM, and that would
> make it insecure if it's being used a general-purpose RAM).
Yes.
> So on x86 it might be an e820-reserved region for example.
Hasn't e820 replaced with something more "elaborate" for UEFI systems
anyway?
> I don't think we want the guest OS just *assuming* that there's usable
> memory in that e820-reserved region, just because some device says that
> it's actually capable of DMA to those addresses.
>
> So it would probably want a separate object, like the separate
> `restricted-dma-pool` in DT, which explicitly identifies that range as
> a DMA bounce-buffer pool. We probably *can* do that even in ACPI with a
> PRP0001 device today, using a `restricted-dma-pool` compatible
> property.
>
> Then the OS would need to spot this range in the config space, and say
> "oh, I *do* have a swiotlb pool this device can reach", and use that.
Yes, that's largely how it should work.
next prev parent reply other threads:[~2025-04-07 7:30 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 [this message]
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_N_DNXq9VbPvTfA@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).