Received: by 2002:a05:7412:6592:b0:d7:7d3a:4fe2 with SMTP id m18csp1152145rdg; Fri, 11 Aug 2023 11:21:18 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHKj6tlGYDueAamhPre/Y3Uvq0t0HGEgohZgCdYm8Fkk3muoDtbQ0l82R6DllDxt4lTiJKC X-Received: by 2002:a05:6a20:8422:b0:134:a478:5e4a with SMTP id c34-20020a056a20842200b00134a4785e4amr3280279pzd.17.1691778078543; Fri, 11 Aug 2023 11:21:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691778078; cv=none; d=google.com; s=arc-20160816; b=DVJwVl3Kd1C0VOmIA7qrwfWVj/flX/xdO03nK/xNzNn7IxNoMWeAqk5UJ7aNyPFqLl 7y/H/sl/cCyVMEhbsFWVn7J1bghi1DG97+sc8t2BXJXAt/DO8fgxNsLZZ3b1xor0kwZM Yi+88jgm2hJeLODQxgLhu9XQM/d85h+yDQFerdMxLtm1J/wJahh7Anw5/0IAxaM3kbJk pNUzUOWy3aiXJfRXB7R/o/ds5TEzdYb8QO4eIKGVQJxnLxJwyV+YYBA4mxob7U4QhbiW l3mUWzo49PnoYNOA2GV7Hxlz0PrA3h3vq36sKf/FCp7HM9lnbg/XW5or2aJCHav8+9EW etOg== 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:dkim-signature; bh=bcJM0SLMxv8I13dY5TRlyJefXEA95JxGEoIyQSKlH3s=; fh=FROtWkHcmTxsik+/ln5NelbIOlFcfMWoBfzDbH+Lmak=; b=vi5HpLfDWrV7K1wcq3Za1tqMaziB0eRh/YdSMgwqg88OgnSywkbQYGdzVVg8U2vX6L IB9DQ03f21zBLy6nSk/KsakPWEvUYwM/Rws9Pnab3dVfqOSgwN76twY0AAyZOo4X01Qy 3cykzt4ZBgHKsiPW0G4Ersa0/0hPBBr0qZb4TV1wjEC5KSUkyL5Pw30xzIhafC2D+AdV xX4sk4V/UKe2GXa/iVGmR/03AZX5Xd/3zWzvbjGmyztm7hYddm1pfDEmndBQDCAHgtmo lZosZ3bBwi5Yx9YvPeofDG/b90NYt5J0Wjn3MTDTedG1zJiLPnuf/1yxCv+OXlU+EKsw pdJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=KqNPrZIi; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c124-20020a633582000000b005634a72454asi3708207pga.37.2023.08.11.11.21.06; Fri, 11 Aug 2023 11:21:18 -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=@ziepe.ca header.s=google header.b=KqNPrZIi; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236636AbjHKROF (ORCPT + 99 others); Fri, 11 Aug 2023 13:14:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230160AbjHKROE (ORCPT ); Fri, 11 Aug 2023 13:14:04 -0400 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D8B52686 for ; Fri, 11 Aug 2023 10:14:04 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-68783b2e40bso1695598b3a.3 for ; Fri, 11 Aug 2023 10:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1691774043; x=1692378843; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=bcJM0SLMxv8I13dY5TRlyJefXEA95JxGEoIyQSKlH3s=; b=KqNPrZIieuMXW+UgXUuHECVuGzp6DFkx3AYbo8xgXyKIzl+6R4MqT+E2phfEgUxYDS u5SrIMTZ0xlYbMTsBexIJMQZteqMFhQzd0kIP4j6LTJ39kgodtEXIHVUEdOTzOdLiGTR xK6w/uG8iTasuLVNR2msFgo+/IZ7iuBY9p5YcWmer1bGTNSDxjxGA4KJQkimxuT92uqG Flb9reLYIfU600rv825vz9iAh0HxtDZTfkxjheEdJQo7F6LIs0+SmJbwEKgB1muTIkK3 cySVwh4wWzmS3xD5X3QT2UER5Gl5IJ6LK0LaEa2s143Agjg1Qajxg8c4L0IvaVujlT5u /Itw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691774043; x=1692378843; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bcJM0SLMxv8I13dY5TRlyJefXEA95JxGEoIyQSKlH3s=; b=g7kkFiAZqfLdpbzNv3sOIaIQrVpMrYRmXK7wWeWROI/cwN+De8zK/JhSd6ezFvaXeQ Ws/BRaTkewKtI0UXrWasDVUj9M6qnQMf+dvWyZVbtWeoGnnCNzc0dkc7e3BXrMRe1+jy 8GwdcyexcvXzzjfjFdCIPm5BtufMBnEzXJPNGDnzKq8kz05BRUvYE2BVMGP2OrXmXQnU jt463PFSlTapX3Kr/oYvqwq3zZUln/qGDBE9rpbigLcwaffjd27jBwgFxaFAwfKTmFjT bxg17aHl1/MY/pVv4+g9rDgrmTJ4Ki+qB8V0Kv6xuJ3eo98mEt6m7Cuk0Qg3k9SfXb4R oy7A== X-Gm-Message-State: AOJu0Yz6njTDKi2l3MKiu456FI02qRZ3oxp+LNMT6cxy28AZN0LEMlo2 3jKB+yWAeMuF4GVjjNaALed2mw== X-Received: by 2002:a05:6a20:5497:b0:135:8a04:9045 with SMTP id i23-20020a056a20549700b001358a049045mr3266427pzk.1.1691774043466; Fri, 11 Aug 2023 10:14:03 -0700 (PDT) Received: from ziepe.ca ([206.223.160.26]) by smtp.gmail.com with ESMTPSA id r30-20020a63441e000000b0056001f43726sm3571605pga.92.2023.08.11.10.14.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Aug 2023 10:14:02 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1qUVi5-005Sth-As; Fri, 11 Aug 2023 14:14:01 -0300 Date: Fri, 11 Aug 2023 14:14:01 -0300 From: Jason Gunthorpe To: Baolu Lu Cc: Joerg Roedel , Will Deacon , Robin Murphy , Kevin Tian , Jean-Philippe Brucker , Nicolin Chen , Yi Liu , Jacob Pan , iommu@lists.linux.dev, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 12/12] iommu: Add helper to set iopf handler for domain Message-ID: References: <20230727054837.147050-1-baolu.lu@linux.intel.com> <20230727054837.147050-13-baolu.lu@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 11, 2023 at 10:40:15AM +0800, Baolu Lu wrote: > On 2023/8/11 3:18, Jason Gunthorpe wrote: > > On Thu, Jul 27, 2023 at 01:48:37PM +0800, Lu Baolu wrote: > > > To avoid open code everywhere. > > > > > > Signed-off-by: Lu Baolu > > > --- > > > include/linux/iommu.h | 11 ++++++++++- > > > drivers/iommu/iommu.c | 20 ++++++++++++++++++-- > > > 2 files changed, 28 insertions(+), 3 deletions(-) > > > > Seems like overkill at this point.. > > > > Also, I think this is probably upside down. > > > > We want to create the domains as fault enabled in the first place. > > > > A fault enabled domain should never be attached to something that > > cannot support faults. It should also not support changing the fault > > handler while it exists. > > > > Thus at the creation point would be the time to supply the fault handler > > as part of requesting faulting. > > > > Taking an existing domain and making it faulting enabled is going to > > be really messy in all the corner cases. > > Yes. Agreed. > > > > > My advice (and Robin will probably hate me), is to define a new op: > > > > struct domain_alloc_paging_args { > > struct fault_handler *fault_handler; > > void *fault_data > > }; > > > > struct iommu_domain *domain_alloc_paging2(struct device *dev, struct > > domain_alloc_paging_args *args) > > > > The point would be to leave the majority of drivers using the > > simplified, core assisted, domain_alloc_paging() interface and they > > just don't have to touch any of this stuff at all. > > > > Obviously if handler is given then the domain will be initialized as > > faulting. > > Perhaps we also need an internal helper for iommu drivers to check the > iopf capability of the domain. Yeah, maybe. I've been mulling over this for a a bit here Robin suggested to wrap everything in a arg to domain_alloc and build a giant super multiplexor I don't really like that because it makes it quite complicated for the driver and multiplexor APIs are rarely good. So for simple drivers I like the 'domain_alloc_paging' as the only op they implement and it is obviously simple and hard to implement wrong. Most drivers would do this. We also need a: struct iommu_domain *domain_alloc_sva(struct device *dev, struct mm_struct *mm) So SVA can be fully setup at allocation time. SVA doesn't have any legal permutations so it can be kept simple. Then we need something to bundle: - Dirty tracking yes/no - The iommufd user space blob - Fault handling yes/no For complex drivers. So maybe we should just have a 3rd option // I'm a complex driver and many people checked that I implemented // this right: struct domain_alloc_args { struct device *dev; unsigned int flags; // For requesting dirty tracking // alloc_domain_user interface struct iommu_domain *parent; void *user_data; size_t user_len; // Faulting struct fault_handler *fault_handler; void *fault_data; }; struct iommu_domain *domain_alloc(struct domain_alloc_args *args); ? IDK, multiplexor APIs are rarely good, but maybe this is the right direction? Jason