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;
Date:   Mon, 15 Aug 2022 15:42:57 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        "Li, Ming" <ming4.li@intel.com>
CC:     <ira.weiny@intel.com>, Dan Williams <dan.j.williams@intel.com>,
        "Bjorn Helgaas" <bhelgaas@google.com>,
        Bjorn Helgaas <helgaas@kernel.org>,
        "Matthew Wilcox" <willy@infradead.org>,
        Lukas Wunner <lukas@wunner.de>,
        "Alison Schofield" <alison.schofield@intel.com>,
        Vishal Verma <vishal.l.verma@intel.com>,
        Dave Jiang <dave.jiang@intel.com>,
        Ben Widawsky <bwidawsk@kernel.org>,
        <linux-kernel@vger.kernel.org>, <linux-cxl@vger.kernel.org>,
        <linux-pci@vger.kernel.org>
Subject: Re: [PATCH V16 3/6] PCI/DOE: Add DOE mailbox support functions
Message-ID: <62facbf166698_dfbc1294ad@dwillia2-xfh.jf.intel.com.notmuch>
References: <20220719205249.566684-1-ira.weiny@intel.com>
 <20220719205249.566684-4-ira.weiny@intel.com>
 <a3f72cdd-884d-efa1-89e8-f9d6660bf760@intel.com>
 <20220815105038.00000336@huawei.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20220815105038.00000336@huawei.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?w1QXbvrh9pkDZqC8D6tg34mBxlxJgfqBcrvaOn7V+xQloA/Sk3iXjwlM91J8?=
 =?us-ascii?Q?i+8XilYXbc4JkwFfGafXcFMT8uRtKO9uDzJc4+BNrQSeaM5jikYFqR6bSXPO?=
 =?us-ascii?Q?j+8SfcWNJF6LY9cp05wGuYw7THO1WSE3ZmrCFHc2CfveUimhKJniuCmwAQRc?=
 =?us-ascii?Q?teyoZlaPRPij6R2Jx4pVTAhclCyq7Fg3UOyiX+f2ML+A6GzokwV/WLRZEdjW?=
 =?us-ascii?Q?fnwrEKnhyY55fhL9nu6xH0JfVPN2Nop3cO2TGRd2dWaA/w2sicY0XWtPU2RV?=
 =?us-ascii?Q?GLFJ4bN2YkajLJA2IHH2JkONYnA+759kon5lk378/HA0kR1CZT8QpYx3texZ?=
 =?us-ascii?Q?rJrTNiHmKdObQ00WSOf0QM9xVeXNhZ1Q/axNC9/KjsWQdlbM1kCbdQj1kS9J?=
 =?us-ascii?Q?dIbcl0IVK7nSKVPFukbLonQJpe6dYXtP7ZkpcHJmHywZ65Kctd73gSOxsyJx?=
 =?us-ascii?Q?dG+n36ro5VdlUDpwBmhiTVGJWOM/y6hbimUYpMN9vrX3ga0gNmIufJRJNgQQ?=
 =?us-ascii?Q?HLQGuDfrNdxYg36Vyo66Nm6P7+8O8FQZRK9TOfbAZ0UTqQOPsSBzQxcawKIs?=
 =?us-ascii?Q?fDTNDkj4zci36wUh97b8GbJgL3/aaVBkx7YPRj8+Qq8FIsB7k3jo2PO8Npng?=
 =?us-ascii?Q?80vfEKeoLNJ78Wx+oKZljJ7b2MlYluT98qt6jvmpKDMSgjFsZp0MNHqzllux?=
 =?us-ascii?Q?m6CPeIJvl+ioIbQl/sJjXSG72lG5oYFo47fQk6Xg6C6SHem+/jqdrLNOhRKS?=
 =?us-ascii?Q?4sF184fsaQ29MZCMb6XqhgFvV0wtB1vUC0YPT4tE6IC3s+OjriJt7Q8Nf+ra?=
 =?us-ascii?Q?69D5kA3pZJjiYLS46y1+U18vkJTjI8sFJabDKgdslfmUiKTQZBjW1qHoSzxr?=
 =?us-ascii?Q?RySHWmAITJhuomA5aeeiMQdiVeotJU/sIHdWS8cu0SRZLmgtNgFUvvoDFvhp?=
 =?us-ascii?Q?GhWWOdPMcbYoH3jlO2ViZW3ytFxh3dBbbXiiqvfOP4cDoWBNLxFq11Os/EVZ?=
 =?us-ascii?Q?DM+4tClbHzRNinhOOuQWmd1l5ws4JRpzN3I1P1R974PxYGtghIqskISNM56V?=
 =?us-ascii?Q?Aq4eZdDNfG2MC5zFzX8JMw0136b8dcBRoQMvEG0D6cvG5L29g07EfIua5FFw?=
 =?us-ascii?Q?v3xGmLbVkY7i3UcHAdtU0Z2FURdRgaAkOUyFGoPEvKwZTHIJA5xIqXW+QIHd?=
 =?us-ascii?Q?T61tbYiuZ9NX2Z/Y1JbibyM+LnTj87x7AEK1pvahUlbnfkZf+Mz9EXoyY0v3?=
 =?us-ascii?Q?RH0/ndcS9zjpzIR35k23C7pzuY2pB27vsWX8X0GIOOP2urkug9bLPSsbtFZi?=
 =?us-ascii?Q?JPHNtlBLStpCdlUUy3QdoxTn0EaIUCVYOB5ns9rbNfSzPZ+qwRXZ6WNrkXv6?=
 =?us-ascii?Q?D1MwuF9UQOg45BGu1lYZe3Ej+12L8eUBXr5+m49lF7Kw02/xwqTU/g1xG2cJ?=
 =?us-ascii?Q?eGu+XUjmWbci+903W0RSz5vkmNHHrdpor+IiPrnj8hR2EYVDGfu3THtnHmkr?=
 =?us-ascii?Q?q4ATGONkGMQ5Vevzma5FwsR/2kKtxj++jIc/VnpBZ4whJ+DYa5CsdJ4KZvWq?=
 =?us-ascii?Q?Lhm+GVIW3iYr4Vmal0xiZ7z23wyyUKeNFIgI4IH+etviV/2HEMihvtS7LL7k?=
 =?us-ascii?Q?VQ=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 960048cc-0002-4df9-4927-08da7f0f81d0
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1101MB2126.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Aug 2022 22:43:00.7213
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: K1j1OaKRP4gTzd2XxRD+30VVczT5wbjgaQcsGjrvh52F+UZGysynvCcuX5Jcu3sdAuHCYSh2/LoNLSqa+emuhvArz80q+k2IBN4wb8uS048=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6213
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham
        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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Jonathan Cameron wrote:
