[Qemu-commits] [qemu/qemu] 58892b: hw/vfio/platform: irqfd setup sequence update

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 58892b447f0ffcd0967bc6f1bcb40df288ebeebc
      
https://github.com/qemu/qemu/commit/58892b447f0ffcd0967bc6f1bcb40df288ebeebc
  Author: Eric Auger <address@hidden>
  Date:   2015-10-05 (Mon, 05 Oct 2015)

  Changed paths:
    M hw/vfio/platform.c

  Log Message:
  -----------
  hw/vfio/platform: irqfd setup sequence update

With current implementation, eventfd VFIO signaling is first set up and
then irqfd is setup, if supported and allowed.

This start sequence causes several issues with IRQ forwarding setup
which, if supported, is transparently attempted on irqfd setup:
IRQ forwarding setup is likely to fail if the IRQ is detected as under
injection into the guest (active at irqchip level or VFIO masked).

This currently always happens because the current sequence explicitly
VFIO-masks the IRQ before setting irqfd.

Even if that masking were removed, we couldn't prevent the case where
the IRQ is under injection into the guest.

So the simpler solution is to remove this 2-step startup and directly
attempt irqfd setup. This is what this patch does.

Also in case the eventfd setup fails, there is no reason to go farther:
let's abort.

Signed-off-by: Eric Auger <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>


  Commit: a22313deca720e038ebc5805cf451b3a685d29ce
      
https://github.com/qemu/qemu/commit/a22313deca720e038ebc5805cf451b3a685d29ce
  Author: Eric Auger <address@hidden>
  Date:   2015-10-05 (Mon, 05 Oct 2015)

  Changed paths:
    M hw/vfio/platform.c
    M include/hw/vfio/vfio-platform.h

  Log Message:
  -----------
  hw/vfio/platform: change interrupt/unmask fields into pointer

unmask EventNotifier might not be initialized in case of edge
sensitive irq. Using EventNotifier pointers make life simpler to
handle the edge-sensitive irqfd setup.

Signed-off-by: Eric Auger <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>


  Commit: a5b39cd3f647eaaaef5b648beda5cb2f387418c0
      
https://github.com/qemu/qemu/commit/a5b39cd3f647eaaaef5b648beda5cb2f387418c0
  Author: Eric Auger <address@hidden>
  Date:   2015-10-05 (Mon, 05 Oct 2015)

  Changed paths:
    M hw/vfio/platform.c
    M trace-events

  Log Message:
  -----------
  hw/vfio/platform: do not set resamplefd for edge-sensitive IRQS

In irqfd mode, current code attempts to set a resamplefd whatever
the type of the IRQ. For an edge-sensitive IRQ this attempt fails
and as a consequence, the whole irqfd setup fails and we fall back
to the slow mode. This patch bypasses the resamplefd setting for
non level-sentive IRQs.

Signed-off-by: Eric Auger <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>


  Commit: ee0bf0e59bb1c07c0196142f2ecfd88f7f8b194e
      
https://github.com/qemu/qemu/commit/ee0bf0e59bb1c07c0196142f2ecfd88f7f8b194e
  Author: David Gibson <address@hidden>
  Date:   2015-10-05 (Mon, 05 Oct 2015)

  Changed paths:
    M hw/vfio/common.c
    M include/hw/vfio/vfio-common.h

  Log Message:
  -----------
  vfio: Remove unneeded union from VFIOContainer

Currently the VFIOContainer iommu_data field contains a union with
different information for different host iommu types.  However:
   * It only actually contains information for the x86-like "Type1" iommu
   * Because we have a common listener the Type1 fields are actually used
on all IOMMU types, including the SPAPR TCE type as well

In fact we now have a general structure for the listener which is unlikely
to ever need per-iommu-type information, so this patch removes the union.

In a similar way we can unify the setup of the vfio memory listener in
vfio_connect_container() that is currently split across a switch on iommu
type, but is effectively the same in both cases.

