> From: Eric Farman > Sent: Friday, September 9, 2022 4:51 AM > > On Thu, 2022-09-08 at 07:19 +0000, Tian, Kevin wrote: > > ping @Eric Farman. > > > > ccw is the only tricky player in this series. Please help take a look > > in case of > > any oversight here. > > Apologies, I had started looking at v1 before I left on holiday, and > only returned today. > > > > > > From: Tian, Kevin <kevin.tian@xxxxxxxxx> > > > Sent: Thursday, September 1, 2022 10:38 PM > > > > > > ccw is the only exception which cannot use vfio_alloc_device() > > > because > > > its private device structure is designed to serve both mdev and > > > parent. > > > Life cycle of the parent is managed by css_driver so > > > vfio_ccw_private > > > must be allocated/freed in css_driver probe/remove path instead of > > > conforming to vfio core life cycle for mdev. > > > > > > Given that use a wait/completion scheme so the mdev remove path > > > waits > > > after vfio_put_device() until receiving a completion notification > > > from > > > @release. The completion indicates that all active references on > > > vfio_device have been released. > > > > > > After that point although free of vfio_ccw_private is delayed to > > > css_driver it's at least guaranteed to have no parallel reference > > > on > > > released vfio device part from other code paths. > > > > > > memset() in @probe is removed. vfio_device is either already > > > cleared > > > when probed for the first time or cleared in @release from last > > > probe. > > > > > > The right fix is to introduce separate structures for mdev and > > > parent, > > > but this won't happen in short term per prior discussions. > > I did start looking at the above, while the mdev series is outstanding. > Will try to get back to that sooner rather than later, but for the > purposes of this series this patch looks/works fine to me. > > Reviewed-by: Eric Farman <farman@xxxxxxxxxxxxx> > Thanks!
