[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using Restricted DMA for virtio-pci



On 30 March 2025 18:06:47 BST, "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote:
>> 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.




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.