summaryrefslogtreecommitdiffstats
path: root/drivers/vfio/vfio.c
AgeCommit message (Collapse)AuthorFilesLines
2013-12-19vfio: Convert control interface to misc driverAlex Williamson1-37/+33
This change allows us to support module auto loading using devname support in userspace tools. With this, /dev/vfio/vfio will always be present and opening it will cause the vfio module to load. This should avoid needing to configure the system to statically load vfio in order to get libvirt to correctly detect support for it. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2013-08-22vfio: Add O_CLOEXEC flag to vfio device fdAlex Williamson1-1/+1
Add the default O_CLOEXEC flag for device file descriptors. This is generally considered a safer option as it allows the user a race free option to decide whether file descriptors are inherited across exec, with the default avoiding file descriptor leaks. Reported-by: Yann Droneaud <ydroneaud@opteya.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2013-08-22vfio: use get_unused_fd_flags(0) instead of get_unused_fd()Yann Droneaud1-1/+1
Macro get_unused_fd() is used to allocate a file descriptor with default flags. Those default flags (0) can be "unsafe": O_CLOEXEC must be used by default to not leak file descriptor across exec(). Instead of macro get_unused_fd(), functions anon_inode_getfd() or get_unused_fd_flags() should be used with flags given by userspace. If not possible, flags should be set to O_CLOEXEC to provide userspace with a default safe behavor. In a further patch, get_unused_fd() will be removed so that new code start using anon_inode_getfd() or get_unused_fd_flags() with correct flags. This patch replaces calls to get_unused_fd() with equivalent call to get_unused_fd_flags(0) to preserve current behavor for existing code. The hard coded flag value (0) should be reviewed on a per-subsystem basis, and, if possible, set to O_CLOEXEC. Signed-off-by: Yann Droneaud <ydroneaud@opteya.com> Link: http://lkml.kernel.org/r/cover.1376327678.git.ydroneaud@opteya.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2013-08-05vfio: add external user supportAlexey Kardashevskiy1-0/+62
VFIO is designed to be used via ioctls on file descriptors returned by VFIO. However in some situations support for an external user is required. The first user is KVM on PPC64 (SPAPR TCE protocol) which is going to use the existing VFIO groups for exclusive access in real/virtual mode on a host to avoid passing map/unmap requests to the user space which would made things pretty slow. The protocol includes: 1. do normal VFIO init operation: - opening a new container; - attaching group(s) to it; - setting an IOMMU driver for a container. When IOMMU is set for a container, all groups in it are considered ready to use by an external user. 2. User space passes a group fd to an external user. The external user calls vfio_group_get_external_user() to verify that: - the group is initialized; - IOMMU is set for it. If both checks passed, vfio_group_get_external_user() increments the container user counter to prevent the VFIO group from disposal before KVM exits. 3. The external user calls vfio_external_user_iommu_id() to know an IOMMU ID. PPC64 KVM uses it to link logical bus number (LIOBN) with IOMMU ID. 4. When the external KVM finishes, it calls vfio_group_put_external_user() to release the VFIO group. This call decrements the container user counter. Everything gets released. The "vfio: Limit group opens" patch is also required for the consistency. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2013-07-24vfio: Ignore sprurious notifiesAlex Williamson1-5/+3
Remove debugging WARN_ON if we get a spurious notify for a group that no longer exists. No reports of anyone hitting this, but it would likely be a race and not a bug if they did. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2013-07-24vfio: Don't overreact to DEL_DEVICEAlex Williamson1-22/+7
BUS_NOTIFY_DEL_DEVICE triggers IOMMU drivers to remove devices from their iommu group, but there's really nothing we can do about it at this point. If the device is in use, then the vfio sub-driver will block the device_del from completing until it's released. If the device is not in use or not owned by a vfio sub-driver, then we really don't care that it's being removed. The current code can be triggered just by unloading an sr-iov driver (ex. igb) while the VFs are attached to vfio-pci because it makes an incorrect assumption about the ordering of driver remove callbacks vs the DEL_DEVICE notification. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2013-07-10Merge tag 'vfio-v3.11' of git://github.com/awilliam/linux-vfioLinus Torvalds1-0/+14
Pull vfio updates from Alex Williamson: "Largely hugepage support for vfio/type1 iommu and surrounding cleanups and fixes" * tag 'vfio-v3.11' of git://github.com/awilliam/linux-vfio: vfio/type1: Fix leak on error path vfio: Limit group opens vfio/type1: Fix missed frees and zero sized removes vfio: fix documentation vfio: Provide module option to disable vfio_iommu_type1 hugepage support vfio: hugepage support for vfio_iommu_type1 vfio: Convert type1 iommu to use rbtree
2013-06-25vfio: Limit group opensAlex Williamson1-0/+14
vfio_group_fops_open attempts to limit concurrent sessions by disallowing opens once group->container is set. This really doesn't do what we want and allow for inconsistent behavior, for instance a group can be opened twice, then a container set giving the user two file descriptors to the group. But then it won't allow more to be opened. There's not much reason to have the group opened multiple times since most access is through devices or the container, so complete what the original code intended and only allow a single instance. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2013-06-20powerpc/vfio: Implement IOMMU driver for VFIOAlexey Kardashevskiy1-0/+1
VFIO implements platform independent stuff such as a PCI driver, BAR access (via read/write on a file descriptor or direct mapping when possible) and IRQ signaling. The platform dependent part includes IOMMU initialization and handling. This implements an IOMMU driver for VFIO which does mapping/unmapping pages for the guest IO and provides information about DMA window (required by a POWER guest). Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paul Mackerras <paulus@samba.org> Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-05vfio: fix crash on rmmodAlexey Kardashevskiy1-1/+1
devtmpfs_delete_node() calls devnode() callback with mode==NULL but vfio still tries to write there. The patch fixes this. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2013-04-30vfio: Set container device modeAlex Williamson1-0/+4
Minor 0 is the VFIO container device (/dev/vfio/vfio). On it's own the container does not provide a user with any privileged access. It only supports API version check and extension check ioctls. Only by attaching a VFIO group to the container does it gain any access. Set the mode of the container to allow access. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2013-04-29vfio: Use down_reads to protect iommu disconnectsAlex Williamson1-16/+46
If a group or device is released or a container is unset from a group it can race against file ops on the container. Protect these with down_reads to allow concurrent users. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reported-by: Michael S. Tsirkin <mst@redhat.com>
2013-04-25vfio: Convert container->group_lock to rwsemAlex Williamson1-10/+11
All current users are writers, maintaining current mutual exclusion. This lets us add read users next. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2013-03-11VFIO: Wrapper for getting reference to vfio_deviceVijay Mohan Pandarathil1-1/+29
- Added vfio_device_get_from_dev() as wrapper to get reference to vfio_device from struct device. - Added vfio_device_data() as a wrapper to get device_data from vfio_device. Signed-off-by: Vijay Mohan Pandarathil <vijaymohan.pandarathil@hp.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2013-02-27vfio: convert to idr_alloc()Tejun Heo1-16/+1
Convert to the much saner new idr interface. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-14vfio: whitelist pcieportAlex Williamson1-1/+1
pcieport does nice things like manage AER and we know it doesn't do DMA or expose any user accessible devices on the host. It also keeps the Memory, I/O, and Busmaster bits enabled, which is pretty handy when trying to use anyting below it. Devices owned by pcieport cannot be given to users via vfio, but we can tolerate them not being owned by vfio-pci. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2013-02-14vfio: Protect vfio_dev_present against device_delAlex Williamson1-21/+12
vfio_dev_present is meant to give us a wait_event callback so that we can block removing a device from vfio until it becomes unused. The root of this check depends on being able to get the iommu group from the device. Unfortunately if the BUS_NOTIFY_DEL_DEVICE notifier has fired then the device-group reference is no longer searchable and we fail the lookup. We don't need to go to such extents for this though. We have a reference to the device, from which we can acquire a reference to the group. We can then use the group reference to search for the device and properly block removal. 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-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-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: Type1 IOMMU implementationAlex Williamson1-0/+7
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 Williamson1-0/+1413
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-26 11:02:35 +0000