From patchwork Tue Dec 17 17:10:45 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kirti Wankhede X-Patchwork-Id: 11298331 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0F061139A for ; Tue, 17 Dec 2019 17:40:56 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D9489206D8 for ; Tue, 17 Dec 2019 17:40:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="md1pzdm7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D9489206D8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Received: from localhost ([::1]:44378 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihGq5-00034g-OL for patchwork-qemu-devel@patchwork.kernel.org; Tue, 17 Dec 2019 12:40:54 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49687) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihGox-0001RG-Mq for qemu-devel@nongnu.org; Tue, 17 Dec 2019 12:39:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihGov-0000Mi-FU for qemu-devel@nongnu.org; Tue, 17 Dec 2019 12:39:42 -0500 Received: from hqnvemgate24.nvidia.com ([216.228.121.143]:13142) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ihGov-0000Hz-4a for qemu-devel@nongnu.org; Tue, 17 Dec 2019 12:39:41 -0500 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Tue, 17 Dec 2019 09:39:10 -0800 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Tue, 17 Dec 2019 09:39:38 -0800 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Tue, 17 Dec 2019 09:39:38 -0800 Received: from HQMAIL101.nvidia.com (172.20.187.10) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Dec 2019 17:39:38 +0000 Received: from kwankhede-dev.nvidia.com (10.124.1.5) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 17 Dec 2019 17:39:31 +0000 From: Kirti Wankhede To: , Subject: [PATCH v11 Kernel 0/6] KABIs to support migration for VFIO devices Date: Tue, 17 Dec 2019 22:40:45 +0530 Message-ID: <1576602651-15430-1-git-send-email-kwankhede@nvidia.com> X-Mailer: git-send-email 2.7.0 X-NVConfidentiality: public MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1576604351; bh=lODMYvYoFy4OfIDsqlxu0jkNIpukWEEJpd2Wszajnyo=; h=X-PGP-Universal:From:To:CC:Subject:Date:Message-ID:X-Mailer: X-NVConfidentiality:MIME-Version:Content-Type; b=md1pzdm7+Lv/wrAU0I5DS7qkfTjRZV8eKCqN/KaN+hs8D4ZtKKbUicNptF+j7m3lF dw9XYYWArSm1/02If/qZHavMehTtMBzXGChNDpMYfC99yEO3X5bKpKe1DHHd4JSuTx eBOfryizSmHdQbE/dAWa/NzONK8Y7TudafrpKSTUwouiCkY0HOfbn024Ac503MngM4 T3gH7iU/O/pXTQHPDu4UDcyRcDJWmFvwCqKB62kEWkQD3CGop1Q/w/feV2pXn+Q2uf sQz1m+6qkFrF/5XvjZ9Zfp41Yha/R+gE6bKuYo2jK3I9SvVhYyqWCFbPayrQFk8NRi nEVRs8YVwQvqg== X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 216.228.121.143 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Zhengxiao.zx@Alibaba-inc.com, kevin.tian@intel.com, yi.l.liu@intel.com, yan.y.zhao@intel.com, kvm@vger.kernel.org, eskultet@redhat.com, ziye.yang@intel.com, qemu-devel@nongnu.org, cohuck@redhat.com, shuangtai.tst@alibaba-inc.com, dgilbert@redhat.com, zhi.a.wang@intel.com, mlevitsk@redhat.com, pasic@linux.ibm.com, aik@ozlabs.ru, Kirti Wankhede , eauger@redhat.com, felipe@nutanix.com, jonathan.davies@nutanix.com, changpeng.liu@intel.com, Ken.Xue@amd.com Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" Hi, This patch set adds: * New IOCTL VFIO_IOMMU_DIRTY_PAGES to get dirty pages bitmap with respect to IOMMU container rather than per device. All pages pinned by vendor driver through vfio_pin_pages external API has to be marked as dirty during migration. When IOMMU capable device is present in the container and all pages are pinned and mapped, then all pages are marked dirty. When there are CPU writes, CPU dirty page tracking can identify dirtied pages, but any page pinned by vendor driver can also be written by device. As of now there is no device which has hardware support for dirty page tracking. So all pages which are pinned should be considered as dirty. This ioctl is also used to start dirty pages tracking for unpinned pages while migration is active and device is running. These tracked unpinned pages information is cleaned on dirty bitmap read from VFIO application or if migration is failed or cancelled and unpinned pages tracking is stopped. * Updated IOCTL VFIO_IOMMU_UNMAP_DMA to get dirty pages bitmap before unmapping IO virtual address range. With vIOMMU, during pre-copy phase of migration, while CPUs are still running, IO virtual address unmap can happen while device still keeping reference of guest pfns. Those pages should be reported as dirty before unmap, so that VFIO user space application can copy content of those pages from source to destination. * Patch 6 is proposed change to detect if IOMMU capable device driver is smart to report pages to be marked dirty by pinning pages using vfio_pin_pages() API. Yet TODO: Since there is no device which has hardware support for system memmory dirty bitmap tracking, right now there is no other API from vendor driver to VFIO IOMMU module to report dirty pages. In future, when such hardware support will be implemented, an API will be required such that vendor driver could report dirty pages to VFIO module during migration phases. Adding revision history from previous QEMU patch set to understand KABI changes done till now v10 -> v11 - Fix pin pages API to free vpfn if it is marked as unpinned tracking page. - Added proposal to detect if IOMMU capable device calls external pin pages API to mark pages dirty. - Nit picks from v10 reviews v9 -> v10: - Updated existing VFIO_IOMMU_UNMAP_DMA ioctl to get dirty pages bitmap during unmap while migration is active - Added flag in VFIO_IOMMU_GET_INFO to indicate driver support dirty page tracking. - If iommu_mapped, mark all pages dirty. - Added unpinned pages tracking while migration is active. - Updated comments for migration device state structure with bit combination table and state transition details. v8 -> v9: - Split patch set in 2 sets, Kernel and QEMU. - Dirty pages bitmap is queried from IOMMU container rather than from vendor driver for per device. Added 2 ioctls to achieve this. v7 -> v8: - Updated comments for KABI - Added BAR address validation check during PCI device's config space load as suggested by Dr. David Alan Gilbert. - Changed vfio_migration_set_state() to set or clear device state flags. - Some nit fixes. v6 -> v7: - Fix build failures. v5 -> v6: - Fix build failure. v4 -> v5: - Added decriptive comment about the sequence of access of members of structure vfio_device_migration_info to be followed based on Alex's suggestion - Updated get dirty pages sequence. - As per Cornelia Huck's suggestion, added callbacks to VFIODeviceOps to get_object, save_config and load_config. - Fixed multiple nit picks. - Tested live migration with multiple vfio device assigned to a VM. v3 -> v4: - Added one more bit for _RESUMING flag to be set explicitly. - data_offset field is read-only for user space application. - data_size is read for every iteration before reading data from migration, that is removed assumption that data will be till end of migration region. - If vendor driver supports mappable sparsed region, map those region during setup state of save/load, similarly unmap those from cleanup routines. - Handles race condition that causes data corruption in migration region during save device state by adding mutex and serialiaing save_buffer and get_dirty_pages routines. - Skip called get_dirty_pages routine for mapped MMIO region of device. - Added trace events. - Split into multiple functional patches. v2 -> v3: - Removed enum of VFIO device states. Defined VFIO device state with 2 bits. - Re-structured vfio_device_migration_info to keep it minimal and defined action on read and write access on its members. v1 -> v2: - Defined MIGRATION region type and sub-type which should be used with region type capability. - Re-structured vfio_device_migration_info. This structure will be placed at 0th offset of migration region. - Replaced ioctl with read/write for trapped part of migration region. - Added both type of access support, trapped or mmapped, for data section of the region. - Moved PCI device functions to pci file. - Added iteration to get dirty page bitmap until bitmap for all requested pages are copied. Thanks, Kirti Kirti Wankhede (6): vfio: KABI for migration interface for device state vfio iommu: Add ioctl definition for dirty pages tracking. vfio iommu: Implementation of ioctl to for dirty pages tracking. vfio iommu: Update UNMAP_DMA ioctl to get dirty bitmap before unmap vfio iommu: Adds flag to indicate dirty pages tracking capability support vfio: Selective dirty page tracking if IOMMU backed device pins pages drivers/vfio/vfio.c | 33 ++++ drivers/vfio/vfio_iommu_type1.c | 324 +++++++++++++++++++++++++++++++++++++--- include/linux/vfio.h | 3 +- include/uapi/linux/vfio.h | 247 +++++++++++++++++++++++++++++- 4 files changed, 587 insertions(+), 20 deletions(-)