On Thu, 29 Jun 2017 00:10:59 +0000 "Tian, Kevin" <kevin.t...@intel.com> wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Thursday, June 29, 2017 12:00 AM > > Thanks Kevin. So really it's not really a dirty bitmap, it's just a > > bitmap of pages that the device has access to and may have dirtied. > > Don't we have this more generally in the vfio type1 IOMMU backend? For > > a mediated device, we know all the pages that the vendor driver has > > asked to be pinned. Should we perhaps make this interface on the vfio > > container rather than the device? Any mediated device can provide this > > level of detail without specific vendor support. If we had DMA page > > faulting, this would be the natural place to put it as well, so maybe > > we should design the interface there to support everything similarly. > > Thanks, > > > > That's a nice idea. Just two comments: > > 1) If some mediated device has its own way to construct true dirty > bitmap (not thru DMA page faulting), the interface is better designed > to allow that flexibility. Maybe an optional callback if not registered > then use common type1 IOMMU logic otherwise prefers to vendor > specific callback I'm not sure what that looks like, but I agree with the idea. Could the pages that type1 knows about every be anything other than a superset of the dirty pages? Perhaps a device ioctl to flush unused mappings would be sufficient. > 2) If there could be multiple mediated devices from different vendors > in same container while not all mediated devices support live migration, > would container-level interface impose some limitation? Dirty page logging is only one small part of migration, each migrate-able device would still need to provide a device-level interface to save/restore state. The migration would fail when we get to the device(s) that don't provide that. Thanks, Alex
