lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150204155247.29468.20260.stgit@gimli.home>
Date:	Wed, 04 Feb 2015 09:12:45 -0700
From:	Alex Williamson <alex.williamson@...hat.com>
To:	kvm@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, alex.williamson@...hat.com
Subject: [PATCH 0/5] vfio/pci: Device request support

Currently when the host kernel attempts to unbind an in-use device
from a vfio driver, we simply block until userspace releases the
device.  With a cooperative userspace client, we can do better (we can
potentially do better with a non-cooperative client too, but this
series does not attempt to address that).  Instead of idly waiting,
we can poke the vfio bus driver using a new device request callback.
For vfio-pci, this is exposed to the user as a new device management
interrupt, like the error reporting interrupt.  With a userspace
client like QEMU, this can be tied to an unplug request, allowing
for automatic removal of a device from a VM when an unbind request is
made on the host.  This of course presumes that the host operation
takes precedence over VM policy or else the VM would not choose to
be cooperative to the request.

A couple issues are fixed to make this reliable, the first being to
close a race where a driver stalled on an unbind can create a small
window where the vfio group is non-viable.  This can interfere with
attempts to acquire a group reference to match and release an
existing reference.  The other problem is that our IOMMU group ref
is tied to the device, so if the device is removed, the IOMMU group
can be removed, putting the vfio group in an awkward state.  The
reference is moved to the vfio group to prevent this.  The rest is
a straight forward addition of a callback and eventfd notifier path.
Thanks,

Alex

---

Alex Williamson (5):
      vfio-pci: Add device request interface
      vfio-pci: Generalize setup of simple eventfds
      vfio: Add and use device request op for vfio bus drivers
      vfio: Tie IOMMU group reference to vfio group
      vfio: Add device tracking during unbind


 drivers/vfio/pci/vfio_pci.c         |   21 ++++++
 drivers/vfio/pci/vfio_pci_intrs.c   |   60 +++++++++++++-----
 drivers/vfio/pci/vfio_pci_private.h |    1 
 drivers/vfio/vfio.c                 |  119 +++++++++++++++++++++++++++++++----
 include/linux/vfio.h                |    2 +
 include/uapi/linux/vfio.h           |    1 
 6 files changed, 173 insertions(+), 31 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