From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CCE8727B50F for ; Mon, 23 Mar 2026 20:28:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774297735; cv=none; b=IOWkyQBmZQJWQdomg639basz3r/L5eWpz/UVwQuGOWr6g6kBTcblc3WZNjpy/C96B3ZzlfKU8gjLg6BOh7gu1khiI5oZ8PGAn89RJ1hfNhpALaBgD9sIhfwrtQBf7l4+rpoDBRS7PruAaBWMyb23qy6JDMzkb94w0xQCq+5vThg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774297735; c=relaxed/simple; bh=Z+0+3TcrMrU5Ujk1sHPJMlRXC0Eeq9rMNfbNi+xXmqk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jhARZzhK0DGErGNp8LeHGearVHLFk0cj1maSHOE1R7/GA5V87pIXZwDUcf7Hdw6PvtRGYi1IpRroOvQ/21FFICasH9GcHndB/qbZyfkOQ8TMCBoBHak/jZIT3EZ/87ZvggO7F+2z2WbkSqmT+TOCMY0oN+xNSQ4c1ptZw9Mvuw4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Xyffs18T; arc=none smtp.client-ip=209.85.214.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Xyffs18T" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2b052562254so26845ad.0 for ; Mon, 23 Mar 2026 13:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774297733; x=1774902533; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=EVB+M1ARpuKmS3d+ozVws2Lc23aSqaEdxwdXJm81KT0=; b=Xyffs18TC2Uen/qMApcnLK9HlHAKscrz6nQJ8bGV7JxGsL6mqpDw3XMRQHPgizM1sP AoeJddBf7PSQOjEX/ZJ7wZedLRGWfV/uiTprPy6C2tJFQ9NNVprmjUE6XND+NaiyKbZj Zpl4dx4jzgkB5EeQnlp85zLYbJXw3PkY6zfR2EJhVzdP34njcpxICduOrstB2Bc1PIEM jhtgyxmPXvsbPdvzJF3wqUgetNqR4jGH5/NSYYCajV6FKm6ON2QvfqreNloNZcm3QgiH ulDR1+gngZr6n5KrIWtB+6P0LA4cGpjjz430ATgpazMZf+ecXeUwtArgZ+pw6OiYa9/d vWNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774297733; x=1774902533; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EVB+M1ARpuKmS3d+ozVws2Lc23aSqaEdxwdXJm81KT0=; b=gtl4lYeqv801VTzlZ+M+McP5etMmI8LR2AeRmtuTrMOZXXTcbaQ8qNxa1ssdo9L0Cg 5TgVhPOtI8eYtUvAXbzEgR7Pxf7zidy6/8NGmRk56TrO5uwttW+IVz2aDgh2U++86vnz GIqTyQ6vV6kztIguFt6HrvR1ZfGhowLtmY2FeBjlo2eEmC7/fGW5eoXE9oh4bP8gzUFD AMyCML+7k0S8emaO3rUew9H50qqkGRF9POBrsSgOIlCoDES50ZlCgf483UGTpaJC3k5n F0NDANvwi5nHxdJiVEpxv38h5h1IgF+5TYyYjP1Ge2oHf7Vv9ouzwsia7Yt0K6mQVXg2 4eMQ== X-Forwarded-Encrypted: i=1; AJvYcCWvghEaQW3tq0fJKtewPU68jC9qOV8aP3TcC7FsJmTEYVjzxL/VkFT0puUKLLprtHLeg44lkZRhwZyal5c=@vger.kernel.org X-Gm-Message-State: AOJu0YzvQYA8bT39rKDYl0NNCdlDYF7wXXwPiMs11aK2Qvlg0urEgkpr U/IEQtf155EjPk6B/e4R1JcaofZ3DFHJ2rQySS8peGKlv2fhm2oPznX05bcJ11hmow== X-Gm-Gg: ATEYQzwzai7BXyRz1J1/4h+yUCfKqHB5oKXnY1NpHOvi9JSNotfql5wcCh0nmQ1pYQh 2OmO1PuXAT7EuuR9GxLX1cfLD9RdKq/v34lXdKL7QfcgdvVgS3JtjGCiqnXzikGBizgWuw2Ewli PFl7/K0AXSOeTLTquxUDneZ5uexjS+1BBegSy+HWA5YcmmIYgSAwaZYtVfjWCZSrGu3fFvMZqSY fPlikOr90N/Te888zdPzevEEWbDRDbYjdc4/W6rZinaupZUHNrFsDc3XLtmp0PTWXvwEMsEWSqc iAzribv53gSrZDm5NX9KQWS+7zv2SjdnV29LRh9t5EoTLGInJXDhM0mryDt3UYpjvjgXd7zbtIg YolOB9XnaS0bO2rlL8zY7KvhT6az6cFaymRk6CwP/jma9OEaPslTc3pEj6JMuJU/ZT5z0kucTCA D2e8BOYp84zg5aRaTaw9kQ9q+zg4ECuuTNDVnmOb440Q0TrdbWSj57pVH09g2M X-Received: by 2002:a17:902:f787:b0:2a1:3cdc:7720 with SMTP id d9443c01a7336-2b0a68a1461mr106215ad.21.1774297698546; Mon, 23 Mar 2026 13:28:18 -0700 (PDT) Received: from google.com (176.13.105.34.bc.googleusercontent.com. [34.105.13.176]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b08353e94asm118298165ad.25.2026.03.23.13.28.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Mar 2026 13:28:17 -0700 (PDT) Date: Mon, 23 Mar 2026 13:28:13 -0700 From: Vipin Sharma To: Samiullah Khawaja Cc: David Woodhouse , Lu Baolu , Joerg Roedel , Will Deacon , Jason Gunthorpe , YiFei Zhu , Robin Murphy , Kevin Tian , Alex Williamson , Shuah Khan , iommu@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Saeed Mahameed , Adithya Jayachandran , Parav Pandit , Leon Romanovsky , William Tu , Pratyush Yadav , Pasha Tatashin , David Matlack , Andrew Morton , Chris Li , Pranjal Shrivastava Subject: Re: [PATCH 11/14] iommufd-lu: Persist iommu hardware pagetables for live update Message-ID: <20260320230654.GB659132.vipinsh@google.com> References: <20260203220948.2176157-1-skhawaja@google.com> <20260203220948.2176157-12-skhawaja@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260203220948.2176157-12-skhawaja@google.com> On Tue, Feb 03, 2026 at 10:09:45PM +0000, Samiullah Khawaja wrote: > From: YiFei Zhu > > The caller is expected to mark each HWPT to be preserved with an ioctl > call, with a token that will be used in restore. At preserve time, each > HWPT's domain is then called with iommu_domain_preserve to preserve the Nit: Add () after iommu_domain_preserve, it makes easier to know this is a function. > diff --git a/drivers/iommu/iommufd/liveupdate.c b/drivers/iommu/iommufd/liveupdate.c > +static int iommufd_save_hwpts(struct iommufd_ctx *ictx, > + struct iommufd_lu *iommufd_lu, > + struct liveupdate_session *session) > +{ > + struct iommufd_hwpt_paging *hwpt, **hwpts = NULL; We should rename hwpts to something to denote that it is a list. > + struct iommu_domain_ser *domain_ser; > + struct iommufd_hwpt_lu *hwpt_lu; > + struct iommufd_object *obj; > + unsigned int nr_hwpts = 0; > + unsigned long index; > + unsigned int i; > + int rc = 0; > + > + if (iommufd_lu) { > + hwpts = kcalloc(iommufd_lu->nr_hwpts, sizeof(*hwpts), > + GFP_KERNEL); > + if (!hwpts) > + return -ENOMEM; > + } > + > + xa_lock(&ictx->objects); > + xa_for_each(&ictx->objects, index, obj) { > + if (obj->type != IOMMUFD_OBJ_HWPT_PAGING) > + continue; > + > + hwpt = container_of(obj, struct iommufd_hwpt_paging, common.obj); > + if (!hwpt->lu_preserve) > + continue; > + > + if (hwpt->ioas) { > + /* > + * Obtain exclusive access to the IOAS and IOPT while we > + * set immutability > + */ > + mutex_lock(&hwpt->ioas->mutex); > + down_write(&hwpt->ioas->iopt.domains_rwsem); > + down_write(&hwpt->ioas->iopt.iova_rwsem); > + > + hwpt->ioas->iopt.lu_map_immutable = true; It feels odd that this is not cleaned up in this function as a part of its error handling. Now it becomes caller resposibility to handle clean up for the side effect created by this function. IMO, this function should clean up lu_map_immutable instread of callers to make sure they call cleanups. You can also try exploring XA_MARK_* APIs if that can help in cleaning up easily. > +int iommufd_liveupdate_unregister_lufs(void) > +{ > + WARN_ON(iommu_liveupdate_unregister_flb(&iommufd_lu_handler)); > + > + return liveupdate_unregister_file_handler(&iommufd_lu_handler); This seems little insconsistent, iommu_liveupdate_unregister_flb() has WARN_ON and liveupdate_unregister_file_handler() does not. Also, refer https://lore.kernel.org/all/20260226160353.6f3371bc@shazbot.org/ > diff --git a/drivers/iommu/iommufd/main.c b/drivers/iommu/iommufd/main.c > @@ -775,11 +775,21 @@ static int __init iommufd_init(void) > if (ret) > goto err_misc; > } > + > + if (IS_ENABLED(CONFIG_IOMMU_LIVEUPDATE)) { > + ret = iommufd_liveupdate_register_lufs(); > + if (ret) > + goto err_vfio_misc; > + } > + Do we need IS_ENABLED here? iommufd_private.h is providing definition for both values of CONFIG_IOMMU_LIVEUPDATE. Nit: What is lufs? Should we just rename to iommufd_liveupdate_register()? > ret = iommufd_test_init(); > if (ret) > - goto err_vfio_misc; > + goto err_lufs; > return 0; > > +err_lufs: > + if (IS_ENABLED(CONFIG_IOMMU_LIVEUPDATE)) > + iommufd_liveupdate_unregister_lufs(); > err_vfio_misc: > if (IS_ENABLED(CONFIG_IOMMUFD_VFIO_CONTAINER)) > misc_deregister(&vfio_misc_dev); > @@ -791,6 +801,8 @@ static int __init iommufd_init(void) > static void __exit iommufd_exit(void) > { > iommufd_test_exit(); > + if (IS_ENABLED(CONFIG_IOMMU_LIVEUPDATE)) > + iommufd_liveupdate_unregister_lufs(); Same as above. > diff --git a/drivers/iommu/iommufd/pages.c b/drivers/iommu/iommufd/pages.c > @@ -1427,6 +1429,12 @@ struct iopt_pages *iopt_alloc_file_pages(struct file *file, > pages->file = get_file(file); > pages->start = start - start_byte; > pages->type = IOPT_ADDRESS_FILE; > + > + pages->seals = 0; This is already 0. > + seals = memfd_get_seals(file); > + if (seals > 0) > + pages->seals = seals; > + > return pages; > } > > --- /dev/null > +++ b/include/linux/kho/abi/iommufd.h > + > +struct iommufd_lu { > + unsigned int nr_hwpts; Should this be u32 or u64? > + struct iommufd_hwpt_lu hwpts[]; > +}; > + Should this also be __packed? > +#endif /* _LINUX_KHO_ABI_IOMMUFD_H */ > -- > 2.53.0.rc2.204.g2597b5adb4-goog >