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, 14 Mar 2022 18:46:33 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Matthew Rosato <mjrosato@linux.ibm.com>
Cc:     linux-s390@vger.kernel.org, alex.williamson@redhat.com,
        cohuck@redhat.com, schnelle@linux.ibm.com, farman@linux.ibm.com,
        pmorel@linux.ibm.com, borntraeger@linux.ibm.com, hca@linux.ibm.com,
        gor@linux.ibm.com, gerald.schaefer@linux.ibm.com,
        agordeev@linux.ibm.com, svens@linux.ibm.com, frankja@linux.ibm.com,
        david@redhat.com, imbrenda@linux.ibm.com, vneethv@linux.ibm.com,
        oberpar@linux.ibm.com, freude@linux.ibm.com, thuth@redhat.com,
        pasic@linux.ibm.com, joro@8bytes.org, will@kernel.org,
        pbonzini@redhat.com, corbet@lwn.net, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
        linux-doc@vger.kernel.org
Subject: Re: [PATCH v4 22/32] KVM: s390: pci: routines for (dis)associating
 zPCI devices with a KVM
Message-ID: <20220314214633.GJ11336@nvidia.com>
References: <20220314194451.58266-1-mjrosato@linux.ibm.com>
 <20220314194451.58266-23-mjrosato@linux.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220314194451.58266-23-mjrosato@linux.ibm.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?tV4b0M1daxj73Gn+rSemXRrRx/ShwVsd+gKfe4s+voymTHU2zX5Oeaf7RIAf?=
 =?us-ascii?Q?F5uFbM9yeXvD5NGzoWBmspsbCu6j0EGoSJyHrnjTNR1L72llHF/DIEYHk5qV?=
 =?us-ascii?Q?ZPxEvAQKCGH7m/ta3jTPBxNQxLG1XDG64X/H58foUkhdZxbYUgZ9fxJ1AZ2e?=
 =?us-ascii?Q?a7HnGeDGaE7HQek9HM9ENFuxMii2MIteyY+pmzyQIgmO1HA35fSeV7fuJYv1?=
 =?us-ascii?Q?l5iiEJFQm9XjjdhPuIy0vcmd+Rtd4MLJOT+ZOgzKShq02Hz5H5waTDKCzXAP?=
 =?us-ascii?Q?A3pL9j3N5PfHil1mVGVaVfbFMAzF/FKAiYrrzi3c0MXzSh18yzVuXu/tFDeh?=
 =?us-ascii?Q?gv/vR11h82u6LQSQCRCROLQA7nSOTgquvjTY7MBL/5/PYowWJ1XfR1rtOacY?=
 =?us-ascii?Q?57dF8WsfhE5d/BfLmI00coOJbnHg3meyiT6Z6J68Hym4aZwB20WYA1FEYEJ2?=
 =?us-ascii?Q?7hQCUXJ7VRuBQg3hbiKBat5B1nPaGH7kCePxhK7jsHTirXZjwzu201+rrLRu?=
 =?us-ascii?Q?xZkh746XYIoDGhBpZVHcIGF+WR3IZHe4BfnutxHtATiEVN+0H/4ukGyIzNZF?=
 =?us-ascii?Q?JiUNBmT6q/wTGrmW9Bi26jcknq8nbdtbRDzeHdYMUwjp11R4mzhNkjWlODsF?=
 =?us-ascii?Q?s4TrFJT0EF7eQd5ksLOVzZL0dTf9FNsAzDFVdOXDg+GI254fRyEc0QKAX3GZ?=
 =?us-ascii?Q?YDrSSJxIVN6r8swp2J0NGgNNtbzkTBNWdUac3c1P2GSi9/Jx/NekfnBhFzT1?=
 =?us-ascii?Q?6soQDYp1ptfB/dpEVM7PSgU93yuM5CvA0JNnsfLSP8qjmkEAxgbARBceYZhV?=
 =?us-ascii?Q?70q20siFUBLATZRth9H/ezuVVUElOCc3KkPpcDQa8Xf9DMczPR4G5zI/fGKq?=
 =?us-ascii?Q?U+8lRAZkGmH96Ye514/W/A5kHvuHtXaDAwllpAPsgtg63aAIcP1ml1NhGDiZ?=
 =?us-ascii?Q?3owaq8XEzqynyqGThGMAGqcMzIYaYW2kX3RpesyMAsT8RhllYw8Dugv0KVKK?=
 =?us-ascii?Q?ACPrEla9F9rWLJBljqwy/440HpRHEWn1C0KwwOv0DeMNFiYL1YF4HLZ+h9AP?=
 =?us-ascii?Q?VRe72/WHHYJWysqlY3xOuERn56kN4oEpFYVYiULgAcN3XRMPaEzkJrEsJRFF?=
 =?us-ascii?Q?NjO5pob100wwpxKYbG6rpIWzqEF9OIvZkVgi2xo4wFtM69OQwJsoCEIKInIf?=
 =?us-ascii?Q?tFrnmUVYdHRjHB4HQ3ux1/KvR9So4/ral2fBAhMjX8uxmA0yS/J444yeQENC?=
 =?us-ascii?Q?Z8T80J/5ZD5F3mCAZd5sOKX7l2UuOnIobigtbIxPdIvO0NZkb/p6du3ihm7j?=
 =?us-ascii?Q?5FdPa9y1rP+ZiMv/cdchLwV78gprbEVIEHVBaq78ZvxzDxU0vgz3RQThjY27?=
 =?us-ascii?Q?SH9qSAkFhWmpaWTYwKUaeRpPUXJGA2jGaNvM8qQnaKeoVzznosU9VsEOyNhc?=
 =?us-ascii?Q?JCMZZSbIpfGm0Jx6Zm/7zdNeFADBkVA5?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a9f0b58d-54ca-4bea-e322-08da06041bbc
