On Mon, 19 Oct 2020 11:57:47 -0600 Alex Williamson <alex.william...@redhat.com> wrote:
> On Sun, 18 Oct 2020 02:05:03 +0530 > Kirti Wankhede <kwankh...@nvidia.com> wrote: > > > On 9/26/2020 1:50 AM, Alex Williamson wrote: > > > On Wed, 23 Sep 2020 04:54:08 +0530 > > > Kirti Wankhede <kwankh...@nvidia.com> wrote: > > >> diff --git a/include/hw/vfio/vfio-common.h > > >> b/include/hw/vfio/vfio-common.h > > >> index 25e3b1a3b90a..49c7c7a0e29a 100644 > > >> --- a/include/hw/vfio/vfio-common.h > > >> +++ b/include/hw/vfio/vfio-common.h > > >> @@ -123,6 +123,7 @@ typedef struct VFIODevice { > > >> VMChangeStateEntry *vm_state; > > >> uint32_t device_state; > > >> int vm_running; > > >> + Notifier migration_state; > > > > > > Can this live in VFIOMigration? Thanks, > > > > > > > No, callback vfio_migration_state_notifier() has notifier argument and > > to reach its corresponding device structure as below, its should be in > > VFIODevice. > > > > VFIODevice *vbasedev = container_of(notifier, VFIODevice, migration_state); > > > > An alternative would be to place migration_state within VFIOMigration, > along with a pointer back to vbasedev (like we do in VFIORegion) then > the notifier could use container_of to get the VFIOMigration structure, > from which we could get to the VFIODevice via the vbasedev pointer. > This would better compartmentalize the migration related data into a > single structure. Thanks, > > Alex +1, I think having everything in VFIOMigration would be nicer.