Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp1731789rwl; Fri, 31 Mar 2023 16:08:54 -0700 (PDT) X-Google-Smtp-Source: AKy350ZOPO92t4y/1S3NszV/fPG6wAVVZtOUJSUW5FjyZQxXd/YpYLjr/vlTW0X6n5w7Zlz0Foer X-Received: by 2002:a05:6a20:72a3:b0:e4:173c:cdec with SMTP id o35-20020a056a2072a300b000e4173ccdecmr7177421pzk.0.1680304134271; Fri, 31 Mar 2023 16:08:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680304134; cv=none; d=google.com; s=arc-20160816; b=n7boWmLLpp+PRDePQmzz28r4A0rwT78ZeXNg/eJNSxxj85EUE8Nd3XKD4eq6q/ehRJ 1wUJX+7BaUl1wXZoh7qma70f1hxmvkabEXFt12v57P54W0SKoT+yVSFjY4iRulojcGf0 LYLNh20tsKsHhm1K3WMXPUVM+pV3EKRhi5w5NoMmsylbheyuQmAaoq/aUkaRa1mqPzwc DR1TTEvJDGR0wY0AlTrEaIOUxjrpY6DaeAh8yrLbtS818eoUH4Ua/x28LKljBRwjuMp3 m0YqRcfD1BAq4w4fl6e7DJnzwzJz0gBmU8Yw54k2YGGWf8VMcCpQqpbH7SA9Ex1egqG1 aFfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=1czAWR/MptgZ7qvTv5/NVMtzZUkI7E+PLl+vGwGmpks=; b=HPEzRRe8+CLZ9Gy+qoCRktAi0ROnL5oe3t1jLihGOL6pYJALfhaAAmMJeNeR0XWOiD s+uh+36II3KH+J0SsOGERQj1LvF2zMEKPj37jr8hTMaZPE8J75AGFWdxbqFtzIsK+qeI xMNaY96a4wHo4m9kc0dx+uZGfX4fTlDyR6jQQWbry845Ipi1SHem9At4LDfZ+AlE+62O RM3woxKZAnkwYTpbaaswikXq8ndLqxwGvwksE6p3iodipNSC6IdugB8m+Amk4RE4ekoH P6GVLmjkhB3HXJYBgpKdaBvhJ4qZPpZAVg9kKQaqD/vqCdgYbYOgLIT2LjKAvLQEhHUj X4Hg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Og74AqYf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y7-20020a63e247000000b004e00a870567si3657753pgj.124.2023.03.31.16.08.42; Fri, 31 Mar 2023 16:08:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Og74AqYf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232670AbjCaXHf (ORCPT + 99 others); Fri, 31 Mar 2023 19:07:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229988AbjCaXHd (ORCPT ); Fri, 31 Mar 2023 19:07:33 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29EDB5BB4; Fri, 31 Mar 2023 16:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680304053; x=1711840053; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=DnaRmj+QiMWJCcTf2AJsdp5uoJ6bEGi3YKrWISZOyzI=; b=Og74AqYffJVqGW4ToNfwET3v1Jbz7TizZ8CW4sf1JtE1rX5eFKNCuwkN QTg85dGgfFuFviAyYXBp3NdZLIy1Fpv5m2CTD8LuI9vwmv8cjwOXQyxnV ct9A/N7HRkd5ObmvIyt3dABHwb0IdkzUhW5bf1LFOnDmn3EJZH5zZ+ej/ e49bW5OwLrZRoCumv1kCWPtZJvnqTMyUi7pSqwZQSOQVJYnqiW2ayP2yt YQhE6PeIKOTL7tUxu1RofbZ1VNVtZK8ricKPSt4b15rooSV5yMAfI7yFA C0VSdq7bDztoTMLtf0dHPT1nRVBdjI4SNywEr7KanMXyaN2L+kYggCmDM A==; X-IronPort-AV: E=McAfee;i="6600,9927,10666"; a="343245119" X-IronPort-AV: E=Sophos;i="5.98,307,1673942400"; d="scan'208";a="343245119" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Mar 2023 16:07:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10666"; a="717888334" X-IronPort-AV: E=Sophos;i="5.98,307,1673942400"; d="scan'208";a="717888334" Received: from srinivas-otcpl-7600.jf.intel.com (HELO jacob-builder.jf.intel.com) ([10.54.39.106]) by orsmga001.jf.intel.com with ESMTP; 31 Mar 2023 16:07:32 -0700 From: Jacob Pan To: LKML , iommu@lists.linux.dev, "Robin Murphy" , Jason Gunthorpe , "Lu Baolu" , Joerg Roedel , dmaengine@vger.kernel.org, vkoul@kernel.org Cc: "Will Deacon" , David Woodhouse , Raj Ashok , "Tian, Kevin" , Yi Liu , "Yu, Fenghua" , Dave Jiang , Tony Luck , "Zanussi, Tom" , Jacob Pan Subject: [PATCH v3 0/7] Re-enable IDXD kernel workqueue under DMA API Date: Fri, 31 Mar 2023 16:11:30 -0700 Message-Id: <20230331231137.1947675-1-jacob.jun.pan@linux.intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=AC_FROM_MANY_DOTS, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, IDXD kernel work queues were disabled due to the flawed use of kernel VA and SVA API. Link: https://lore.kernel.org/linux-iommu/20210511194726.GP1002214@nvidia.com/ The solution is to enable it under DMA API where IDXD shared workqueue users can use ENQCMDS to submit work on buffers mapped by DMA API. This patchset adds support for attaching PASID to the device's default domain and the ability to reserve global PASIDs from SVA APIs. We can then re-enable the kernel work queues and use them under DMA API. This depends on the IOASID removal series. https://lore.kernel.org/all/ZCaUBJvUMsJyD7EW@8bytes.org/ Thanks, Jacob --- Changelog: v3: - moved global PASID allocation API from SVA to IOMMU (Kevin) - remove #ifdef around global PASID reservation during boot (Baolu) - remove restriction on PASID 0 allocation (Baolu) - fix a bug in sysfs domain change when attaching devices - clear idxd user interrupt enable bit after disabling device( Fenghua) v2: - refactored device PASID attach domain ops based on Baolu's early patch - addressed TLB flush gap - explicitly reserve RID_PASID from SVA PASID number space - get dma domain directly, avoid checking domain types Jacob Pan (7): iommu/vt-d: Use non-privileged mode for all PASIDs iommu/vt-d: Remove PASID supervisor request support iommu/sva: Support allocation of global PASIDs outside SVA iommu/vt-d: Reserve RID_PASID from global PASID space iommu/vt-d: Make device pasid attachment explicit iommu/vt-d: Implement set_dev_pasid domain op dmaengine/idxd: Re-enable kernel workqueue under DMA API drivers/dma/idxd/device.c | 30 +----- drivers/dma/idxd/init.c | 56 ++++++++++- drivers/dma/idxd/sysfs.c | 7 -- drivers/iommu/intel/iommu.c | 180 +++++++++++++++++++++++++++++------- drivers/iommu/intel/iommu.h | 8 ++ drivers/iommu/intel/pasid.c | 43 --------- drivers/iommu/intel/pasid.h | 7 -- drivers/iommu/iommu-sva.c | 10 +- drivers/iommu/iommu.c | 33 +++++++ include/linux/iommu.h | 10 ++ 10 files changed, 257 insertions(+), 127 deletions(-) -- 2.25.1