> -Original Message-
> From: Alex Williamson
> Sent: 01 June 2021 15:14
> To: Thanos Makatos
> Cc: vfio-users@redhat.com; John Levon ; Swapnil
> Ingle ; linux-ker...@vger.kernel.org;
> k...@vger.kernel.org
> Subject: Re: semantics of VFIO_IOMMU_DIRTY_PAGES_FLA
(sending here as I can't find a relevant list in
http://vger.kernel.org/vger-lists.html)
I'm trying to understand the semantics of
VFIO_IOMMU_DIRTY_PAGES_FLAG_GET_BITMAP. My (very rough) understanding so far is
that once a page gets pinned then it's considered dirty and if the page is
still pi
> -Original Message-
> From: Auger Eric
> Sent: 02 October 2020 14:56
> To: Thanos Makatos ; vfio-
> us...@redhat.com
> Cc: John G Johnson
> Subject: Re: [vfio-users] location of regions
> VFIO_REGION_TYPE_MIGRATION/VFIO_REGION_SUBTYPE_MIGRATION
>
> Hi T
According to linux/include/uapi/linux/vfio.h, for a device to support migration
it must provide a VFIO capability of type VFIO_REGION_INFO_CAP_TYPE and set
.type/.subtype to VFIO_REGION_TYPE_MIGRATION/VFIO_REGION_TYPE_MIGRATION.
What confuses me is the following:
"The structure vfio_device_migrat
> Drivers that handle DMA region registration events without having to call
> vfio_pin_pages (e.g. in muser we inject the fd backing that VMA to a
> userspace
> process and then ask it to memory map that fd) aren't notified at all when
> that
> region is unmapped. Because of this, we get duplicate
Drivers that handle DMA region registration events without having to call
vfio_pin_pages (e.g. in muser we inject the fd backing that VMA to a userspace
process and then ask it to memory map that fd) aren't notified at all when that
region is unmapped. Because of this, we get duplicate/overlapping