linux-kernel - Re: [PATCH v2 1/5] iommu/vt-d: Separate page request queue from SVM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241007104611.bipxx4vao4n3hg3m@joelS2.panther.com>
Date: Mon, 7 Oct 2024 12:46:11 +0200
From: Joel Granados <joel.granados@...nel.org>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Baolu Lu <baolu.lu@...ux.intel.com>,
	"Tian, Kevin" <kevin.tian@...el.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
	Robin Murphy <robin.murphy@....com>,
	Klaus Jensen <its@...elevant.dk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>
Subject: Re: [PATCH v2 1/5] iommu/vt-d: Separate page request queue from SVM

On Fri, Sep 20, 2024 at 09:54:34AM -0300, Jason Gunthorpe wrote:
> On Wed, Sep 18, 2024 at 07:17:32PM +0800, Baolu Lu wrote:
> > > more than that... for each IOMMU the current code allocates 16 pages
> > > and 1 hwirq. Those are unnecessary burdens in majority deployments
> > > which don't support/require I/O page faults.
> > 
> > Yeah! I only focused on the kernel binary size but ignored these system
> > resources consumed by IOPF. Then, perhaps
> 
> If you care about runtime overhead it should be delt with by
> dynamically allocating the memory and enabling it, not via kconfig
> 
> We can dynmaically add IRQS in some cases now for instance
> 
> Jason

Summary (Please correct if inaccurate):
1. Kevin Tian & Baolu Lu have proposed a kconfig guard
   (INTEL_IOMMU_IOPF) to avoid unnecessary resource allocation (of 16
   pages and 1 hwirq). It can be keep it until it becomes a burden.
2. Jason Gunthorp: runtime overhead should be handled by dynamically
   allocating memory and enabling it. Not via Kconfig.

There was no real consensus reached here. I'll leave IOMMU_IOPF guarded
under INTEL_IOMMU (no changes from V2), two reasons for this IMO:
1. The reasoning being that any system that has the resources for
   INTEL_IOMMU has them for IOMMU_IOPF.
2. If the IOPF resources are a burden, they should be solved by changing
   the way we allocate memory instead of hiding them behind a kconfig.

Quick Note: I am adding my new email to the thread so I get the responses
routed to the correct inbox.

Best

-- 

Joel Granados