[Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'

[Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'

[Qinxin Xia]

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'?

  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?

-- 
Thanks,
Qinxin

Re: [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'

[Ben Horgan]

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.

> 
>  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

Re: [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'

[Qinxin Xia]

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.:-)

>>
>>   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.

-- 
Thanks,
Qinxin

Re: [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'

[Ben Horgan]

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.
> 

Re: [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'

[Zeng Heng]

Hi Ben,

On 2026/4/13 23:02, Ben Horgan wrote:
> 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
> 

Following the current SMMU approach, I've submitted several bugfix
patches for the MPAM driver, but haven't received any review feedback
yet.

To avoid these being overlooked, I'd like to kindly remind to take a
look:
v2: 
https://lore.kernel.org/all/20260414032610.1523958-1-zengheng4@huawei.com/
v1: 
https://lore.kernel.org/all/20251107063300.1580046-1-zengheng4@huawei.com/

Additionally, I'd like to check on the status of this branch — is it
still actively maintained? It would be helpful to understand the future
plans for MPAM development.


Thanks for your time,
Zeng Heng

Re: [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'

[Ben Horgan]

Hi Zeng,

On 4/15/26 02:27, Zeng Heng wrote:
> Hi Ben,
> 
> On 2026/4/13 23:02, Ben Horgan wrote:
>> 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
>>
> 
> Following the current SMMU approach, I've submitted several bugfix
> patches for the MPAM driver, but haven't received any review feedback
> yet.
> 
> To avoid these being overlooked, I'd like to kindly remind to take a
> look:
> v2: https://lore.kernel.org/all/20260414032610.1523958-1-zengheng4@huawei.com/
> v1: https://lore.kernel.org/all/20251107063300.1580046-1-zengheng4@huawei.com/
> 
> Additionally, I'd like to check on the status of this branch — is it
> still actively maintained? It would be helpful to understand the future
> plans for MPAM development.

The MPAM snapshot and extras branches are no longer maintained. Work on these has stopped so that we can focus on
upstream. Apologies for not making this clear earlier.

Thanks,

Ben

> 
> 
> Thanks for your time,
> Zeng Heng

Re: [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'

[Zeng Heng]

On 2026/4/15 20:42, Ben Horgan wrote:
> Hi Zeng,
> 
> On 4/15/26 02:27, Zeng Heng wrote:
>> Hi Ben,
>>
>> On 2026/4/13 23:02, Ben Horgan wrote:
>>> 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
>>>
>>
>> Following the current SMMU approach, I've submitted several bugfix
>> patches for the MPAM driver, but haven't received any review feedback
>> yet.
>>
>> To avoid these being overlooked, I'd like to kindly remind to take a
>> look:
>> v2: https://lore.kernel.org/all/20260414032610.1523958-1-zengheng4@huawei.com/
>> v1: https://lore.kernel.org/all/20251107063300.1580046-1-zengheng4@huawei.com/
>>
>> Additionally, I'd like to check on the status of this branch — is it
>> still actively maintained? It would be helpful to understand the future
>> plans for MPAM development.
> 
> The MPAM snapshot and extras branches are no longer maintained. Work on these has stopped so that we can focus on
> upstream. Apologies for not making this clear earlier.
> 


Ack. If the extras branch scheme mentioned above is rebased onto
upstream, these bugfix patches would remain applicable and worth
reviewing.


Best regards,
Zeng Heng