X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4192.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2022 21:46:34.2919
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 7uI8yZkSLCkBHK3rZM+YKxAD5TYfO82PfCN9u4aW5xk9vxmf7LUeQjmEiquRETfd
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB3844
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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

On Mon, Mar 14, 2022 at 03:44:41PM -0400, Matthew Rosato wrote:
> +int kvm_s390_pci_zpci_start(struct kvm *kvm, struct zpci_dev *zdev)
> +{
> +	struct vfio_device *vdev;
> +	struct pci_dev *pdev;
> +	int rc;
> +
> +	rc = kvm_s390_pci_dev_open(zdev);
> +	if (rc)
> +		return rc;
> +
> +	pdev = pci_get_slot(zdev->zbus->bus, zdev->devfn);
> +	if (!pdev) {
> +		rc = -ENODEV;
> +		goto exit_err;
> +	}
> +
> +	vdev = get_vdev(&pdev->dev);
> +	if (!vdev) {
> +		pci_dev_put(pdev);
> +		rc = -ENODEV;
> +		goto exit_err;
> +	}
> +
> +	zdev->kzdev->nb.notifier_call = kvm_s390_pci_group_notifier;
> +
> +	/*
> +	 * At this point, a KVM should already be associated with this device,
> +	 * so registering the notifier now should immediately trigger the
> +	 * event.  We also want to know if the KVM association is later removed
> +	 * to ensure proper cleanup happens.
> +	 */
> +	rc = register_notifier(vdev->dev, &zdev->kzdev->nb);
> +
> +	put_vdev(vdev);
> +	pci_dev_put(pdev);
> +
> +	/* Make sure the registered KVM matches the KVM issuing the ioctl */
> +	if (rc || zdev->kzdev->kvm != kvm) {
> +		rc = -ENODEV;
> +		goto exit_err;
> +	}
> +
> +	/* Must support KVM-managed IOMMU to proceed */
> +	if (IS_ENABLED(CONFIG_S390_KVM_IOMMU))
> +		rc = zpci_iommu_attach_kvm(zdev, kvm);
> +	else
> +		rc = -EINVAL;

This seems like kind of a strange API, shouldn't kvm be getting a
reference on the underlying iommu_domain and then calling into it to
get the mapping table instead of pushing KVM specific logic into the
iommu driver?

I would be nice if all the special kvm stuff could more isolated in
kvm code.

I'm still a little unclear about why this is so complicated - can't
you get the iommu_domain from the group FD directly in KVM code as
power does?

Jason