Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1957146pxb; Mon, 8 Mar 2021 10:15:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJxOhgUrXQsrXn0Sfp3l6igxx/h997jwS80B/shwITkhR2v4zimF4lCBPWIQ7kAZQfCZdoWM X-Received: by 2002:a17:907:f97:: with SMTP id kb23mr16105761ejc.33.1615227337063; Mon, 08 Mar 2021 10:15:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615227337; cv=none; d=google.com; s=arc-20160816; b=Ckc1GhkKys1dJWjGz6wIh02TC+Jgt8/k0BRSuQyqqaFG8SO77eoEzpsMqi06Afer4S XuLBxHbpbAOjxF7wwYsBYVOtHe1QG0LOOswhfHB1GhB1k8cdUpidwlKhCfpzJQ3miExC 30n4CpdZN2IMSkTeWeOXQj+Ei9i6G1btzDIg6MXa3L1E/Gxf0JisDEoNsIBkSM1yA92t f7vCf8zxS9DnP/PvWWsuVCVD7/mAlowjokO9VNnnmB3aLZPzaeLfi50/uu1JiLaEfcOD 7srdO+TItE82gOmwWNoNs2SjGwKRpnhzTVRLJim5Dy6qDqkZInrvgSZ/8sT0H/ldPa1/ NN3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=g3PfKhdiqdgUwSWYSwDNbfusFaETS5oAF78BcOmOgew=; b=LaCYKg1Po54M44K1tMzrX58s1fYesZFc4CMrM3f060oJDzaioxhG4738ALmpgnFRJP PRqIh0jl5yt2g3Kk5M7mBZpEwdP2W7PKr0xgLflgcHWKDgLxWjEEvh28RiwkC3TLwteL fZuFJnr073ieck1HGxMaHPwtUCfO4AYaSBit5plxESWnPMNMx7jl8YVUnF5iw8muOEbJ P1TGZijgeYbPpq0wCXe6ZBW41YQsKa7hmZA1PLEtkvfu3Tqew88GFO9IWvQUmgaVFY7P Y2b2in/i9pMCwJpaFx0+ZzFdCcGEofuJVkXAQvlOAD9GBZGp1PnKPyGgIpDoGsZhZZ64 XxeQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=KojPM+aC; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d3si7637426eds.83.2021.03.08.10.15.07; Mon, 08 Mar 2021 10:15:37 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=KojPM+aC; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229469AbhCHSNS (ORCPT + 99 others); Mon, 8 Mar 2021 13:13:18 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:32433 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230299AbhCHSMp (ORCPT ); Mon, 8 Mar 2021 13:12:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615227164; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g3PfKhdiqdgUwSWYSwDNbfusFaETS5oAF78BcOmOgew=; b=KojPM+aCjtw7dZvKWAuFFjs6OQ+SE59GTh2hxHMYuVClQNO6oqblWOga7PCeU6LdlMWpM7 uBvzMxmmW0h4lUGVhr/DNChmtpgw9fxjy5Ui19gZkatH2nr1e2HqimRq+43k1O/jlDWMpm meieghCrrWB4REOn6/z9Yh6qNYhzNEY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-509-LHQEfOXhMzaPdazJnqfR1g-1; Mon, 08 Mar 2021 13:12:40 -0500 X-MC-Unique: LHQEfOXhMzaPdazJnqfR1g-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E1E3980432E; Mon, 8 Mar 2021 18:12:35 +0000 (UTC) Received: from [10.36.112.254] (ovpn-112-254.ams2.redhat.com [10.36.112.254]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 29A7D5D756; Mon, 8 Mar 2021 18:12:22 +0000 (UTC) Subject: Re: [PATCH v12 03/13] vfio: VFIO_IOMMU_SET_MSI_BINDING To: Jean-Philippe Brucker Cc: eric.auger.pro@gmail.com, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, will@kernel.org, maz@kernel.org, robin.murphy@arm.com, joro@8bytes.org, alex.williamson@redhat.com, tn@semihalf.com, zhukeqian1@huawei.com, jacob.jun.pan@linux.intel.com, yi.l.liu@intel.com, wangxingang5@huawei.com, jiangkunkun@huawei.com, zhangfei.gao@linaro.org, zhangfei.gao@gmail.com, vivek.gautam@arm.com, shameerali.kolothum.thodi@huawei.com, yuzenghui@huawei.com, nicoleotsuka@gmail.com, lushenming@huawei.com, vsethi@nvidia.com References: <20210223210625.604517-1-eric.auger@redhat.com> <20210223210625.604517-4-eric.auger@redhat.com> From: Auger Eric Message-ID: <0e23edb9-9923-edb9-ac3d-8fb52d2fe8c6@redhat.com> Date: Mon, 8 Mar 2021 19:12:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jean, On 3/5/21 11:45 AM, Jean-Philippe Brucker wrote: > Hi, > > On Tue, Feb 23, 2021 at 10:06:15PM +0100, Eric Auger wrote: >> This patch adds the VFIO_IOMMU_SET_MSI_BINDING ioctl which aim >> to (un)register the guest MSI binding to the host. This latter >> then can use those stage 1 bindings to build a nested stage >> binding targeting the physical MSIs. > > Now that RMR is in the IORT spec, could it be used for the nested MSI > problem? For virtio-iommu tables I was planning to do it like this: > > MSI is mapped at stage-2 with an arbitrary IPA->doorbell PA. We report > this IPA to userspace through iommu_groups/X/reserved_regions. No change > there. Then to the guest we report a reserved identity mapping at IPA > (using RMR, an equivalent DT binding, or probed RESV_MEM for > virtio-iommu). Is there any DT binding equivalent? The guest creates that mapping at stage-1, and that's it. > Unless I overlooked something we'd only reuse existing infrastructure and > avoid the SET_MSI_BINDING interface. Yes at first glance I think this should work. The guest SMMU driver will continue allocating IOVA for MSIs but I think that's not an issue as they won't be used. For the SMMU case this makes the guest behavior different from the baremetal one though. Typically you will never get any S1 fault. Also the S1 mapping is static and direct. I will prototype this too. Thanks Eric > > Thanks, > Jean >