The iommu_data.release pointer was only needed as a cleanup function
which would handle potentially different data in the union.  With the
union gone, it too can be removed.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>


  Commit: ac6dc3894fbb6775245565229953879a0263d27f
      
https://github.com/qemu/qemu/commit/ac6dc3894fbb6775245565229953879a0263d27f
  Author: David Gibson <address@hidden>
  Date:   2015-10-05 (Mon, 05 Oct 2015)

  Changed paths:
    M hw/vfio/common.c

  Log Message:
  -----------
  vfio: Generalize vfio_listener_region_add failure path

If a DMA mapping operation fails in vfio_listener_region_add() it
checks to see if we've already completed initial setup of the
container.  If so it reports an error so the setup code can fail
gracefully, otherwise throws a hw_error().

There are other potential failure cases in vfio_listener_region_add()
which could benefit from the same logic, so move it to its own
fail: block.  Later patches can use this to extend other failure cases
to fail as gracefully as possible under the circumstances.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>


  Commit: 3898aad323475cf19127d9fc0846954d591d8e11
      
https://github.com/qemu/qemu/commit/3898aad323475cf19127d9fc0846954d591d8e11
  Author: David Gibson <address@hidden>
  Date:   2015-10-05 (Mon, 05 Oct 2015)

  Changed paths:
    M hw/vfio/common.c
    M include/hw/vfio/vfio-common.h

  Log Message:
  -----------
  vfio: Check guest IOVA ranges against host IOMMU capabilities

The current vfio core code assumes that the host IOMMU is capable of
mapping any IOVA the guest wants to use to where we need.  However, real
IOMMUs generally only support translating a certain range of IOVAs (the
"DMA window") not a full 64-bit address space.

The common x86 IOMMUs support a wide enough range that guests are very
unlikely to go beyond it in practice, however the IOMMU used on IBM Power
machines - in the default configuration - supports only a much more limited
IOVA range, usually 0..2GiB.

If the guest attempts to set up an IOVA range that the host IOMMU can't
map, qemu won't report an error until it actually attempts to map a bad
IOVA.  If guest RAM is being mapped directly into the IOMMU (i.e. no guest
visible IOMMU) then this will show up very quickly.  If there is a guest
visible IOMMU, however, the problem might not show up until much later when
the guest actually attempt to DMA with an IOVA the host can't handle.

This patch adds a test so that we will detect earlier if the guest is
attempting to use IOVA ranges that the host IOMMU won't be able to deal
with.

For now, we assume that "Type1" (x86) IOMMUs can support any IOVA, this is
incorrect, but no worse than what we have already.  We can't do better for
now because the Type1 kernel interface doesn't tell us what IOVA range the
IOMMU actually supports.

For the Power "sPAPR TCE" IOMMU, however, we can retrieve the supported
IOVA range and validate guest IOVA ranges against it, and this patch does
so.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>


  Commit: 7a140a57c69293a2f19b045f40953a87879e8c76
      
https://github.com/qemu/qemu/commit/7a140a57c69293a2f19b045f40953a87879e8c76
  Author: David Gibson <address@hidden>
  Date:   2015-10-05 (Mon, 05 Oct 2015)

  Changed paths:
    M hw/vfio/common.c
    M include/hw/vfio/vfio-common.h

  Log Message:
  -----------
  vfio: Record host IOMMU's available IO page sizes

Depending on the host IOMMU type we determine and record the available page
sizes for IOMMU translation.  We'll need this for other validation in
future patches.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>


  Commit: a788f227ef7bd2912fcaacdfe13d13ece2998149
      
https://github.com/qemu/qemu/commit/a788f227ef7bd2912fcaacdfe13d13ece2998149
  Author: David Gibson <address@hidden>
  Date:   2015-10-05 (Mon, 05 Oct 2015)

  Changed paths:
    M include/exec/memory.h
    M memory.c

  Log Message:
  -----------
  memory: Allow replay of IOMMU mapping notifications

When we have guest visible IOMMUs, we allow notifiers to be registered
which will be informed of all changes to IOMMU mappings.  This is used by
vfio to keep the host IOMMU mappings in sync with guest IOMMU mappings.

