Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1398325

Re: [PATCH v9 7/7] vfio/type1: return MSI geometry through VFIO_IOMMU_GET_INFO capability chains

From Eric Auger <eric.auger@linaro.org>
Newsgroups linux.kernel
Subject Re: [PATCH v9 7/7] vfio/type1: return MSI geometry through VFIO_IOMMU_GET_INFO capability chains
Date 2016-05-10 19:00 +0200
Message-ID <rxjaP-6ly-17@gated-at.bofh.it> (permalink)
References <rv3Db-38F-1@gated-at.bofh.it> <rv3Dd-38F-29@gated-at.bofh.it> <rv3MS-3xj-1@gated-at.bofh.it> <rx2tj-76w-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 05/10/2016 01:03 AM, Alex Williamson wrote:
> On Wed, 4 May 2016 14:06:19 +0200
> Eric Auger <eric.auger@linaro.org> wrote:
> 
>> Hi Alex,
>> On 05/04/2016 01:54 PM, Eric Auger wrote:
>>> This patch allows the user-space to retrieve the MSI geometry. The
>>> implementation is based on capability chains, now also added to
>>> VFIO_IOMMU_GET_INFO.  
>>
>> If you prefer we could consider this patch outside of the main series
>> since it brings extra functionalities (MSI geometry reporting). In a
>> first QEMU integration we would live without knowing the MSI geometry I
>> think, all the more so I currently report an arbitrary number of
>> requested IOVA pages. The computation of the exact number of doorbells
>> to map brings extra complexity and I did not address this issue yet.
>>
>> It sketches a possible user API to report the MSI geometry based on the
>> capability chains, as you suggested some time ago. I am currently busy
>> drafting a QEMU integration.
> 
> How would the user know that reserved MSI mappings are requires or
> available without this?  Wouldn't the only option be for userspace to
> try to map something with the reserved MSI flag set and see if the
> kernel accepts it?
Well my first guess was that the (QEMU) virt machine using KVM/PCIe-MSI
passthrough could hardcode an arbitrary "large" iova size (currently 16
64kB pages in my QEMU integration). In case this is not sufficient for
mapping all host doorbells, we would see MSI allocation failing. In case
the need shows up, we could increase the value later on.
  That's not a very desirable programming model.  The
> arbitrary size is pretty ugly, but it at least makes for a consistent
> user interface.  Is it a functional issue if we overestimate the size
> or is it just a matter of wasting IOVA space?  Is there significant
> harm in making it obscenely large, like 1MB?
no just waste of IOVA space. To make it as transparent as possible for
virt machine I wanted to hide in the platform bus reserved IOVA.
  The reference counting and
> re-use of IOVA pages seems like we may often only be using a single
> IOVA page for multiple doorbells.  I guess I'm leaning towards defining
> the API even if the value is somewhat arbitrary because we'd rather have
> control of this rather than having the user guess and try to rope them
> back in later to use a kernel recommended value.  Thanks,

OK

Thanks

