Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp6013392pxv; Wed, 7 Jul 2021 17:36:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy74WwQ14Nx+KXWKhxoiYhFDAX/f4ivuKw0sJHqpvl7fh4Jty5PaUMQRUyOpolT6CchUpVf X-Received: by 2002:a6b:7905:: with SMTP id i5mr22270043iop.175.1625704568855; Wed, 07 Jul 2021 17:36:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625704568; cv=none; d=google.com; s=arc-20160816; b=jl9B157/RdVKO3rzyCWEHfkx3yXaBp99gdZlBhcLJ/6SpqKGQvzzoU1ZJWbcoG6Sk/ /SV3k3fA559smkGT0UL/UhpdSPr8TwchDcWMSf9sNYdaAiD6L/je5Z1b4Rf66IUO7C9z apo7TLCkThTd646J/3O0cH55FCTvJUmhdRjW05qI7aZ+A+UsXv3O+8I1e6QkkENl/W5m 24HaC7/ouKc8YnznFT7VP3S9h9n2J0qirRyEWXhyYeHRueawGVuBhVpV4YSMhNDr3RiO wwDuJpn6lJGfnEs1hl30tPEuCLfCbRl4Udd9LGwnxsK0tvb3/atudXgNFwo8MUFqJSf0 sagg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=TL3ZlYoFFadh6mnpw9+RF0+6LRR48vbpiIyTkZdY8r4=; b=U6MTkfUpY0Y8l+7WSw7BUZPfis3LYfaDfBab6lFxoeEBGMv2K5WhRXaLfv7WzKjU52 ysL1dvGTx+k2mH1g5s2NiOGfAs06BLesSR54sEktzBwYav12SEobvThmGnBeHs5LlV53 L/BThsZaiP6BKpFrSHEry5Eze2LbC9bam8sukjGFvjxgH92zk+q84o/YzibEZfhNzX5W +YwYORsGoQQd75vjQwo5NrS4pALTOpLh0pbIo7ynOQnEN7rOwmwN8p2oxeE0Gli6FZNV J5j95VhV93memjWQn8h5TF7xC/kjJQDXDtGHFYVYF6D9nc6Lug0fkYn7nTJTGevgYUfI /YMA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k11si639020ilo.114.2021.07.07.17.35.56; Wed, 07 Jul 2021 17:36:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230093AbhGHAg4 (ORCPT + 99 others); Wed, 7 Jul 2021 20:36:56 -0400 Received: from mga02.intel.com ([134.134.136.20]:40961 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230000AbhGHAgz (ORCPT ); Wed, 7 Jul 2021 20:36:55 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10038"; a="196587808" X-IronPort-AV: E=Sophos;i="5.84,222,1620716400"; d="scan'208";a="196587808" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2021 17:34:02 -0700 X-IronPort-AV: E=Sophos;i="5.84,222,1620716400"; d="scan'208";a="498174309" Received: from otc-nc-03.jf.intel.com (HELO otc-nc-03) ([10.54.39.36]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2021 17:34:01 -0700 Date: Wed, 7 Jul 2021 17:33:35 -0700 From: "Raj, Ashok" To: Jason Gunthorpe Cc: Thomas Gleixner , "Dey, Megha" , linux-kernel@vger.kernel.org, "Jiang, Dave" , "Tian, Kevin" , "Pan, Jacob jun" , "Liu, Yi L" , "Kumar, Sanjay K" , "Van De Ven, Arjan" , "Williams, Dan J" , "Shankar, Ravi V" , Ashok Raj Subject: Re: Programming PASID in IMS entries Message-ID: <20210708003335.GC56594@otc-nc-03> References: <87k0m2qzgz.ffs@nanos.tec.linutronix.de> <20210707221216.GA56594@otc-nc-03> <20210707235822.GB4459@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210707235822.GB4459@nvidia.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 07, 2021 at 08:58:22PM -0300, Jason Gunthorpe wrote: > On Wed, Jul 07, 2021 at 03:12:16PM -0700, Raj, Ashok wrote: > > Hi Thomas > > > > On Wed, Jul 07, 2021 at 10:50:52AM +0200, Thomas Gleixner wrote: > > > Megha, > > > > > > On Wed, Jul 07 2021 at 09:49, Megha Dey wrote: > > > > Per your suggestions during the last meeting, we wanted to confirm the > > > > sequence to program the PASID into the IMS entries: > > > > > > > > 1. Add a PASID member to struct msi_desc (Add as part of a union. Other > > > > source-id's such as Jason's vm-id can be added to it) > > > > > > Yes. Though we also discussed storing the default PASID in struct device > > > to begin with which is then copied to the msi_desc entries during > > > allocation. > > > > Using default PASID in struct device will work for sub-devices until the > > guest needs to enable ENQCMD support. Since the guest kernel can ask for an > > interrupt by specifying something in the descriptor submitted via ENQCMD. > > Using the PASID in struct device won't be sufficient. > > Could you could store a pasid table in the struct device and index it > by vector? Possibly... what ever Thomas things is clean. The device specific driver would have this already. So providing some call to get this filled in vs storing that in struct device. Someone close at heart to the driver model is best to comment :-) IMS core owns the format of the entries right now vs device specific driver. I suppose your use case requiring a vm_id might have a different format. So this is yet another one the core needs to learn and adapt? It seems we have conceptually 3 types of IMS already brewing up. 1. IDXD has legacy MSIx + MSix permission table to hold PASID. 2. IMS in IDXD has PASID in the IMS entry itself. 3. Jason's vm_id instead of the PASID use case. So we can keep IMS core about these types, another way is to allow device specific implementations provide the write handlers with the index, and let the driver handle the location of the write. IMS core will provide the format and data. Cheers, Ashok