From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout07.his.huawei.com (canpmsgout07.his.huawei.com [113.46.200.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C7005265606 for ; Thu, 16 Apr 2026 03:02:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.222 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776308579; cv=none; b=svJSwY32OnHn5uy5Ul6qPBZiUgp5889xzm+oU+43uiyjLiQB9gvsgakGyq37HbOfuUb+cROGiDRsHGkuIdu2yHkqMftQ2/avVXe2qhWJEtTK5NKOpzXEtnL/io2nxwMLkKxaQ9GKSA13RWpUmQFQ09RXg+2dzy8tNJROVvozGlE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776308579; c=relaxed/simple; bh=hM68MqX6IivN7XWXqIxANL92dLtZepn/X92D8ddlQ5M=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=LcZR1CIyWMRt5QqwlEk7VlxjJ9Ygm6q4i64/Z2wn+ElhcgcLYYEetnt7dowZaxVqXA/kHAmsbo2Hur/SOkSIoNphv6K4Bi97L+RJ0SgHYXiN7kVmwg7ByMWAWwMwkGVAayaDrqJfI0phXXUjC9+IAOXEKFnzN+LfFjEXPFm9Kqc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=h-partners.com; dkim=pass (1024-bit key) header.d=h-partners.com header.i=@h-partners.com header.b=Ij1RBAcw; arc=none smtp.client-ip=113.46.200.222 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=h-partners.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=h-partners.com header.i=@h-partners.com header.b="Ij1RBAcw" dkim-signature: v=1; a=rsa-sha256; d=h-partners.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=4mb3ZAQhsea54q8p8RFMNsDARhntx+n9OVpSYKpoRno=; b=Ij1RBAcwL2Gv87YRSgvNTfb95nZhHfEHy5x+0gjxcvWZy+N6pDk/Jh/15fY5EMv/+0AoEvo7h 0enegr0sJfnc5mHao97xkU5ygqkdOWKIfMHsJ8ynvHhxnUxNqshRKbmD4scQudHe/4EWPxImcTo +vsA2leP5sr+RYNRF6k1/h8= Received: from mail.maildlp.com (unknown [172.19.163.15]) by canpmsgout07.his.huawei.com (SkyGuard) with ESMTPS id 4fx2hs6kXPzLlYX; Thu, 16 Apr 2026 10:56:29 +0800 (CST) Received: from kwepemf100008.china.huawei.com (unknown [7.202.181.222]) by mail.maildlp.com (Postfix) with ESMTPS id EC54F40571; Thu, 16 Apr 2026 11:02:47 +0800 (CST) Received: from [10.174.179.37] (10.174.179.37) by kwepemf100008.china.huawei.com (7.202.181.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Thu, 16 Apr 2026 11:02:46 +0800 Message-ID: <7e69034d-ff8e-f0ed-1c79-59f4449d74ab@huawei.com> Date: Thu, 16 Apr 2026 11:02:45 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task' Content-Language: en-US To: Ben Horgan , James Morse CC: Qinxin Xia , , , , , , , , , , , , , , , , , , , , , , , Linuxarm References: <08aacacc-e3e5-4e97-858b-cbcbdb9a1fcf@arm.com> <7b2681c3-9ef7-4882-ba57-2503934e2759@huawei.com> <0d578c61-1341-4149-9e8c-936ea0ce0c50@arm.com> From: Zeng Heng In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemf100008.china.huawei.com (7.202.181.222) 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 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