Re: [PATCH 3/3] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
On Tue, May 05, 2020 at 11:12:27AM -0600, Alex Williamson wrote: > > As noted in the comment, the fault handler can simply do: > > mutex_lock(&vdev->vma_lock); > down_read(&vdev->memory_lock); > > This should be deadlock free now, so we can drop the retry handling That does look like the right direction, because the memory_lock can be done at the very end it means it doesn't need to be nested inside mmap_sem This is much cleaner! Jason
Re: [PATCH 3/3] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
On Mon, 4 May 2020 17:01:23 -0300
Jason Gunthorpe wrote:
> On Mon, May 04, 2020 at 01:35:52PM -0600, Alex Williamson wrote:
>
> > Ok, this all makes a lot more sense with memory_lock still in the
> > picture. And it looks like you're not insisting on the wait_event, we
> > can block on memory_lock so long as we don't have an ordering issue.
> > I'll see what I can do. Thanks,
>
> Right, you can block on the rwsem if it is ordered properly vs
> mmap_sem.
This is what I've come up with, please see if you agree with the logic:
void vfio_pci_zap_and_down_write_memory_lock(struct vfio_pci_device *vdev)
{
struct vfio_pci_mmap_vma *mmap_vma, *tmp;
/*
* Lock ordering:
* vma_lock is nested under mmap_sem for vm_ops callback paths.
* The memory_lock semaphore is used by both code paths calling
* into this function to zap vmas and the vm_ops.fault callback
* to protect the memory enable state of the device.
*
* When zapping vmas we need to maintain the mmap_sem => vma_lock
* ordering, which requires using vma_lock to walk vma_list to
* acquire an mm, then dropping vma_lock to get the mmap_sem and
* reacquiring vma_lock. This logic is derived from similar
* requirements in uverbs_user_mmap_disassociate().
*
* mmap_sem must always be the top-level lock when it is taken.
* Therefore we can only hold the memory_lock write lock when
* vma_list is empty, as we'd need to take mmap_sem to clear
* entries. vma_list can only be guaranteed empty when holding
* vma_lock, thus memory_lock is nested under vma_lock.
*
* This enables the vm_ops.fault callback to acquire vma_lock,
* followed by memory_lock read lock, while already holding
* mmap_sem without risk of deadlock.
*/
while (1) {
struct mm_struct *mm = NULL;
mutex_lock(&vdev->vma_lock);
while (!list_empty(&vdev->vma_list)) {
mmap_vma = list_first_entry(&vdev->vma_list,
struct vfio_pci_mmap_vma,
vma_next);
mm = mmap_vma->vma->vm_mm;
if (mmget_not_zero(mm))
break;
list_del(&mmap_vma->vma_next);
kfree(mmap_vma);
mm = NULL;
}
if (!mm)
break;
mutex_unlock(&vdev->vma_lock);
down_read(&mm->mmap_sem);
if (mmget_still_valid(mm)) {
mutex_lock(&vdev->vma_lock);
list_for_each_entry_safe(mmap_vma, tmp,
&vdev->vma_list, vma_next) {
struct vm_area_struct *vma = mmap_vma->vma;
if (vma->vm_mm != mm)
continue;
list_del(&mmap_vma->vma_next);
kfree(mmap_vma);
zap_vma_ptes(vma, vma->vm_start,
vma->vm_end - vma->vm_start);
}
mutex_unlock(&vdev->vma_lock);
}
up_read(&mm->mmap_sem);
mmput(mm);
}
down_write(&vdev->memory_lock);
mutex_unlock(&vdev->vma_lock);
}
As noted in the comment, the fault handler can simply do:
mutex_lock(&vdev->vma_lock);
down_read(&vdev->memory_lock);
This should be deadlock free now, so we can drop the retry handling
Paths needing to acquire memory_lock with vmas zapped (device reset,
memory bit *->0 transition) call this function, perform their
operation, then simply release with up_write(&vdev->memory_lock). Both
the read and write version of acquiring memory_lock can still occur
outside this function for operations that don't require flushing all
vmas or otherwise touch vma_lock or mmap_sem (ex. read/write, MSI-X
vector table access, writing *->1 to memory enable bit).
I still need to work on the bus reset path as acquiring memory_lock
write locks across multiple devices seems like it requires try-lock
behavior, which is clearly complicated, or at least messy in the above
function.
Does this seem like it's going in a reasonable direction? Thanks,
Alex
Re: [PATCH 3/3] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
On Mon, May 04, 2020 at 01:35:52PM -0600, Alex Williamson wrote: > Ok, this all makes a lot more sense with memory_lock still in the > picture. And it looks like you're not insisting on the wait_event, we > can block on memory_lock so long as we don't have an ordering issue. > I'll see what I can do. Thanks, Right, you can block on the rwsem if it is ordered properly vs mmap_sem. Jason
Re: [PATCH 3/3] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
On Mon, 4 May 2020 15:44:36 -0300
Jason Gunthorpe wrote:
> On Mon, May 04, 2020 at 12:26:43PM -0600, Alex Williamson wrote:
> > On Fri, 1 May 2020 20:48:49 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Fri, May 01, 2020 at 03:39:30PM -0600, Alex Williamson wrote:
> > >
> > > > static int vfio_pci_add_vma(struct vfio_pci_device *vdev,
> > > > struct vm_area_struct *vma)
> > > > {
> > > > @@ -1346,15 +1450,49 @@ static vm_fault_t vfio_pci_mmap_fault(struct
> > > > vm_fault *vmf)
> > > > {
> > > > struct vm_area_struct *vma = vmf->vma;
> > > > struct vfio_pci_device *vdev = vma->vm_private_data;
> > > > + vm_fault_t ret = VM_FAULT_NOPAGE;
> > > >
> > > > - if (vfio_pci_add_vma(vdev, vma))
> > > > - return VM_FAULT_OOM;
> > > > + /*
> > > > +* Zap callers hold memory_lock and acquire mmap_sem, we hold
> > > > +* mmap_sem and need to acquire memory_lock to avoid races with
> > > > +* memory bit settings. Release mmap_sem, wait, and retry, or
> > > > fail.
> > > > +*/
> > > > + if (unlikely(!down_read_trylock(&vdev->memory_lock))) {
> > > > + if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
> > > > + if (vmf->flags & FAULT_FLAG_RETRY_NOWAIT)
> > > > + return VM_FAULT_RETRY;
> > > > +
> > > > + up_read(&vma->vm_mm->mmap_sem);
> > > > +
> > > > + if (vmf->flags & FAULT_FLAG_KILLABLE) {
> > > > + if
> > > > (!down_read_killable(&vdev->memory_lock))
> > > > + up_read(&vdev->memory_lock);
> > > > + } else {
> > > > + down_read(&vdev->memory_lock);
> > > > + up_read(&vdev->memory_lock);
> > > > + }
> > > > + return VM_FAULT_RETRY;
> > > > + }
> > > > + return VM_FAULT_SIGBUS;
> > > > + }
> > >
> > > So, why have the wait? It isn't reliable - if this gets faulted from a
> > > call site that can't handle retry then it will SIGBUS anyhow?
> >
> > Do such call sites exist? My assumption was that half of the branch
> > was unlikely to ever occur.
>
> hmm_range_fault() for instance doesn't set ALLOW_RETRY, I assume there
> are enough other case to care about, but am not so sure
>
> > > The weird use of a rwsem as a completion suggest that perhaps using
> > > wait_event might improve things:
> > >
> > > disable:
> > > // Clean out the vma list with zap, then:
> > >
> > > down_read(mm->mmap_sem)
> >
> > I assume this is simplifying the dance we do in zapping to first take
> > vma_lock in order to walk vma_list, to find a vma from which we can
> > acquire the mm, drop vma_lock, get mmap_sem, then re-get vma_lock
> > below.
>
> No, that has to stay..
Sorry, I stated that unclearly, I'm assuming we keep that and it's been
omitted from this pseudo code for simplicity.
> > Also accounting that vma_list might be empty and we might need
> > to drop and re-acquire vma_lock to get to another mm, so we really
> > probably want to set pause_faults at the start rather than at the end.
>
> New vmas should not created/faulted while vma_lock is held, so the
> order shouldn't matter..
Technically that's true, but if vfio_pci_zap_mmap_vmas() drops vma_lock
to go back and get another mm, then vm_ops.fault() could get another
vma into the list while we're trying to zap and clear them all. The
result is the same, but we might be doing unnecessary work versus
holding off the fault from the start.
> > > mutex_lock(vma_lock);
> > > list_for_each_entry_safe()
> > > // zap and remove all vmas
> > >
> > > pause_faults = true;
> > > mutex_write(vma_lock);
> > >
> > > fault:
> > > // Already have down_read(mmap_sem)
> > > mutex_lock(vma_lock);
> > > while (pause_faults) {
> > > mutex_unlock(vma_lock)
> > > wait_event(..., !pause_faults)
> > > mutex_lock(vma_lock)
> > > }
> >
> > Nit, we need to test the memory enable bit setting somewhere under this
> > lock since it seems to be the only thing protecting it now.
>
> I was thinking you'd keep the same locking for the memory enable bit,
> the pause_faults is a shadow of that bit with locking connected to
> vma_lock..
Oh! I totally did not get that!
> > > list_add()
> > > remap_pfn()
> > > mutex_unlock(vma_lock)
> >
> > The read and write file ops would need similar mechanisms.
>
> Keep using the rwsem?
>
> > > enable:
> > > pause_faults = false
> > > wake_event()
> >
> > Hmm, vma_lock was dropped above and not re-acquired here.
>
> I was thinking this would be under a continous rwlock
>
> > I'm not sure if it was an oversight that pause_faults was not tested
> > in the disable path, but this combination appears to lead to
> > concurrent writers
Re: [PATCH 3/3] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
On Mon, May 04, 2020 at 12:26:43PM -0600, Alex Williamson wrote:
> On Fri, 1 May 2020 20:48:49 -0300
> Jason Gunthorpe wrote:
>
> > On Fri, May 01, 2020 at 03:39:30PM -0600, Alex Williamson wrote:
> >
> > > static int vfio_pci_add_vma(struct vfio_pci_device *vdev,
> > > struct vm_area_struct *vma)
> > > {
> > > @@ -1346,15 +1450,49 @@ static vm_fault_t vfio_pci_mmap_fault(struct
> > > vm_fault *vmf)
> > > {
> > > struct vm_area_struct *vma = vmf->vma;
> > > struct vfio_pci_device *vdev = vma->vm_private_data;
> > > + vm_fault_t ret = VM_FAULT_NOPAGE;
> > >
> > > - if (vfio_pci_add_vma(vdev, vma))
> > > - return VM_FAULT_OOM;
> > > + /*
> > > + * Zap callers hold memory_lock and acquire mmap_sem, we hold
> > > + * mmap_sem and need to acquire memory_lock to avoid races with
> > > + * memory bit settings. Release mmap_sem, wait, and retry, or fail.
> > > + */
> > > + if (unlikely(!down_read_trylock(&vdev->memory_lock))) {
> > > + if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
> > > + if (vmf->flags & FAULT_FLAG_RETRY_NOWAIT)
> > > + return VM_FAULT_RETRY;
> > > +
> > > + up_read(&vma->vm_mm->mmap_sem);
> > > +
> > > + if (vmf->flags & FAULT_FLAG_KILLABLE) {
> > > + if (!down_read_killable(&vdev->memory_lock))
> > > + up_read(&vdev->memory_lock);
> > > + } else {
> > > + down_read(&vdev->memory_lock);
> > > + up_read(&vdev->memory_lock);
> > > + }
> > > + return VM_FAULT_RETRY;
> > > + }
> > > + return VM_FAULT_SIGBUS;
> > > + }
> >
> > So, why have the wait? It isn't reliable - if this gets faulted from a
> > call site that can't handle retry then it will SIGBUS anyhow?
>
> Do such call sites exist? My assumption was that half of the branch
> was unlikely to ever occur.
hmm_range_fault() for instance doesn't set ALLOW_RETRY, I assume there
are enough other case to care about, but am not so sure
> > The weird use of a rwsem as a completion suggest that perhaps using
> > wait_event might improve things:
> >
> > disable:
> > // Clean out the vma list with zap, then:
> >
> > down_read(mm->mmap_sem)
>
> I assume this is simplifying the dance we do in zapping to first take
> vma_lock in order to walk vma_list, to find a vma from which we can
> acquire the mm, drop vma_lock, get mmap_sem, then re-get vma_lock
> below.
No, that has to stay..
> Also accounting that vma_list might be empty and we might need
> to drop and re-acquire vma_lock to get to another mm, so we really
> probably want to set pause_faults at the start rather than at the end.
New vmas should not created/faulted while vma_lock is held, so the
order shouldn't matter..
> > mutex_lock(vma_lock);
> > list_for_each_entry_safe()
> > // zap and remove all vmas
> >
> > pause_faults = true;
> > mutex_write(vma_lock);
> >
> > fault:
> > // Already have down_read(mmap_sem)
> > mutex_lock(vma_lock);
> > while (pause_faults) {
> > mutex_unlock(vma_lock)
> > wait_event(..., !pause_faults)
> > mutex_lock(vma_lock)
> > }
>
> Nit, we need to test the memory enable bit setting somewhere under this
> lock since it seems to be the only thing protecting it now.
I was thinking you'd keep the same locking for the memory enable bit,
the pause_faults is a shadow of that bit with locking connected to
vma_lock..
> > list_add()
> > remap_pfn()
> > mutex_unlock(vma_lock)
>
> The read and write file ops would need similar mechanisms.
Keep using the rwsem?
> > enable:
> > pause_faults = false
> > wake_event()
>
> Hmm, vma_lock was dropped above and not re-acquired here.
I was thinking this would be under a continous rwlock
> I'm not sure if it was an oversight that pause_faults was not tested
> in the disable path, but this combination appears to lead to
> concurrent writers and serialized readers??
? pause_faults only exists to prevent the vm_ops fault callback from
progressing to a fault. I don't think any concurrancy is lost
> > The only requirement here is that while inside the write side of
> > memory_lock you cannot touch user pages (ie no copy_from_user/etc)
>
> I'm lost at this statement, I can only figure the above works if we
> remove memory_lock. Are you referring to a different lock? Thanks,
No
This is just an approach to avoid the ABBA deadlock problem when using
a rwsem by using a looser form of lock combined witih the already
correctly nested vma_lock.
Stated another way, you can keep the existing memory_lock as is, if it
is structured like this:
disable:
down_read(mmap_sem)
mutex_lock(vma_lock)
list_for_each_entry_safe()
// zap and remove all vmas
down_write(memory_lock) // Now inside vma_lock!
mutex_unlock(vma_lock)
up_read(mmap_sem
[ do the existing stuff under memory_lock ]
Re: [PATCH 3/3] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
On Fri, 1 May 2020 20:48:49 -0300
Jason Gunthorpe wrote:
> On Fri, May 01, 2020 at 03:39:30PM -0600, Alex Williamson wrote:
>
> > static int vfio_pci_add_vma(struct vfio_pci_device *vdev,
> > struct vm_area_struct *vma)
> > {
> > @@ -1346,15 +1450,49 @@ static vm_fault_t vfio_pci_mmap_fault(struct
> > vm_fault *vmf)
> > {
> > struct vm_area_struct *vma = vmf->vma;
> > struct vfio_pci_device *vdev = vma->vm_private_data;
> > + vm_fault_t ret = VM_FAULT_NOPAGE;
> >
> > - if (vfio_pci_add_vma(vdev, vma))
> > - return VM_FAULT_OOM;
> > + /*
> > +* Zap callers hold memory_lock and acquire mmap_sem, we hold
> > +* mmap_sem and need to acquire memory_lock to avoid races with
> > +* memory bit settings. Release mmap_sem, wait, and retry, or fail.
> > +*/
> > + if (unlikely(!down_read_trylock(&vdev->memory_lock))) {
> > + if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
> > + if (vmf->flags & FAULT_FLAG_RETRY_NOWAIT)
> > + return VM_FAULT_RETRY;
> > +
> > + up_read(&vma->vm_mm->mmap_sem);
> > +
> > + if (vmf->flags & FAULT_FLAG_KILLABLE) {
> > + if (!down_read_killable(&vdev->memory_lock))
> > + up_read(&vdev->memory_lock);
> > + } else {
> > + down_read(&vdev->memory_lock);
> > + up_read(&vdev->memory_lock);
> > + }
> > + return VM_FAULT_RETRY;
> > + }
> > + return VM_FAULT_SIGBUS;
> > + }
>
> So, why have the wait? It isn't reliable - if this gets faulted from a
> call site that can't handle retry then it will SIGBUS anyhow?
Do such call sites exist? My assumption was that half of the branch
was unlikely to ever occur.
> The weird use of a rwsem as a completion suggest that perhaps using
> wait_event might improve things:
>
> disable:
> // Clean out the vma list with zap, then:
>
> down_read(mm->mmap_sem)
I assume this is simplifying the dance we do in zapping to first take
vma_lock in order to walk vma_list, to find a vma from which we can
acquire the mm, drop vma_lock, get mmap_sem, then re-get vma_lock
below. Also accounting that vma_list might be empty and we might need
to drop and re-acquire vma_lock to get to another mm, so we really
probably want to set pause_faults at the start rather than at the end.
> mutex_lock(vma_lock);
> list_for_each_entry_safe()
> // zap and remove all vmas
>
> pause_faults = true;
> mutex_write(vma_lock);
>
> fault:
> // Already have down_read(mmap_sem)
> mutex_lock(vma_lock);
> while (pause_faults) {
> mutex_unlock(vma_lock)
> wait_event(..., !pause_faults)
> mutex_lock(vma_lock)
> }
Nit, we need to test the memory enable bit setting somewhere under this
lock since it seems to be the only thing protecting it now.
> list_add()
> remap_pfn()
> mutex_unlock(vma_lock)
The read and write file ops would need similar mechanisms.
> enable:
> pause_faults = false
> wake_event()
Hmm, vma_lock was dropped above and not re-acquired here. I'm not sure
if it was an oversight that pause_faults was not tested in the disable
path, but this combination appears to lead to concurrent writers and
serialized readers??
So yeah, this might resolve a theoretical sigbus if we can't retry to
get the memory_lock ordering correct, but we also lose the concurrency
that memory_lock provided us.
>
> The only requirement here is that while inside the write side of
> memory_lock you cannot touch user pages (ie no copy_from_user/etc)
I'm lost at this statement, I can only figure the above works if we
remove memory_lock. Are you referring to a different lock? Thanks,
Alex
Re: [PATCH 3/3] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
On Fri, May 01, 2020 at 03:39:30PM -0600, Alex Williamson wrote:
> static int vfio_pci_add_vma(struct vfio_pci_device *vdev,
> struct vm_area_struct *vma)
> {
> @@ -1346,15 +1450,49 @@ static vm_fault_t vfio_pci_mmap_fault(struct vm_fault
> *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct vfio_pci_device *vdev = vma->vm_private_data;
> + vm_fault_t ret = VM_FAULT_NOPAGE;
>
> - if (vfio_pci_add_vma(vdev, vma))
> - return VM_FAULT_OOM;
> + /*
> + * Zap callers hold memory_lock and acquire mmap_sem, we hold
> + * mmap_sem and need to acquire memory_lock to avoid races with
> + * memory bit settings. Release mmap_sem, wait, and retry, or fail.
> + */
> + if (unlikely(!down_read_trylock(&vdev->memory_lock))) {
> + if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
> + if (vmf->flags & FAULT_FLAG_RETRY_NOWAIT)
> + return VM_FAULT_RETRY;
> +
> + up_read(&vma->vm_mm->mmap_sem);
> +
> + if (vmf->flags & FAULT_FLAG_KILLABLE) {
> + if (!down_read_killable(&vdev->memory_lock))
> + up_read(&vdev->memory_lock);
> + } else {
> + down_read(&vdev->memory_lock);
> + up_read(&vdev->memory_lock);
> + }
> + return VM_FAULT_RETRY;
> + }
> + return VM_FAULT_SIGBUS;
> + }
So, why have the wait? It isn't reliable - if this gets faulted from a
call site that can't handle retry then it will SIGBUS anyhow?
The weird use of a rwsem as a completion suggest that perhaps using
wait_event might improve things:
disable:
// Clean out the vma list with zap, then:
down_read(mm->mmap_sem)
mutex_lock(vma_lock);
list_for_each_entry_safe()
// zap and remove all vmas
pause_faults = true;
mutex_write(vma_lock);
fault:
// Already have down_read(mmap_sem)
mutex_lock(vma_lock);
while (pause_faults) {
mutex_unlock(vma_lock)
wait_event(..., !pause_faults)
mutex_lock(vma_lock)
}
list_add()
remap_pfn()
mutex_unlock(vma_lock)
enable:
pause_faults = false
wake_event()
The only requirement here is that while inside the write side of
memory_lock you cannot touch user pages (ie no copy_from_user/etc)
Jason
[PATCH 3/3] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
Accessing the disabled memory space of a PCI device would typically
result in a master abort response on conventional PCI, or an
unsupported request on PCI express. The user would generally see
these as a -1 response for the read return data and the write would be
silently discarded, possibly with an uncorrected, non-fatal AER error
triggered on the host. Some systems however take it upon themselves
to bring down the entire system when they see something that might
indicate a loss of data, such as this discarded write to a disabled
memory space.
To avoid this, we want to try to block the user from accessing memory
spaces while they're disabled. We start with a semaphore around the
memory enable bit, where writers modify the memory enable state and
must be serialized, while readers make use of the memory region and
can access in parallel. Writers include both direct manipulation via
the command register, as well as any reset path where the internal
mechanics of the reset may both explicitly and implicitly disable
memory access, and manipulation of the MSI-X configuration, where the
MSI-X vector table resides in MMIO space of the device. Readers
include the read and write file ops to access the vfio device fd
offsets as well as memory mapped access. In the latter case, we make
use of our new vma list support to zap, or invalidate, those memory
mappings in order to force them to be faulted back in on access.
Our semaphore usage will stall user access to MMIO spaces across
internal operations like reset, but the user might experience new
behavior when trying to access the MMIO space while disabled via the
PCI command register. Access via read or write while disabled will
return -EIO and access via memory maps will result in a SIGBUS. This
is expected to be compatible with known use cases and potentially
provides better error handling capabilities than present in the
hardware, while avoiding the more readily accessible and severe
platform error responses that might otherwise occur.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci.c | 200 ---
drivers/vfio/pci/vfio_pci_config.c | 31 +
drivers/vfio/pci/vfio_pci_intrs.c | 18 +++
drivers/vfio/pci/vfio_pci_private.h |4 +
drivers/vfio/pci/vfio_pci_rdwr.c| 12 ++
5 files changed, 246 insertions(+), 19 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index da2fef666d9c..ce2bb3e62b18 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "vfio_pci_private.h"
@@ -184,6 +185,7 @@ static void vfio_pci_probe_mmaps(struct vfio_pci_device
*vdev)
static void vfio_pci_try_bus_reset(struct vfio_pci_device *vdev);
static void vfio_pci_disable(struct vfio_pci_device *vdev);
+static int vfio_pci_lock_mem(struct pci_dev *pdev, void *data);
/*
* INTx masking requires the ability to disable INTx signaling via PCI_COMMAND
@@ -736,6 +738,12 @@ int vfio_pci_register_dev_region(struct vfio_pci_device
*vdev,
return 0;
}
+struct vfio_devices {
+ struct vfio_device **devices;
+ int cur_index;
+ int max_index;
+};
+
static long vfio_pci_ioctl(void *device_data,
unsigned int cmd, unsigned long arg)
{
@@ -984,8 +992,17 @@ static long vfio_pci_ioctl(void *device_data,
return ret;
} else if (cmd == VFIO_DEVICE_RESET) {
- return vdev->reset_works ?
- pci_try_reset_function(vdev->pdev) : -EINVAL;
+ int ret;
+
+ if (!vdev->reset_works)
+ return -EINVAL;
+
+ down_write(&vdev->memory_lock);
+ vfio_pci_zap_mmap_vmas(vdev);
+ ret = pci_try_reset_function(vdev->pdev);
+ up_write(&vdev->memory_lock);
+
+ return ret;
} else if (cmd == VFIO_DEVICE_GET_PCI_HOT_RESET_INFO) {
struct vfio_pci_hot_reset_info hdr;
@@ -1065,6 +1082,7 @@ static long vfio_pci_ioctl(void *device_data,
int32_t *group_fds;
struct vfio_pci_group_entry *groups;
struct vfio_pci_group_info info;
+ struct vfio_devices devs = { .cur_index = 0 };
bool slot = false;
int i, count = 0, ret = 0;
@@ -1153,11 +1171,39 @@ static long vfio_pci_ioctl(void *device_data,
ret = vfio_pci_for_each_slot_or_bus(vdev->pdev,
vfio_pci_validate_devs,
&info, slot);
- if (!ret)
- /* User has access, do the reset */
- ret = pci_reset_bus(vdev->pdev);
+ if (ret)
+ goto hot_reset_release;
+
+ devs.max_index = count;
+ devs.devices = kcalloc(count
