From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Eric Auger <eric.auger@redhat.com>
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: Fri, 5 Mar 2021 11:45:50 +0100 [thread overview]
Message-ID: <YEIL3qmcRfhUoRGt@myrica> (raw)
In-Reply-To: <20210223210625.604517-4-eric.auger@redhat.com>
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). 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.
Thanks,
Jean
next prev parent reply other threads:[~2021-03-05 10:47 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 [this message]
2021-03-08 18:12 ` Auger Eric
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=YEIL3qmcRfhUoRGt@myrica \
--to=jean-philippe@linaro.org \
--cc=alex.williamson@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@linux.intel.com \
--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).