From: Will Deacon <will.deacon@arm.com>
To: Auger Eric <eric.auger@redhat.com>
Cc: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
Bharat Bhushan <bharat.bhushan@nxp.com>,
"eric.auger.pro@gmail.com" <eric.auger.pro@gmail.com>,
"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"mst@redhat.com" <mst@redhat.com>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"wei@redhat.com" <wei@redhat.com>,
"kevin.tian@intel.com" <kevin.tian@intel.com>,
"marc.zyngier@arm.com" <marc.zyngier@arm.com>,
"tn@semihalf.com" <tn@semihalf.com>,
"drjones@redhat.com" <drjones@redhat.com>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"christoffer.dall@linaro.org" <christoffer.dall@linaro.org>
Subject: Re: [Qemu-devel] [RFC v2 0/8] VIRTIO-IOMMU device
Date: Tue, 27 Jun 2017 09:46:42 +0100 [thread overview]
Message-ID: <20170627084641.GC5759@arm.com> (raw)
In-Reply-To: <6070f02d-20d3-98fb-e31a-e7dbf5010419@redhat.com>
Hi Eric,
On Tue, Jun 27, 2017 at 08:38:48AM +0200, Auger Eric wrote:
> On 26/06/2017 18:13, Jean-Philippe Brucker wrote:
> > On 26/06/17 09:22, Auger Eric wrote:
> >> On 19/06/2017 12:15, Jean-Philippe Brucker wrote:
> >>> On 19/06/17 08:54, Bharat Bhushan wrote:
> >>>> I started added replay in virtio-iommu and came across how MSI interrupts with work with VFIO.
> >>>> I understand that on intel this works differently but vsmmu will have same requirement.
> >>>> kvm-msi-irq-route are added using the msi-address to be translated by viommu and not the final translated address.
> >>>> While currently the irqfd framework does not know about emulated iommus (virtio-iommu, vsmmuv3/vintel-iommu).
> >>>> So in my view we have following options:
> >>>> - Programming with translated address when setting up kvm-msi-irq-route
> >>>> - Route the interrupts via QEMU, which is bad from performance
> >>>> - vhost-virtio-iommu may solve the problem in long term
> >>>>
> >>>> Is there any other better option I am missing?
> >>>
> >>> Since we're on the topic of MSIs... I'm currently trying to figure out how
> >>> we'll handle MSIs in the nested translation mode, where the guest manages
> >>> S1 page tables and the host doesn't know about GVA->GPA translation.
> >>
> >> I have a question about the "nested translation mode" terminology. Do
> >> you mean in that case you use stage 1 + stage 2 of the physical IOMMU
> >> (which the ARM spec normally advises or was meant for) or do you mean
> >> stage 1 implemented in vIOMMU and stage 2 implemented in pIOMMU. At the
> >> moment my understanding is for VFIO integration the pIOMMU uses a single
> >> stage combining both the stage 1 and stage2 mappings but the host is not
> >> aware of those 2 stages.
> >
> > Yes at the moment the VMM merges stage-1 (GVA->GPA) from the guest with
> > its stage-2 mappings (GPA->HPA) and creates a stage-2 mapping (GVA->HPA)
> > in the pIOMMU via VFIO_IOMMU_MAP_DMA. stage-1 is disabled in the pIOMMU.
> >
> > What I mean by "nested mode" is stage 1 + stage 2 in the physical IOMMU.
> > I'm referring to the "Page Table Sharing" bit of the Future Work in the
> > initial RFC for virtio-iommu [1], and also PASID table binding [2] in the
> > case of vSMMU. In that mode, stage-1 page tables in the pIOMMU are managed
> > by the guest, and the VMM only maps GPA->HPA.
>
> OK I need to read that part more thoroughly. I was told in the past
> handling nested stages at pIOMMU was considered too complex and
> difficult to maintain. But definitively The SMMU architecture is devised
> for that. Michael asked why we did not use that already for vsmmu
> (nested stages are used on AMD IOMMU I think).
Curious -- but what gave you that idea? I worry that something I might have
said wasn't clear or has been misunderstood.
Will
next prev parent reply other threads:[~2017-06-27 8:46 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-07 16:01 [Qemu-devel] [RFC v2 0/8] VIRTIO-IOMMU device Eric Auger
2017-06-07 16:01 ` [Qemu-devel] [RFC v2 1/8] update-linux-headers: import virtio_iommu.h Eric Auger
2017-06-07 16:01 ` [Qemu-devel] [RFC v2 2/8] linux-headers: Update for virtio-iommu Eric Auger
2017-06-07 16:01 ` [Qemu-devel] [RFC v2 3/8] virtio_iommu: add skeleton Eric Auger
2017-06-08 11:09 ` Bharat Bhushan
2017-06-23 16:08 ` Jean-Philippe Brucker
2017-06-07 16:01 ` [Qemu-devel] [RFC v2 4/8] virtio-iommu: Decode the command payload Eric Auger
2017-06-07 16:01 ` [Qemu-devel] [RFC v2 5/8] virtio_iommu: Add the iommu regions Eric Auger
2017-06-12 5:59 ` Bharat Bhushan
2017-06-07 16:01 ` [Qemu-devel] [RFC v2 6/8] virtio-iommu: Implement the translation and commands Eric Auger
2017-06-23 16:09 ` Jean-Philippe Brucker
2017-07-04 9:13 ` Bharat Bhushan
2017-07-05 6:40 ` Auger Eric
2017-07-14 2:17 ` Peter Xu
2017-07-14 6:40 ` Bharat Bhushan
2017-07-17 1:28 ` Peter Xu
2017-07-31 13:08 ` Auger Eric
2017-08-03 10:48 ` Bharat Bhushan
2017-07-14 11:25 ` Jean-Philippe Brucker
2017-07-17 1:37 ` Peter Xu
2017-06-07 16:01 ` [Qemu-devel] [RFC v2 7/8] hw/arm/virt: Add 2.10 machine type Eric Auger
2017-06-07 16:01 ` [Qemu-devel] [RFC v2 8/8] hw/arm/virt: Add virtio-iommu the virt board Eric Auger
2017-06-09 6:16 ` [Qemu-devel] [RFC v2 0/8] VIRTIO-IOMMU device Bharat Bhushan
2017-06-09 6:43 ` Auger Eric
2017-06-09 11:30 ` Bharat Bhushan
2017-06-09 11:53 ` Auger Eric
2017-06-19 7:54 ` Bharat Bhushan
2017-06-19 10:15 ` Jean-Philippe Brucker
2017-06-26 8:22 ` Auger Eric
2017-06-26 16:13 ` Jean-Philippe Brucker
2017-06-27 6:38 ` Auger Eric
2017-06-27 8:46 ` Will Deacon [this message]
2017-06-27 8:59 ` Auger Eric
2017-07-05 7:25 ` Tian, Kevin
2017-07-05 12:44 ` Jean-Philippe Brucker
2017-07-05 7:14 ` Tian, Kevin
2017-07-05 12:44 ` Jean-Philippe Brucker
2017-07-07 6:21 ` Tian, Kevin
2017-07-07 15:15 ` Jean-Philippe Brucker
2017-07-14 7:20 ` Tian, Kevin
2017-07-14 11:25 ` Jean-Philippe Brucker
2017-07-17 2:20 ` Tian, Kevin
2017-07-05 7:15 ` Bharat Bhushan
2017-06-26 7:54 ` Auger Eric
2017-07-05 8:23 ` Bharat Bhushan
2017-07-05 8:44 ` Auger Eric
2017-07-05 8:49 ` Bharat Bhushan
2017-07-06 10:02 ` Jean-Philippe Brucker
2017-07-06 11:24 ` Bharat Bhushan
2017-07-06 11:55 ` Jean-Philippe Brucker
2017-07-06 21:16 ` Auger Eric
2017-07-06 23:23 ` [Qemu-devel] [Qemu-arm] " Kalra, Ashish
2017-07-06 23:29 ` Michael S. Tsirkin
2017-07-06 23:33 ` Tian, Kevin
2017-07-07 15:14 ` Jean-Philippe Brucker
2017-07-07 22:11 ` Kalra, Ashish
2017-07-11 11:31 ` Jean-Philippe Brucker
2017-07-14 6:58 ` Tian, Kevin
2017-07-07 6:25 ` [Qemu-devel] " Bharat Bhushan
2017-07-07 7:25 ` Auger Eric
2017-07-07 11:36 ` Bharat Bhushan
2017-07-07 15:19 ` Jean-Philippe Brucker
2017-07-11 5:54 ` Bharat Bhushan
2017-07-11 12:51 ` Jean-Philippe Brucker
2017-07-12 3:50 ` Bharat Bhushan
2017-07-12 10:18 ` Jean-Philippe Brucker
2017-07-12 10:27 ` Bharat Bhushan
2017-07-12 10:58 ` Jean-Philippe Brucker
2017-07-12 11:12 ` Bharat Bhushan
2017-07-06 21:11 ` Auger Eric
2017-07-07 7:31 ` Auger Eric
2017-07-07 15:20 ` Jean-Philippe Brucker
2017-06-09 12:15 ` Auger Eric
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=20170627084641.GC5759@arm.com \
--to=will.deacon@arm.com \
--cc=alex.williamson@redhat.com \
--cc=bharat.bhushan@nxp.com \
--cc=christoffer.dall@linaro.org \
--cc=drjones@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=eric.auger@redhat.com \
--cc=jean-philippe.brucker@arm.com \
--cc=kevin.tian@intel.com \
--cc=marc.zyngier@arm.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=robin.murphy@arm.com \
--cc=tn@semihalf.com \
--cc=wei@redhat.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).