All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Eric Auger <eric.auger@linaro.org>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	eric.auger@st.com, christoffer.dall@linaro.org,
	marc.zyngier@arm.com, linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	Bharat.Bhushan@freescale.com, pranav.sawargaonkar@gmail.com,
	p.fedin@samsung.com, suravee.suthikulpanit@amd.com,
	linux-kernel@vger.kernel.org, patches@linaro.org,
	iommu@lists.linux-foundation.org
Subject: Re: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
Date: Mon, 1 Feb 2016 14:03:51 +0000	[thread overview]
Message-ID: <20160201140351.GE6828@arm.com> (raw)
In-Reply-To: <56ABD8E0.6080409@linaro.org>

On Fri, Jan 29, 2016 at 10:25:52PM +0100, Eric Auger wrote:
> On 01/29/2016 08:33 PM, Alex Williamson wrote:
> >>> We know that x86 handles MSI vectors specially, so there is some
> >>> hardware that helps the situation.  It's not just that x86 has a fixed
> >>> range for MSI, it's how it manages that range when interrupt remapping
> >>> hardware is enabled.  A device table indexed by source-ID references a
> >>> per device table indexed by data from the MSI write itself.  So we get
> >>> much, much finer granularity,
> >> About the granularity, I think ARM GICv3 now provides a similar
> >> capability with GICv3 ITS (interrupt translation service). Along with
> >> the MSI MSG write transaction, the device outputs a DeviceID conveyed on
> >> the bus. This DeviceID (~ your source-ID) enables to index a device
> >> table. The entry in the device table points to a DeviceId interrupt
> >> translation table indexed by the EventID found in the msi msg. So the
> >> entry in the interrupt translation table eventually gives you the
> >> eventual interrupt ID targeted by the MSI MSG.
> >> This translation capability if not available in GICv2M though, ie. the
> >> one I am currently using.
> >>  
> >> Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)

That's right. GICv3/ITS disambiguates the interrupt source using the
DeviceID, which for PCI is derived from the Requester ID of the endpoint.
GICv2m is less flexible and requires a separate physical frame per guest
to achieve isolation.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: eric.auger-qxv4g6HH51o@public.gmane.org,
	kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	marc.zyngier-5wv7dgnIgG8@public.gmane.org,
	p.fedin-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
Date: Mon, 1 Feb 2016 14:03:51 +0000	[thread overview]
Message-ID: <20160201140351.GE6828@arm.com> (raw)
In-Reply-To: <56ABD8E0.6080409-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

On Fri, Jan 29, 2016 at 10:25:52PM +0100, Eric Auger wrote:
> On 01/29/2016 08:33 PM, Alex Williamson wrote:
> >>> We know that x86 handles MSI vectors specially, so there is some
> >>> hardware that helps the situation.  It's not just that x86 has a fixed
> >>> range for MSI, it's how it manages that range when interrupt remapping
> >>> hardware is enabled.  A device table indexed by source-ID references a
> >>> per device table indexed by data from the MSI write itself.  So we get
> >>> much, much finer granularity,
> >> About the granularity, I think ARM GICv3 now provides a similar
> >> capability with GICv3 ITS (interrupt translation service). Along with
> >> the MSI MSG write transaction, the device outputs a DeviceID conveyed on
> >> the bus. This DeviceID (~ your source-ID) enables to index a device
> >> table. The entry in the device table points to a DeviceId interrupt
> >> translation table indexed by the EventID found in the msi msg. So the
> >> entry in the interrupt translation table eventually gives you the
> >> eventual interrupt ID targeted by the MSI MSG.
> >> This translation capability if not available in GICv2M though, ie. the
> >> one I am currently using.
> >>  
> >> Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)

That's right. GICv3/ITS disambiguates the interrupt source using the
DeviceID, which for PCI is derived from the Requester ID of the endpoint.
GICv2m is less flexible and requires a separate physical frame per guest
to achieve isolation.

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
Date: Mon, 1 Feb 2016 14:03:51 +0000	[thread overview]
Message-ID: <20160201140351.GE6828@arm.com> (raw)
In-Reply-To: <56ABD8E0.6080409@linaro.org>

On Fri, Jan 29, 2016 at 10:25:52PM +0100, Eric Auger wrote:
> On 01/29/2016 08:33 PM, Alex Williamson wrote:
> >>> We know that x86 handles MSI vectors specially, so there is some
> >>> hardware that helps the situation.  It's not just that x86 has a fixed
> >>> range for MSI, it's how it manages that range when interrupt remapping
> >>> hardware is enabled.  A device table indexed by source-ID references a
> >>> per device table indexed by data from the MSI write itself.  So we get
> >>> much, much finer granularity,
> >> About the granularity, I think ARM GICv3 now provides a similar
> >> capability with GICv3 ITS (interrupt translation service). Along with
> >> the MSI MSG write transaction, the device outputs a DeviceID conveyed on
> >> the bus. This DeviceID (~ your source-ID) enables to index a device
> >> table. The entry in the device table points to a DeviceId interrupt
> >> translation table indexed by the EventID found in the msi msg. So the
> >> entry in the interrupt translation table eventually gives you the
> >> eventual interrupt ID targeted by the MSI MSG.
> >> This translation capability if not available in GICv2M though, ie. the
> >> one I am currently using.
> >>  
> >> Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)

