On Wed, Nov 06, 2024 at 12:38:02PM +0000, Srujana Challa wrote: > > Subject: Re: [EXTERNAL] Re: [PATCH v2 0/2] vhost-vdpa: Add support for NO- > > IOMMU mode > > > > On Wed, Oct 23, 2024 at 04: 19: 02AM -0400, Michael S. Tsirkin wrote: > On > > Tue, Oct 22, 2024 at 11: 58: 19PM -0700, Christoph Hellwig wrote: > > On Sat, > > Oct 19, 2024 at 08: 16: 44PM -0400, Michael S. Tsirkin wrote: > > > Because > > > > On Wed, Oct 23, 2024 at 04:19:02AM -0400, Michael S. Tsirkin wrote: > > > On Tue, Oct 22, 2024 at 11:58:19PM -0700, Christoph Hellwig wrote: > > > > On Sat, Oct 19, 2024 at 08:16:44PM -0400, Michael S. Tsirkin wrote: > > > > > Because people want to move from some vendor specific solution > > > > > with vfio to a standard vdpa compatible one with vdpa. > > > > > > > > So now you have a want for new use cases and you turn that into a > > > > must for supporting completely insecure and dangerous crap. > > > > > > Nope. > > > > > > kernel is tainted -> unsupported > > > > > > whoever supports tainted kernels is already in dangerous waters. > > > > That's not a carte blanche for doing whatever crazy stuff you want. > > > > And if you don't trust me I'll add Greg who has a very clear opinion on > > IOMMU-bypassing user I/O hooks in the style of the uio driver as well I think > > :) > > It is going in circles, let me give the summary, > Issue: We need to address the lack of no-IOMMU support in the vhost vDPA driver for better performance. > Measured Performance: On the machine "13th Gen Intel(R) Core(TM) i9-13900K, 32 Cores", we observed > a performance improvement of 70 - 80% with intel_iommu=off when we run high-throughput network > packet processing. > Rationale for Fix: High-end machines which gives better performance with IOMMU are very expensive, > and certain use cases, such as embedded environment and trusted applications, do not require > the security features provided by IOMMU. > Initial Approach: We initially considered a driver-based solution, specifically integrating no-IOMMU > support into Marvell’s octep-vdpa driver. > Initial Community Feedback: The community suggested adopting a VFIO-like scheme to make the solution > more generic and widely applicable. > Decision Point: Should we pursue a generic approach for no-IOMMU support in the vhost vDPA driver, > or should we implement a driver-specific solution? > > Thanks, > Srujana. This point does not matter for Christoph. -- MST
