Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3751630pxb; Mon, 1 Feb 2021 03:54:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJyTlkvKnwkkyW2gRkDMQTIyYlJeT1bq6CagosMVNOPZ2RPHwHCPlNyuVyuMwWkMlUoFeMBh X-Received: by 2002:a17:906:38c3:: with SMTP id r3mr17555350ejd.193.1612180496733; Mon, 01 Feb 2021 03:54:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612180496; cv=none; d=google.com; s=arc-20160816; b=J/c2CMH8E3np1ta8hYIFmodyJjUoe7L5OczsFWkIMuFdC3LzLS/CnfNRgA6IgnLC3y iy6sVX65zVPl3bmaFv7IYjVBMD+15his9YNms4pUu/MHEFz/hlF4FjHkOXQZaziGUbdC Z06eRvijLcdwXMtn6K4/WKrvpiyVrCubFpysGluOHSdDK+F+6aE17PpS+bZpd6eTY2zf YMF4J1LkWzG11EktiXJpE5SgrkdtXIXwFvHE/dru7dm/gWUuqSfGEcuxdr5K/z8ShWlV aKIOOkslQLdo1fKEQ6n0bpJ5xtI1tKmUBC9aY34yZR2qCkeu/CXPff+GiBhf9ABR0RYB HRbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=h3O3SpXcOavaudxTRFYA6jnavJplPgSxy7v4nLAbbtU=; b=KGCLjhZ94vk36vVMvLpFdc2120TAQLQG8Pta3O5L94ZDxZZD7QgOoYs33LaR99x+/H vobNadXUaxsSAVNsnvIwxXElabahCEnrVnw85a135PWzIYHaZFynrqAud6nfDEwaip9S 3XGqhfF1GQ0jYXgzPG4cvk/QCl/1Z8SjCQWIHC/8volUXA2QGFd9SeqDUpM3XS3YiPTp pPF8fPdRPVQPe0lsTKZeObiz5DoYn8U/B2a93jastqygHj4YSgNB5A5wBXjwIa3l7w0O ds/l414pTz+bjJ+G4sOyr2YkoAym+spcUkVpod/qZ+9k+uluRV7Zw5bJP1GOw2oeb31v cvrQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gs15si230947ejb.579.2021.02.01.03.54.32; Mon, 01 Feb 2021 03:54:56 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229842AbhBALxf (ORCPT + 99 others); Mon, 1 Feb 2021 06:53:35 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:11996 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229481AbhBALxd (ORCPT ); Mon, 1 Feb 2021 06:53:33 -0500 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4DTmWC0lfWzjHP0; Mon, 1 Feb 2021 19:51:35 +0800 (CST) Received: from [10.174.184.42] (10.174.184.42) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.498.0; Mon, 1 Feb 2021 19:52:45 +0800 Subject: Re: [PATCH v13 02/15] iommu: Introduce bind/unbind_guest_msi To: Eric Auger , , , , , , , , , , References: <20201118112151.25412-1-eric.auger@redhat.com> <20201118112151.25412-3-eric.auger@redhat.com> CC: , , , , , From: Keqian Zhu Message-ID: <6a70d93d-329f-4129-bd90-03f8589c5de4@huawei.com> Date: Mon, 1 Feb 2021 19:52:44 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20201118112151.25412-3-eric.auger@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.184.42] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eric, On 2020/11/18 19:21, Eric Auger wrote: > On ARM, MSI are translated by the SMMU. An IOVA is allocated > for each MSI doorbell. If both the host and the guest are exposed > with SMMUs, we end up with 2 different IOVAs allocated by each. > guest allocates an IOVA (gIOVA) to map onto the guest MSI > doorbell (gDB). The Host allocates another IOVA (hIOVA) to map > onto the physical doorbell (hDB). > > So we end up with 2 untied mappings: > S1 S2 > gIOVA -> gDB > hIOVA -> hDB > > Currently the PCI device is programmed by the host with hIOVA > as MSI doorbell. So this does not work. > > This patch introduces an API to pass gIOVA/gDB to the host so > that gIOVA can be reused by the host instead of re-allocating > a new IOVA. So the goal is to create the following nested mapping: Does the gDB can be reused under non-nested mode? > > S1 S2 > gIOVA -> gDB -> hDB > > and program the PCI device with gIOVA MSI doorbell. > > In case we have several devices attached to this nested domain > (devices belonging to the same group), they cannot be isolated > on guest side either. So they should also end up in the same domain > on guest side. We will enforce that all the devices attached to > the host iommu domain use the same physical doorbell and similarly > a single virtual doorbell mapping gets registered (1 single > virtual doorbell is used on guest as well). > [...] > + * > + * The associated IOVA can be reused by the host to create a nested > + * stage2 binding mapping translating into the physical doorbell used > + * by the devices attached to the domain. > + * > + * All devices within the domain must share the same physical doorbell. > + * A single MSI GIOVA/GPA mapping can be attached to an iommu_domain. > + */ > + > +int iommu_bind_guest_msi(struct iommu_domain *domain, > + dma_addr_t giova, phys_addr_t gpa, size_t size) > +{ > + if (unlikely(!domain->ops->bind_guest_msi)) > + return -ENODEV; > + > + return domain->ops->bind_guest_msi(domain, giova, gpa, size); > +} > +EXPORT_SYMBOL_GPL(iommu_bind_guest_msi); > + > +void iommu_unbind_guest_msi(struct iommu_domain *domain, > + dma_addr_t iova) nit: s/iova/giova > +{ > + if (unlikely(!domain->ops->unbind_guest_msi)) > + return; > + > + domain->ops->unbind_guest_msi(domain, iova); > +} > +EXPORT_SYMBOL_GPL(iommu_unbind_guest_msi); > + [...] Thanks, Keqian