Thread (35 messages) flat view 35 messages, 7 authors, 2025-03-31

Re: Using Restricted DMA for virtio-pci

From: David Woodhouse <dwmw2@infradead.org>
Date: 2025-03-30 21:28:36
Also in: linux-devicetree, lkml, virtualization, xen-devel

On 30 March 2025 18:06:47 BST, "Michael S. Tsirkin" [off-list ref] wrote:
quoted
It's basically just allowing us to expose through PCI, what I believe
we can already do for virtio in DT.
I am not saying I am against this extension.
The idea to restrict DMA has a lot of merit outside pkvm.
For example, with a physical devices, limiting its DMA
to a fixed range can be good for security at a cost of
an extra data copy.

So I am not saying we have to block this specific hack.

what worries me fundamentally is I am not sure it works well
e.g. for physical virtio cards.
Not sure why it doesn't work for physical cards. They don't need to be bus-mastering; they just take data from a buffer in their own RAM.
Attempts to pass data between devices will now also require
extra data copies.
Yes. I think that's acceptable, but if we really cared we could perhaps extend the capability to refer to a range inside a given BAR on a specific *device*? Or maybe just *function*, and allow sharing of SWIOTLB buffer within a multi-function device?

I think it's overkill though.
Did you think about adding an swiotlb mode to virtio-iommu at all?
Much easier than parsing page tables.
Often the guests which need this will have a real IOMMU for the true pass-through devices. Adding a virtio-iommu into the mix (or any other system-wide way of doing something different for certain devices) is problematic.

The on-device buffer keeps it nice and simple, and even allows us to do device support for operating systems like Windows where it's a lot harder to do anything generic in the core OS.

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help