From: Auger Eric <eric.auger@redhat.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
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
Subject: Re: [PATCH v12 03/13] vfio: VFIO_IOMMU_SET_MSI_BINDING
Date: Mon, 8 Mar 2021 19:12:21 +0100 [thread overview]
Message-ID: <0e23edb9-9923-edb9-ac3d-8fb52d2fe8c6@redhat.com> (raw)
In-Reply-To: <YEIL3qmcRfhUoRGt@myrica>
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
>
next prev parent reply other threads:[~2021-03-08 18:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-23 21:06 [PATCH v12 00/13] SMMUv3 Nested Stage Setup (VFIO part) Eric Auger
2021-02-23 21:06 ` [PATCH v12 01/13] vfio: VFIO_IOMMU_SET_PASID_TABLE Eric Auger
2021-02-24 0:21 ` kernel test robot
2021-02-24 1:19 ` kernel test robot
2021-02-24 3:29 ` kernel test robot
2021-04-07 9:33 ` Zenghui Yu
2021-04-11 12:12 ` Auger Eric
2021-02-23 21:06 ` [PATCH v12 02/13] vfio: VFIO_IOMMU_CACHE_INVALIDATE Eric Auger
2021-02-23 21:06 ` [PATCH v12 03/13] vfio: VFIO_IOMMU_SET_MSI_BINDING Eric Auger
2021-02-24 2:22 ` kernel test robot
2021-03-05 10:45 ` Jean-Philippe Brucker
2021-03-08 18:12 ` Auger Eric [this message]
2021-02-23 21:06 ` [PATCH v12 04/13] vfio/pci: Add VFIO_REGION_TYPE_NESTED region type Eric Auger
2021-02-23 21:06 ` [PATCH v12 05/13] vfio/pci: Register an iommu fault handler Eric Auger
2021-02-23 21:06 ` [PATCH v12 06/13] vfio/pci: Allow to mmap the fault queue Eric Auger
2021-02-23 21:06 ` [PATCH v12 07/13] vfio: Use capability chains to handle device specific irq Eric Auger
2021-02-23 21:06 ` [PATCH v12 08/13] vfio/pci: Add framework for custom interrupt indices Eric Auger
2021-02-23 21:06 ` [PATCH v12 09/13] vfio: Add new IRQ for DMA fault reporting Eric Auger
2021-02-23 21:06 ` [PATCH v12 10/13] vfio/pci: Register and allow DMA FAULT IRQ signaling Eric Auger
2021-02-23 21:06 ` [PATCH v12 11/13] vfio: Document nested stage control Eric Auger
2021-02-23 21:06 ` [PATCH v12 12/13] vfio/pci: Register a DMA fault response region Eric Auger
2021-02-23 21:06 ` [PATCH v12 13/13] vfio/pci: Inject page response upon response region fill Eric Auger
2021-03-18 0:00 ` [PATCH v12 00/13] SMMUv3 Nested Stage Setup (VFIO part) Krishna Reddy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0e23edb9-9923-edb9-ac3d-8fb52d2fe8c6@redhat.com \
--to=eric.auger@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=jean-philippe@linaro.org \
--cc=jiangkunkun@huawei.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=lushenming@huawei.com \
--cc=maz@kernel.org \
--cc=nicoleotsuka@gmail.com \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=tn@semihalf.com \
--cc=vivek.gautam@arm.com \
--cc=vsethi@nvidia.com \
--cc=wangxingang5@huawei.com \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.com \
--cc=yuzenghui@huawei.com \
--cc=zhangfei.gao@gmail.com \
--cc=zhangfei.gao@linaro.org \
--cc=zhukeqian1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).