From: Ben Horgan <ben.horgan@arm.com>
To: Qinxin Xia <xiaqinxin@huawei.com>
Cc: amitsinght@marvell.com, baisheng.gao@unisoc.com,
baolin.wang@linux.alibaba.com, carl@os.amperecomputing.com,
dave.martin@arm.com, david@kernel.org, dfustini@baylibre.com,
fenghuay@nvidia.com, gshan@redhat.com, james.morse@arm.com,
jonathan.cameron@huawei.com, kobak@nvidia.com,
lcherian@marvell.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, peternewman@google.com,
punit.agrawal@oss.qualcomm.com, quic_jiles@quicinc.com,
reinette.chatre@intel.com, rohit.mathew@arm.com,
scott@os.amperecomputing.com, sdonthineni@nvidia.com,
xhao@linux.alibaba.com, zengheng4@huawei.com,
Linuxarm <linuxarm@huawei.com>
Subject: Re: [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'
Date: Mon, 13 Apr 2026 16:02:51 +0100 [thread overview]
Message-ID: <0d578c61-1341-4149-9e8c-936ea0ce0c50@arm.com> (raw)
In-Reply-To: <7b2681c3-9ef7-4882-ba57-2503934e2759@huawei.com>
Hi Qinxin,
On 4/3/26 03:44, Qinxin Xia wrote:
>
>
> On 2026/3/27 18:47:49, Ben Horgan <ben.horgan@arm.com> wrote:
>> Hi Qinxin,
>>
>> On 3/27/26 10:21, Qinxin Xia wrote:
>>>
>>> Hello everyone!
>>>
>>> In earlier versions, mpam supports the configuration of iommu_groups.
>>>
>>> 823 static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of,
>>> 824 char *buf, size_t nbytes,
>>> loff_t off)
>>> 825 {
>>> 826 struct rdtgroup *rdtgrp;
>>> 827 int iommu_group_id;
>>> 828 bool is_iommu;
>>> 829 char *pid_str;
>>> 830 int ret = 0;
>>> 831 pid_t pid;
>>> 832
>>> 833 rdtgrp = rdtgroup_kn_lock_live(of->kn);
>>> 834 if (!rdtgrp) {
>>> 835 rdtgroup_kn_unlock(of->kn);
>>> 836 return -ENOENT;
>>> 837 }
>>> 838 rdt_last_cmd_clear();
>>> 839
>>> 840 if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED ||
>>> 841 rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
>>> 842 ret = -EINVAL;
>>> 843 rdt_last_cmd_puts("Pseudo-locking in progress\n");
>>> 844 goto unlock;
>>> 845 }
>>> 846
>>> 847 while (buf && buf[0] != '\0' && buf[0] != '\n') {
>>> 848 pid_str = strim(strsep(&buf, ","));
>>> 849
>>> 850 is_iommu = string_is_iommu_group(pid_str, &iommu_group_id);
>>>
>>> What puzzles me is why we would put it under 'task'—this seems a little
>>> strange to users.It seems they are not related.Why don't we add a new
>>> interface like 'iommu'?
>>
>> I think it is likely that this interface would change if upstream support is added.
>>
>
> I have done some work in this direction before, and I will release an
> RFC later for further discussion.:-)
Looking forward to seeing it.
Ben
>
>>>
>>> 851 if (is_iommu)
>>> 852 ret = rdtgroup_move_iommu(iommu_group_id, rdtgrp, of);
>>> 853 else if (kstrtoint(pid_str, 0, &pid)) {
>>> 854 rdt_last_cmd_printf("Task list parsing error pid %s\n", pid_str);
>>> 855 ret = -EINVAL;
>>> 856 break;
>>> 857 }
>>> 858
>>> 859 if (pid < 0) {
>>> 860 rdt_last_cmd_printf("Invalid pid %d\n", pid);
>>> 861 ret = -EINVAL;
>>> 862 break;
>>> 863 }
>>> 864
>>>
>>> In future glue versions, will you re-enable support for iommu_group, and
>>> if so, will the configuration scheme be changed?
>>
>> Please can you let us know about your usecase so that we can get more information to decide
>> what the best interface would be?
>>
>> Thanks,
>>
>> Ben
>>
>>
>>
>
> We want to use the iommu mpam to implement stream control for different
> PCIe devices. By limiting the access bandwidth of some PCIe devices, the
> high-priority service devices can obtain more resources.
>
next prev parent reply other threads:[~2026-04-13 15:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-27 10:21 [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task' Qinxin Xia
2026-03-27 10:47 ` Ben Horgan
2026-04-03 2:44 ` Qinxin Xia
2026-04-13 15:02 ` Ben Horgan [this message]
2026-04-15 1:27 ` Zeng Heng
2026-04-15 12:42 ` Ben Horgan
2026-04-16 3:02 ` Zeng Heng
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=0d578c61-1341-4149-9e8c-936ea0ce0c50@arm.com \
--to=ben.horgan@arm.com \
--cc=amitsinght@marvell.com \
--cc=baisheng.gao@unisoc.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=carl@os.amperecomputing.com \
--cc=dave.martin@arm.com \
--cc=david@kernel.org \
--cc=dfustini@baylibre.com \
--cc=fenghuay@nvidia.com \
--cc=gshan@redhat.com \
--cc=james.morse@arm.com \
--cc=jonathan.cameron@huawei.com \
--cc=kobak@nvidia.com \
--cc=lcherian@marvell.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=peternewman@google.com \
--cc=punit.agrawal@oss.qualcomm.com \
--cc=quic_jiles@quicinc.com \
--cc=reinette.chatre@intel.com \
--cc=rohit.mathew@arm.com \
--cc=scott@os.amperecomputing.com \
--cc=sdonthineni@nvidia.com \
--cc=xhao@linux.alibaba.com \
--cc=xiaqinxin@huawei.com \
--cc=zengheng4@huawei.com \
/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