From nobody Sun Sep 28 17:40:18 2025 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass header.i=@intel.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1757472008; cv=none; d=zohomail.com; s=zohoarc; b=NKH1M5+qtB/oWoRm9oopFe045f2/EtqDifFm8UNqKupanwAC0b0GvtwiFt6qzBnolvW0b190ASLYFpGwhWNHb2yLx9Fx0FUZAGJ1koDW0mhEhoRHE1u9bt2NPgQ1j2nL8dDgFuY+DV8G2qdWzZZReMd0C6rh4clVp5YIiIw6How= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1757472008; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=N04iPNaFLP1vax0eKL9KloBAvyM2/IeXQIOFkzMnJvM=; b=dIgTLhhQe3hAnJTgJxH5iHxutsuLqT8JeOun2Y0A8VKKOpiV0iumF8+JKFXWFyA+nurQkkwaJy9YkSHtw4aDRn2bxf3Zvif6/hBXn589x60+q+z2Ftn8Va5lqEsYENPerIsQM+dhCLox1mjLUClzGNZDkPatfPvD+vYHMCeCg90= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1757472008370913.6004144482491; Tue, 9 Sep 2025 19:40:08 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1uwAij-00072M-CL; Tue, 09 Sep 2025 22:38:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uwAih-00071g-CC for qemu-devel@nongnu.org; Tue, 09 Sep 2025 22:38:03 -0400 Received: from mgamail.intel.com ([192.198.163.13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uwAid-0005gB-Hb for qemu-devel@nongnu.org; Tue, 09 Sep 2025 22:38:02 -0400 Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 19:37:44 -0700 Received: from unknown (HELO gnr-sp-2s-612.sh.intel.com) ([10.112.230.229]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2025 19:37:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1757471880; x=1789007880; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Zu28Wx2gkxOgWLPOk59CCYz0qv1zGQ8gGNxyBTmRFXs=; b=IehuGJcF0PW3lCW/WpZlIb+JDbsp3BnXCVI0fMwCxumqy1wgQLghOWrc 9KjzyHSAYZaty63osWuP1I7WFbLvum/OS/idZ4IEutAEdQlv1W+BN3+zI /lpVmzNOAUh1c7S1EKOfVDIXjfalO+pprHcxLPvWI2TQcveVdFFv9LygP w56MYWxtQNKb+6CmumPs4WiEvikwCYM2oKcEVMIUpnplmRXuQGkIeJfUv 4AmMDwDfmfHnWi0elO02rkcplwe78yleRBD1OXu7It/Q9ahxQMJTqSUWN doq+1KNE4Ze5FnMV/TZXt5Ls6tl4FokRjZvT3NUIWp/jrysXXZeogszON g==; X-CSE-ConnectionGUID: SncOXWMWR/eKIwpodOfpDA== X-CSE-MsgGUID: WzewmLO4SeCdxXFJamIRhQ== X-IronPort-AV: E=McAfee;i="6800,10657,11548"; a="62402809" X-IronPort-AV: E=Sophos;i="6.18,253,1751266800"; d="scan'208";a="62402809" X-CSE-ConnectionGUID: XAi2f26PQTeJ4IDTnLvINA== X-CSE-MsgGUID: nTqWyxooQhSqGBJUve8h1Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.18,253,1751266800"; d="scan'208";a="196930581" From: Zhenzhong Duan To: qemu-devel@nongnu.org Cc: alex.williamson@redhat.com, clg@redhat.com, mst@redhat.com, jasowang@redhat.com, yi.l.liu@intel.com, clement.mathieu--drif@eviden.com, eric.auger@redhat.com, joao.m.martins@oracle.com, avihaih@nvidia.com, xudong.hao@intel.com, giovanni.cabiddu@intel.com, mark.gross@intel.com, arjan.van.de.ven@intel.com, Zhenzhong Duan Subject: [PATCH 4/5] intel_iommu: Optimize unmap_bitmap during migration Date: Tue, 9 Sep 2025 22:37:00 -0400 Message-ID: <20250910023701.244356-5-zhenzhong.duan@intel.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20250910023701.244356-1-zhenzhong.duan@intel.com> References: <20250910023701.244356-1-zhenzhong.duan@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=192.198.163.13; envelope-from=zhenzhong.duan@intel.com; helo=mgamail.intel.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1757472009076116600 Content-Type: text/plain; charset="utf-8" If a VFIO device in guest switches from IOMMU domain to block domain, vtd_address_space_unmap() is called to unmap whole address space. If that happens during migration, migration fails with legacy VFIO backend as below: Status: failed (vfio_container_dma_unmap(0x561bbbd92d90, 0x100000000000, 0x= 100000000000) =3D -7 (Argument list too long)) Because legacy VFIO limits maximum bitmap size to 256MB which maps to 8TB on 4K page system, when 16TB sized UNMAP notification is sent, unmap_bitmap ioctl fails. There is no such limitation with iommufd backend, but it's still not optimal to allocate large bitmap. Optimize it by iterating over DMAMap list to unmap each range with active mapping when migration is active. If migration is not active, unmapping the whole address space in one go is optimal. Signed-off-by: Zhenzhong Duan Tested-by: Giovannio Cabiddu --- hw/i386/intel_iommu.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index 83c5e44413..6876dae727 100644 --- a/hw/i386/intel_iommu.c +++ b/hw/i386/intel_iommu.c @@ -37,6 +37,7 @@ #include "system/system.h" #include "hw/i386/apic_internal.h" #include "kvm/kvm_i386.h" +#include "migration/misc.h" #include "migration/vmstate.h" #include "trace.h" =20 @@ -4423,6 +4424,42 @@ static void vtd_dev_unset_iommu_device(PCIBus *bus, = void *opaque, int devfn) vtd_iommu_unlock(s); } =20 +/* + * Unmapping a large range in one go is not optimal during migration becau= se + * a large dirty bitmap needs to be allocated while there may be only small + * mappings, iterate over DMAMap list to unmap each range with active mapp= ing. + */ +static void vtd_address_space_unmap_in_migration(VTDAddressSpace *as, + IOMMUNotifier *n) +{ + const DMAMap *map; + const DMAMap target =3D { + .iova =3D n->start, + .size =3D n->end, + }; + IOVATree *tree =3D as->iova_tree; + + /* + * DMAMap is created during IOMMU page table sync, it's either 4KB or = huge + * page size and always a power of 2 in size. So the range of DMAMap c= ould + * be used for UNMAP notification directly. + */ + while ((map =3D iova_tree_find(tree, &target))) { + IOMMUTLBEvent event; + + event.type =3D IOMMU_NOTIFIER_UNMAP; + event.entry.iova =3D map->iova; + event.entry.addr_mask =3D map->size; + event.entry.target_as =3D &address_space_memory; + event.entry.perm =3D IOMMU_NONE; + /* This field is meaningless for unmap */ + event.entry.translated_addr =3D 0; + memory_region_notify_iommu_one(n, &event); + + iova_tree_remove(tree, *map); + } +} + /* Unmap the whole range in the notifier's scope. */ static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n) { @@ -4432,6 +4469,11 @@ static void vtd_address_space_unmap(VTDAddressSpace = *as, IOMMUNotifier *n) IntelIOMMUState *s =3D as->iommu_state; DMAMap map; =20 + if (migration_is_running()) { + vtd_address_space_unmap_in_migration(as, n); + return; + } + /* * Note: all the codes in this function has a assumption that IOVA * bits are no more than VTD_MGAW bits (which is restricted by --=20 2.47.1