aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/vfio (follow)
AgeCommit message (Collapse)AuthorFilesLines
2012-12-07vfio-pci: Enable device before attempting resetAlex Williamson1-13/+10
Devices making use of PM reset are getting incorrectly identified as not supporting reset because pci_pm_reset() fails unless the device is in D0 power state. When first attached to vfio_pci devices are typically in an unknown power state. We can fix this by explicitly setting the power state or simply calling pci_enable_device() before attempting a pci_reset_function(). We need to enable the device anyway, so move this up in our vfio_pci_enable() function, which also simplifies the error path a bit. Note that pci_disable_device() does not explicitly set the power state, so there's no need to re-order vfio_pci_disable(). Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2012-12-07VFIO: fix out of order labels for error recovery in vfio_pci_init()Jiang Liu1-2/+2
The two labels for error recovery in function vfio_pci_init() is out of order, so fix it. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2012-12-07VFIO: use ACCESS_ONCE() to guard access to dev->driverJiang Liu1-1/+2
Comments from dev_driver_string(), /* dev->driver can change to NULL underneath us because of unbinding, * so be careful about accessing it. */ So use ACCESS_ONCE() to guard access to dev->driver field. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2012-12-07VFIO: unregister IOMMU notifier on error recovery pathJiang Liu1-16/+15
On error recovery path in function vfio_create_group(), it should unregister the IOMMU notifier for the new VFIO group. Otherwise it may cause invalid memory access later when handling bus notifications. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2012-12-07vfio-pci: Re-order device resetAlex Williamson1-12/+31
Move the device reset to the end of our disable path, the device should already be stopped from pci_disable_device(). This also allows us to manipulate the save/restore to avoid the save/reset/restore + save/restore that we had before. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2012-12-07vfio: simplify kmalloc+copy_from_user to memdup_userFengguang Wu1-9/+4
Generated by: coccinelle/api/memdup_user.cocci Acked-by: Julia Lawall <julia.lawall@lip6.fr> Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2012-10-10vfio: Fix PCI INTx disable consistencyAlex Williamson1-1/+12
The virq_disabled flag tracks the userspace view of INTx masking across interrupt mode changes, but we're not consistently applying this to the interrupt and masking handler notion of the device. Currently if the user sets DisINTx while in MSI or MSIX mode, then returns to INTx mode (ex. rebooting a qemu guest), the hardware has DisINTx+, but the management of INTx thinks it's enabled, making it impossible to actually clear DisINTx. Fix this by updating the handler state when INTx is re-enabled. Cc: stable@vger.kernel.org Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2012-10-10vfio: Move PCI INTx eventfd setting earlierAlex Williamson1-2/+3
We need to be ready to recieve an interrupt as soon as we call request_irq, so our eventfd context setting needs to be moved earlier. Without this, an interrupt from our device or one sharing the interrupt line can pass a NULL into eventfd_signal and oops. Cc: stable@vger.kernel.org Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2012-10-10vfio: Fix PCI mmap after b3b9c293Alex Williamson1-4/+3
Our mmap path mistakely relied on vma->vm_pgoff to get set in remap_pfn_range. After b3b9c293, that path only applies to copy-on-write mappings. Set it in our own code. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2012-10-09Fix staging driver use of VM_RESERVEDLinus Torvalds1-1/+1
The VM_RESERVED flag was killed off in commit 314e51b9851b ("mm: kill vma flag VM_RESERVED and mm->reserved_vm counter"), and replaced by the proper semantic flags (eg "don't core-dump" etc). But there was a new use of VM_RESERVED that got missed by the merge. Fix the remaining use of VM_RESERVED in the vfio_pci driver, replacing the VM_RESERVED flag with VM_DONTEXPAND | VM_DONTDUMP. Signed-off-by: Linus Torvalds <torvalds@linux-foundation,org>
2012-09-26switch simple cases of fget_light to fdgetAl Viro1-9/+8
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-09-26switch vfio_group_set_container() to fget_light()Al Viro1-4/+4
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-09-21vfio: Fix virqfd release raceAlex Williamson1-20/+56
vfoi-pci supports a mechanism like KVM's irqfd for unmasking an interrupt through an eventfd. There are two ways to shutdown this interface: 1) close the eventfd, 2) ioctl (such as disabling the interrupt). Both of these do the release through a workqueue, which can result in a segfault if two jobs get queued for the same virqfd. Fix this by protecting the pointer to these virqfds by a spinlock. The vfio pci device will therefore no longer have a reference to it once the release job is queued under lock. On the ioctl side, we still flush the workqueue to ensure that any outstanding releases are completed. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2012-08-22vfio: grab vfio_device reference *before* exposing the sucker via fd_install()Al Viro1-2/+2
It's not critical (anymore) since another thread closing the file will block on ->device_lock before it gets to dropping the final reference, but it's definitely cleaner that way... Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-08-22vfio: get rid of vfio_device_put()/vfio_group_get_device* racesAl Viro1-2/+1
we really need to make sure that dropping the last reference happens under the group->device_lock; otherwise a loop (under device_lock) might find vfio_device instance that is being freed right now, has already dropped the last reference and waits on device_lock to exclude the sucker from the list. Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-08-22vfio: get rid of open-coding kref_put_mutexAl Viro1-7/+2
Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-08-22vfio: don't dereference after kfree...Al Viro1-1/+2
Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-07-31vfio: Add PCI device driverAlex Williamson8-0/+3233
Add PCI device support for VFIO. PCI devices expose regions for accessing config space, I/O port space, and MMIO areas of the device. PCI config access is virtualized in the kernel, allowing us to ensure the integrity of the system, by preventing various accesses while reducing duplicate support across various userspace drivers. I/O port supports read/write access while MMIO also supports mmap of sufficiently sized regions. Support for INTx, MSI, and MSI-X interrupts are provided using eventfds to userspace. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2012-07-31vfio: Type1 IOMMU implementationAlex Williamson4-0/+768
This VFIO IOMMU backend is designed primarily for AMD-Vi and Intel VT-d hardware, but is potentially usable by anything supporting similar mapping functionality. We arbitrarily call this a Type1 backend for lack of a better name. This backend has no IOVA or host memory mapping restrictions for the user and is optimized for relatively static mappings. Mapped areas are pinned into system memory. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2012-07-31vfio: VFIO coreAlex Williamson3-0/+1422
VFIO is a secure user level driver for use with both virtual machines and user level drivers. VFIO makes use of IOMMU groups to ensure the isolation of devices in use, allowing unprivileged user access. It's intended that VFIO will replace KVM device assignment and UIO drivers (in cases where the target platform includes a sufficiently capable IOMMU). New in this version of VFIO is support for IOMMU groups managed through the IOMMU core as well as a rework of the API, removing the group merge interface. We now go back to a model more similar to original VFIO with UIOMMU support where the file descriptor obtained from /dev/vfio/vfio allows access to the IOMMU, but only after a group is added, avoiding the previous privilege issues with this type of model. IOMMU support is also now fully modular as IOMMUs have vastly different interface requirements on different platforms. VFIO users are able to query and initialize the IOMMU model of their choice. Please see the follow-on Documentation commit for further description and usage example. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.