Messages in this thread | | | Subject | Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support | From | Avi Kivity <> | Date | Tue, 6 Oct 2015 18:23:10 +0300 |
| |
On 10/06/2015 05:56 PM, Michael S. Tsirkin wrote: > On Tue, Oct 06, 2015 at 05:43:50PM +0300, Vlad Zolotarov wrote: >> The only "like VFIO" behavior we implement here is binding the MSI-X >> interrupt notification to eventfd descriptor. > There will be more if you add some basic memory protections. > > Besides, that's not true. > Your patch queries MSI capability, sets # of vectors. > You even hinted you want to add BAR mapping down the road.
BAR mapping is already available from sysfs; it is not mandatory.
> VFIO does all of that. >
Copying vfio maintainer Alex (hi!).
vfio's charter is modern iommu-capable configurations. It is designed to be secure enough to be usable by an unprivileged user.
For performance and hardware reasons, many dpdk deployments use uio_pci_generic. They are willing to trade off the security provided by vfio for the performance and deployment flexibility of pci_uio_generic. Forcing these features into vfio will compromise its security and needlessly complicate its code (I guess it can be done with a "null" iommu, but then vfio will have to decide whether it is secure or not).
>> This doesn't justifies the >> hassle of implementing IOMMU-less VFIO mode. > This applies to both VFIO and UIO really. I'm not sure the hassle of > maintaining this functionality in tree is justified. It remains to be > seen whether there are any users that won't taint the kernel. > Apparently not in the current form of the patch, but who knows.
It is not msix that taints the kernel, it's uio_pci_generic. Msix is a tiny feature addition that doesn't change the security situation one bit.
btw, currently you can map BARs and dd to /dev/mem to your heart's content without tainting the kernel. I don't see how you can claim that msix support makes the situation worse, when root can access every bit of physical memory, either directly or via DMA.
| |