public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
	"j.granados@samsung.com" <j.granados@samsung.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Jason Gunthorpe <jgg@ziepe.ca>, Klaus Jensen <its@irrelevant.dk>
Cc: baolu.lu@linux.intel.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>
Subject: Re: [PATCH v2 1/5] iommu/vt-d: Separate page request queue from SVM
Date: Sat, 14 Sep 2024 13:49:44 +0800	[thread overview]
Message-ID: <c8708b95-14b9-4545-84f7-6f45161456cc@linux.intel.com> (raw)
In-Reply-To: <BN9PR11MB527611131A808B78C8E0E8388C662@BN9PR11MB5276.namprd11.prod.outlook.com>

On 2024/9/14 10:53, Tian, Kevin wrote:
>> From: Baolu Lu<baolu.lu@linux.intel.com>
>> Sent: Saturday, September 14, 2024 9:18 AM
>>
>> On 9/14/24 8:52 AM, Tian, Kevin wrote:
>>>> From: Joel Granados via B4 Relay
>>>> <devnull+j.granados.samsung.com@kernel.org>
>>>>
>>>> From: Joel Granados<j.granados@samsung.com>
>>>>
>>>> IO page faults are no longer dependent on CONFIG_INTEL_IOMMU_SVM.
>>>> Move
>>>> all Page Request Queue (PRQ) functions that handle prq events to a new
>>>> file in drivers/iommu/intel/prq.c. The page_req_des struct is now
>>>> declared in drivers/iommu/intel/prq.c.
>>>>
>>>> No functional changes are intended. This is a preparation patch to
>>>> enable the use of IO page faults outside the SVM/PASID use cases.
>>> Do we want to guard it under a new config option e.g.
>>> CONFIG_INTEL_IOMMU_IOPF? it's unnecessary to allocate resources
>>> for the majority usages which don't require IOPF.
>>>
>>> Baolu?
>> The OS builder doesn't know if Linux will run on a platform with PRI-
>> capable devices. They'll probably always enable this option if we
>> provide it.
> hmm then why do we need a SVM option? In reality I haven't seen
> a platform which supports IOPF but no pasid/SVM. so the reason
> for whether to have an option should be same between IOPF/SVM.
> 
> IMHO the point of options is to allow reducing footprint of the kernel
> image and many options are probably always enabled in distributions...

To be honest, I would hope to remove the SVM option some day. It's
nothing special except listening to an external notification and
synchronize the caches when the page table is updated. It's common to
all cases where a page table is shared between the IOMMU and another
component.

As for CONFIG_INTEL_IOMMU_IOPF, my suggestion is that we don't need to
add any unnecessary options unless we see a real need.

Thanks,
baolu

  reply	other threads:[~2024-09-14  5:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-13 11:44 [PATCH v2 0/5] iommu: Enable user space IOPFs in non-PASID and non-svm cases Joel Granados via B4 Relay
2024-09-13 11:44 ` [PATCH v2 1/5] iommu/vt-d: Separate page request queue from SVM Joel Granados via B4 Relay
2024-09-14  0:52   ` Tian, Kevin
2024-09-14  1:18     ` Baolu Lu
2024-09-14  2:53       ` Tian, Kevin
2024-09-14  5:49         ` Baolu Lu [this message]
2024-09-15 13:49           ` Jason Gunthorpe
2024-09-16 13:02             ` Joel Granados
2024-09-18  2:52             ` Baolu Lu
2024-09-18  8:20           ` Tian, Kevin
2024-09-18 11:17             ` Baolu Lu
2024-09-20 12:54               ` Jason Gunthorpe
2024-10-07 10:46                 ` Joel Granados
2024-09-16  9:24     ` Joel Granados
2024-09-13 11:44 ` [PATCH v2 2/5] iommu/vt-d: Remove the pasid present check in prq_event_thread Joel Granados via B4 Relay
2024-09-14  0:52   ` Tian, Kevin
2024-09-13 11:44 ` [PATCH v2 3/5] iommu: kconfig: Move IOMMU_IOPF into INTEL_IOMMU Joel Granados via B4 Relay
2024-09-13 11:44 ` [PATCH v2 4/5] iommufd: Enable PRI when doing the iommufd_hwpt_alloc Joel Granados via B4 Relay
2024-09-14  0:56   ` Tian, Kevin
2024-09-13 11:44 ` [PATCH v2 5/5] iommu/vt-d: drop pasid requirement for prq initialization Joel Granados via B4 Relay
2024-09-14  0:56   ` Tian, Kevin
2024-09-14  0:48 ` [PATCH v2 0/5] iommu: Enable user space IOPFs in non-PASID and non-svm cases Tian, Kevin
2024-09-16  8:50   ` Joel Granados
2024-09-20  6:57     ` Tian, Kevin
2024-10-07 10:42       ` Joel Granados

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c8708b95-14b9-4545-84f7-6f45161456cc@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=its@irrelevant.dk \
    --cc=j.granados@samsung.com \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox