> From: Doug Ledford [mailto:dledf...@redhat.com]
> > I suppose that the main issue would be handling existing user memory
> mappings,
> > which cannot be just invalidated -- the user-space driver may not be aware
> of the
> > device removal and may access this memory concurrently, and we don't
> w
> From: Doug Ledford [mailto:dledf...@redhat.com]
> > I suppose that the main issue would be handling existing user memory
> mappings,
> > which cannot be just invalidated -- the user-space driver may not be aware
> of the
> > device removal and may access this memory concurrently, and we don't
>
On Tue, 2015-05-19 at 16:17 +, Liran Liss wrote:
> > From: Hefty, Sean [mailto:sean.he...@intel.com]
>
> > > these remaining resources may be device-specific.
> > > The proposed framework first of all allows a provider to indicate
> > > whether hot-removal is supported (i.e., the presence of t
On 5/19/2015 7:17 PM, Liran Liss wrote:
From: Hefty, Sean [mailto:sean.he...@intel.com]
these remaining resources may be device-specific.
The proposed framework first of all allows a provider to indicate
whether hot-removal is supported (i.e., the presence of the
'disassociate_ucontext' callba
Currently, if there is any user space application using an IB device,
it is impossible to unload the HW device driver for this device.
Similarly, if the device is hot-unplugged or reset, the device driver
hardware removal flow blocks until all user contexts are destroyed.
This patchset removes th