> On Mon, 15 Aug 2022 10:17:00 +0800
> "Li, Ming" <ming4.li@intel.com> wrote:
> 
> > On 7/20/2022 4:52 AM, ira.weiny@intel.com wrote:
> > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > 
> > > Introduced in a PCIe r6.0, sec 6.30, DOE provides a config space based
> > > mailbox with standard protocol discovery.  Each mailbox is accessed
> > > through a DOE Extended Capability.
> > > 
> > > Each DOE mailbox must support the DOE discovery protocol in addition to
> > > any number of additional protocols.
> > > 
> > > Define core PCIe functionality to manage a single PCIe DOE mailbox at a
> > > defined config space offset.  Functionality includes iterating,
> > > creating, query of supported protocol, and task submission.  Destruction
> > > of the mailboxes is device managed.
> > > 
> > > Cc: "Li, Ming" <ming4.li@intel.com>
> > > Cc: Bjorn Helgaas <helgaas@kernel.org>
> > > Cc: Matthew Wilcox <willy@infradead.org>
> > > Acked-by: Bjorn Helgaas <helgaas@kernel.org>
> > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > Co-developed-by: Ira Weiny <ira.weiny@intel.com>
> > > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> > > 
> > > ---  
> > 
> > > +/**
> > > + * pci_doe_submit_task() - Submit a task to be processed by the state machine
> > > + *
> > > + * @doe_mb: DOE mailbox capability to submit to
> > > + * @task: task to be queued
> > > + *
> > > + * Submit a DOE task (request/response) to the DOE mailbox to be processed.
> > > + * Returns upon queueing the task object.  If the queue is full this function
> > > + * will sleep until there is room in the queue.
> > > + *
> > > + * task->complete will be called when the state machine is done processing this
> > > + * task.
> > > + *
> > > + * Excess data will be discarded.
> > > + *
> > > + * RETURNS: 0 when task has been successfully queued, -ERRNO on error
> > > + */
> > > +int pci_doe_submit_task(struct pci_doe_mb *doe_mb, struct pci_doe_task *task)
> > > +{
> > > +	if (!pci_doe_supports_prot(doe_mb, task->prot.vid, task->prot.type))
> > > +		return -EINVAL;
> > > +
> > > +	/*
> > > +	 * DOE requests must be a whole number of DW and the response needs to
> > > +	 * be big enough for at least 1 DW
> > > +	 */
> > > +	if (task->request_pl_sz % sizeof(u32) ||
> > > +	    task->response_pl_sz < sizeof(u32))
> > > +		return -EINVAL;
> > > +
> > > +	if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags))
> > > +		return -EIO;
> > > +
> > > +	task->doe_mb = doe_mb;
> > > +	INIT_WORK(&task->work, doe_statemachine_work);
> > > +	queue_work(doe_mb->work_queue, &task->work);
> > > +	return 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(pci_doe_submit_task);  
> > 
> 
> > I'm curious why there is not a sychronous function for DOE users. I
> > think some protocols over DOE need a DOE sychrounous interface(e.g.
> > SPDM, TDISP, IDE...). These protocols have to implement an sychronous
> > function over pci_doe_submit_task() by themselves, maybe we can
> > implement an generic sychronous function in PCI/DOE for these DOE
> > users.
> 
> This came up during discussions of earlier versions of the series.
> IIRC we decided to postpone adding a synchronous wrapper function
> until there were more use cases.

Note that as far as I can see TDISP makes no requirement of the VMM nor
TVM (trusted VM) to drive an SPDM session. All of that is handled by the
TSM (TEE / Platform Security Manager) where the VMM is outside the trust
boundary. The TVM only validates the contents of a
GET_DEVICE_INTERFACE_REPORT which the TSM had negotiated with the DSM
(Device Security Manager).

All this to say its not clear that Linux needs to grow the capabilities
listed above when it is expected to be outside the Trusted Compute
Boundary.