That's right. GICv3/ITS disambiguates the interrupt source using the
DeviceID, which for PCI is derived from the Requester ID of the endpoint.
GICv2m is less flexible and requires a separate physical frame per guest
to achieve isolation.

Will

  reply	other threads:[~2016-02-01 14:03 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-26 13:12 [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` [PATCH 01/10] iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12 ` [PATCH 02/10] vfio: expose MSI mapping requirement through VFIO_IOMMU_GET_INFO Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12 ` [PATCH 03/10] vfio_iommu_type1: add reserved binding RB tree management Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12 ` [PATCH 04/10] vfio: introduce VFIO_IOVA_RESERVED vfio_dma type Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12 ` [PATCH 05/10] vfio/type1: attach a reserved iova domain to vfio_domain Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12 ` [PATCH 06/10] vfio: introduce vfio_group_alloc_map_/unmap_free_reserved_iova Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 16:17   ` kbuild test robot
2016-01-26 16:17     ` kbuild test robot
2016-01-26 16:17     ` kbuild test robot
2016-01-26 16:17     ` kbuild test robot
2016-01-26 16:37     ` Eric Auger
2016-01-26 16:37       ` Eric Auger
2016-01-26 16:37       ` Eric Auger
2016-01-26 13:12 ` [PATCH 07/10] vfio: pci: cache the vfio_group in vfio_pci_device Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12 ` [PATCH 08/10] vfio: introduce vfio_group_require_msi_mapping Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12 ` [PATCH 09/10] vfio-pci: create an iommu mapping for msi address Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 14:43   ` kbuild test robot
2016-01-26 14:43     ` kbuild test robot
2016-01-26 14:43     ` kbuild test robot
2016-01-26 14:43     ` kbuild test robot
2016-01-26 15:14     ` Eric Auger
2016-01-26 15:14       ` Eric Auger
2016-01-26 15:14       ` Eric Auger
2016-01-26 13:12 ` [PATCH 10/10] vfio: allow the user to register reserved iova range for MSI mapping Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 13:12   ` Eric Auger
2016-01-26 16:42   ` kbuild test robot
2016-01-26 16:42     ` kbuild test robot
2016-01-26 16:42     ` kbuild test robot
2016-01-26 18:32   ` kbuild test robot
2016-01-26 18:32     ` kbuild test robot
2016-01-26 18:32     ` kbuild test robot
2016-01-26 18:32     ` kbuild test robot
2016-01-26 17:25 ` [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 Pavel Fedin
2016-01-26 17:25   ` Pavel Fedin
2016-01-26 17:25   ` Pavel Fedin
2016-01-27  8:52   ` Eric Auger
2016-01-27  8:52     ` Eric Auger
2016-01-27  8:52     ` Eric Auger
2016-01-28  7:13     ` Pavel Fedin
2016-01-28  7:13       ` Pavel Fedin
2016-01-28  7:13       ` Pavel Fedin
2016-01-28  9:50       ` Eric Auger
2016-01-28  9:50         ` Eric Auger
2016-01-28 21:51 ` Alex Williamson
2016-01-28 21:51   ` Alex Williamson
2016-01-28 21:51   ` Alex Williamson
2016-01-29 14:35   ` Eric Auger
2016-01-29 14:35     ` Eric Auger
2016-01-29 14:35     ` Eric Auger
2016-01-29 19:33     ` Alex Williamson
2016-01-29 19:33       ` Alex Williamson
2016-01-29 21:25       ` Eric Auger
2016-01-29 21:25         ` Eric Auger
2016-01-29 21:25         ` Eric Auger
2016-02-01 14:03         ` Will Deacon [this message]
2016-02-01 14:03           ` Will Deacon
2016-02-01 14:03           ` Will Deacon
2016-02-03 12:50           ` Christoffer Dall
2016-02-03 12:50             ` Christoffer Dall
2016-02-03 12:50             ` Christoffer Dall
2016-02-03 13:10             ` Will Deacon
2016-02-03 13:10               ` Will Deacon
2016-02-03 13:10               ` Will Deacon
2016-02-03 15:36               ` Christoffer Dall
2016-02-03 15:36                 ` Christoffer Dall
2016-02-03 15:36                 ` Christoffer Dall
2016-02-05 17:32                 ` ARM PCI/MSI KVM passthrough with GICv2M Eric Auger
2016-02-05 17:32                   ` Eric Auger
2016-02-05 18:17                   ` Alex Williamson
2016-02-05 18:17                     ` Alex Williamson
2016-02-05 18:17                     ` Alex Williamson
2016-02-08  9:48                     ` Christoffer Dall
2016-02-08  9:48                       ` Christoffer Dall
2016-02-08  9:48                       ` Christoffer Dall
2016-02-08 13:27                       ` Eric Auger
2016-02-08 13:27                         ` Eric Auger
2016-02-08 13:27                         ` Eric Auger

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=20160201140351.GE6828@arm.com \
    --to=will.deacon@arm.com \
    --cc=Bharat.Bhushan@freescale.com \
    --cc=alex.williamson@redhat.com \
    --cc=christoffer.dall@linaro.org \
    --cc=eric.auger@linaro.org \
    --cc=eric.auger@st.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=p.fedin@samsung.com \
    --cc=patches@linaro.org \
    --cc=pranav.sawargaonkar@gmail.com \
    --cc=suravee.suthikulpanit@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.