[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140716184645.4153.86129.stgit@gimli.home>
Date: Wed, 16 Jul 2014 13:01:10 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: alex.williamson@...hat.com
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org
Subject: [PATCH 0/3] vfio-pci: Reset improvements
This series is intended to improve the state of devices returned back
to the host from vfio-pci or re-used by another user. First we make
sure that busmaster is disabled in the saved state, so the device
cannot continue to do DMA, then we add some serialization, move our
reference counting under it to fix an unlikely bug should we fail to
initialize a device, and add the ability to do bus/slot reset on
device release. To do this, we require all devices affected by the
bus/slot reset to be bound to vfio-pci, therefore users sequestering
devices with pci-stub will need to bind them to vfio-pci to see this
change.
The effect of these changes are perhaps most noticeable with GPU
assignment to a VM, where killing QEMU results in a static image on
the framebuffer since no reset of the device was done. Returning
the GPU to a host device at this point was suspect. Other devices,
like USB controllers, also don't necessarily appreciate being abruptly
disconnected from their IOMMU domain and would generate IOMMU faults
in the event the user process is killed. Both of these cases should
be resolved here, assuming all the devices on the bus are bound to
vfio-pci and at least one of the devices in use does not support
a function-local reset.
Please test and comment. Thanks,
Alex
---
Alex Williamson (3):
vfio-pci: Attempt bus/slot reset on release
vfio-pci: Use mutex around open, release, and remove
vfio-pci: Release devices with BusMaster disabled
drivers/vfio/pci/vfio_pci.c | 157 ++++++++++++++++++++++++++++++++---
drivers/vfio/pci/vfio_pci_private.h | 3 -
2 files changed, 147 insertions(+), 13 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