However, unlike with a memory region listener, an iommu notifier won't be
told about any mappings which already exist in the (guest) IOMMU at the
time it is registered.  This can cause problems if hotplugging a VFIO
device onto a guest bus which had existing guest IOMMU mappings, but didn't
previously have an VFIO devices (and hence no host IOMMU mappings).

This adds a memory_region_iommu_replay() function to handle this case.  It
replays any existing mappings in an IOMMU memory region to a specified
notifier.  Because the IOMMU memory region doesn't internally remember the
granularity of the guest IOMMU it has a small hack where the caller must
specify a granularity at which to replay mappings.

If there are finer mappings in the guest IOMMU these will be reported in
the iotlb structures passed to the notifier which it must handle (probably
causing it to flag an error).  This isn't new - the VFIO iommu notifier
must already handle notifications about guest IOMMU mappings too short
for it to represent in the host IOMMU.

Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Acked-by: Paolo Bonzini <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>


  Commit: 508ce5eb00070809f0d19917a1b2960dfcf5a64b
      
https://github.com/qemu/qemu/commit/508ce5eb00070809f0d19917a1b2960dfcf5a64b
  Author: David Gibson <address@hidden>
  Date:   2015-10-05 (Mon, 05 Oct 2015)

  Changed paths:
    M hw/vfio/common.c

  Log Message:
  -----------
  vfio: Allow hotplug of containers onto existing guest IOMMU mappings

At present the memory listener used by vfio to keep host IOMMU mappings
in sync with the guest memory image assumes that if a guest IOMMU
appears, then it has no existing mappings.

This may not be true if a VFIO device is hotplugged onto a guest bus
which didn't previously include a VFIO device, and which has existing
guest IOMMU mappings.

Therefore, use the memory_region_register_iommu_notifier_replay()
function in order to fix this case, replaying existing guest IOMMU
mappings, bringing the host IOMMU into sync with the guest IOMMU.

Signed-off-by: David Gibson <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>


  Commit: 1d27b91723c252d9a97151dc1959cfd89c5816cb
      
https://github.com/qemu/qemu/commit/1d27b91723c252d9a97151dc1959cfd89c5816cb
  Author: Peter Maydell <address@hidden>
  Date:   2015-10-08 (Thu, 08 Oct 2015)

  Changed paths:
    M hw/vfio/common.c
    M hw/vfio/platform.c
    M include/exec/memory.h
    M include/hw/vfio/vfio-common.h
    M include/hw/vfio/vfio-platform.h
    M memory.c
    M trace-events

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/awilliam/tags/vfio-update-20151007.0' 
into staging

VFIO updates 2015-10-07

 - Change platform device IRQ setup sequence for compatibility
   with upcoming IRQ forwarding (Eric Auger)
 - Extensions to support vfio-pci devices on spapr-pci-host-bridge
   (David Gibson) [clang problem patch dropped]

# gpg: Signature made Wed 07 Oct 2015 16:30:52 BST using RSA key ID 3BB08B22
# gpg: Good signature from "Alex Williamson <address@hidden>"
# gpg:                 aka "Alex Williamson <address@hidden>"
# gpg:                 aka "Alex Williamson <address@hidden>"
# gpg:                 aka "Alex Williamson <address@hidden>"

* remotes/awilliam/tags/vfio-update-20151007.0:
  vfio: Allow hotplug of containers onto existing guest IOMMU mappings
  memory: Allow replay of IOMMU mapping notifications
  vfio: Record host IOMMU's available IO page sizes
  vfio: Check guest IOVA ranges against host IOMMU capabilities
  vfio: Generalize vfio_listener_region_add failure path
  vfio: Remove unneeded union from VFIOContainer
  hw/vfio/platform: do not set resamplefd for edge-sensitive IRQS
  hw/vfio/platform: change interrupt/unmask fields into pointer
  hw/vfio/platform: irqfd setup sequence update

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/31c9bd164ddb...1d27b91723c2