Eric
> 
> Alex
> 

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v9 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 3/3: vfio changes Eric Auger <eric.auger@linaro.org> - 2016-05-04 14:00 +0200
  [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at msi domain Eric Auger <eric.auger@linaro.org> - 2016-05-04 14:00 +0200
    Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at  msi domain "Chalamarla, Tirumalesh" <Tirumalesh.Chalamarla@caviumnetworks.com> - 2016-05-05 21:30 +0200
      Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at  msi domain Eric Auger <eric.auger@linaro.org> - 2016-05-09 10:10 +0200
    Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability  at msi domain Alex Williamson <alex.williamson@redhat.com> - 2016-05-10 00:50 +0200
      Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at  msi domain Eric Auger <eric.auger@linaro.org> - 2016-05-10 18:20 +0200
        Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at  msi domain Robin Murphy <robin.murphy@arm.com> - 2016-05-10 19:30 +0200
          Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at  msi domain Eric Auger <eric.auger@linaro.org> - 2016-05-11 10:50 +0200
            Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at  msi domain Robin Murphy <robin.murphy@arm.com> - 2016-05-11 11:40 +0200
              Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at  msi domain Eric Auger <eric.auger@linaro.org> - 2016-05-11 11:50 +0200
                Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at  msi domain Robin Murphy <robin.murphy@arm.com> - 2016-05-11 15:50 +0200
                Re: [PATCH v9 5/7] vfio/type1: also check IRQ remapping capability at  msi domain Eric Auger <eric.auger@linaro.org> - 2016-05-11 16:40 +0200
  [PATCH v9 6/7] iommu/arm-smmu: do not advertise IOMMU_CAP_INTR_REMAP Eric Auger <eric.auger@linaro.org> - 2016-05-04 14:00 +0200
  [PATCH v9 1/7] vfio: introduce a vfio_dma type field Eric Auger <eric.auger@linaro.org> - 2016-05-04 14:00 +0200
  [PATCH v9 7/7] vfio/type1: return MSI geometry through VFIO_IOMMU_GET_INFO capability chains Eric Auger <eric.auger@linaro.org> - 2016-05-04 14:00 +0200
    Re: [PATCH v9 7/7] vfio/type1: return MSI geometry through  VFIO_IOMMU_GET_INFO capability chains Eric Auger <eric.auger@linaro.org> - 2016-05-04 14:10 +0200
      Re: [PATCH v9 7/7] vfio/type1: return MSI geometry through  VFIO_IOMMU_GET_INFO capability chains Alex Williamson <alex.williamson@redhat.com> - 2016-05-10 01:10 +0200
        Re: [PATCH v9 7/7] vfio/type1: return MSI geometry through  VFIO_IOMMU_GET_INFO capability chains Eric Auger <eric.auger@linaro.org> - 2016-05-10 19:00 +0200
    Re: [PATCH v9 7/7] vfio/type1: return MSI geometry through  VFIO_IOMMU_GET_INFO capability chains Alex Williamson <alex.williamson@redhat.com> - 2016-05-10 01:00 +0200
      Re: [PATCH v9 7/7] vfio/type1: return MSI geometry through  VFIO_IOMMU_GET_INFO capability chains Eric Auger <eric.auger@linaro.org> - 2016-05-10 18:40 +0200
  [PATCH v9 2/7] vfio/type1: vfio_find_dma accepting a type argument Eric Auger <eric.auger@linaro.org> - 2016-05-04 14:00 +0200
    Re: [PATCH v9 2/7] vfio/type1: vfio_find_dma accepting a type  argument Alex Williamson <alex.williamson@redhat.com> - 2016-05-10 00:50 +0200
      Re: [PATCH v9 2/7] vfio/type1: vfio_find_dma accepting a type  argument Eric Auger <eric.auger@linaro.org> - 2016-05-10 17:00 +0200
  [PATCH v9 4/7] vfio: allow reserved msi iova registration Eric Auger <eric.auger@linaro.org> - 2016-05-04 14:00 +0200
    Re: [PATCH v9 4/7] vfio: allow reserved msi iova registration "Chalamarla, Tirumalesh" <Tirumalesh.Chalamarla@caviumnetworks.com> - 2016-05-05 21:40 +0200
      Re: [PATCH v9 4/7] vfio: allow reserved msi iova registration Eric Auger <eric.auger@linaro.org> - 2016-05-09 10:00 +0200
    Re: [PATCH v9 4/7] vfio: allow reserved msi iova registration Alex Williamson <alex.williamson@redhat.com> - 2016-05-10 17:40 +0200
      Re: [PATCH v9 4/7] vfio: allow reserved msi iova registration Eric Auger <eric.auger@linaro.org> - 2016-05-10 17:40 +0200
  [PATCH v9 3/7] vfio/type1: bypass unmap/unpin and replay for VFIO_IOVA_RESERVED slots Eric Auger <eric.auger@linaro.org> - 2016-05-04 14:00 +0200
    Re: [PATCH v9 3/7] vfio/type1: bypass unmap/unpin and replay for  VFIO_IOVA_RESERVED slots Alex Williamson <alex.williamson@redhat.com> - 2016-05-10 00:50 +0200
      Re: [PATCH v9 3/7] vfio/type1: bypass unmap/unpin and replay for  VFIO_IOVA_RESERVED slots Eric Auger <eric.auger@linaro.org> - 2016-05-11 15:00 +0200

csiph-web