[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <59be937432fe73b5781ecb04aad501ae5a11be23.camel@infradead.org>
Date: Thu, 03 Apr 2025 08:54:45 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: "Michael S. Tsirkin" <mst@...hat.com>, Zhu Lingshan
<lingshan.zhu@....com>
Cc: virtio-comment@...ts.linux.dev, hch@...radead.org, Claire Chang
<tientzu@...omium.org>, linux-devicetree <devicetree@...r.kernel.org>, Rob
Herring <robh+dt@...nel.org>, Jörg Roedel
<joro@...tes.org>, iommu@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, graf@...zon.de
Subject: Re: [RFC PATCH 1/3] content: Add VIRTIO_F_SWIOTLB to negotiate use
of SWIOTLB bounce buffers
On Thu, 2025-04-03 at 03:34 -0400, Michael S. Tsirkin wrote:
>
> Indeed I personally do not exactly get why implement a virtual system
> without an IOMMU when virtio-iommu is available.
>
> I have a feeling it's about lack of windows drivers for virtio-iommu
> at this point.
And a pKVM (etc.) implementation of virtio-iommu which would allow the
*trusted* part of the hypervisor to know which guest memory should be
shared with the VMM implementing the virtio device models?
You'd also end up in a situation where you have a virtio-iommu for some
devices, and a real two-stage IOMMU (e.g. SMMU or AMD's vIOMMU) for
other devices. Are guest operating systems going to cope well with
that? Do the available discovery mechanisms for all the relevant IOMMUs
even *allow* for that to be expressed?
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)
Powered by blists - more mailing lists