From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (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 10F7C369224 for ; Wed, 25 Mar 2026 20:24:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774470277; cv=none; b=iQo03N3CKeqtN7tfwPOLgRbBoUvhOau5NVhuXdSO8o7NHXF7FEfB2us6Qx9zdPx+UDUzwN6F6L3GsjDkxl29mdwOyUd0bRroQj1iaPtq/lnQQ6fA9fHwmycKSzE1tcr/u/er354wVtR08fbQXheZYpEaBuGunpa6m5BsXw1wx3Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774470277; c=relaxed/simple; bh=DYvje2FoIho5ps5m5xxWUnNXzs0jagNYsnTUHNm0hls=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jn6fVN4nbg+N7k67B32Uhk1x08Gi5LUza+NFyLQ9gsM6Ap25igGme0AdqSNvbTcerYI53a8f1TM8Nw8QPvzBytxcX0dt+r49+JXpBgDYjcQjW47FAS/nw2sRZ/of1F7DLhZCbDpren+h+XgHZtPdTDwIoY4irq7FFbZUoHSa5/M= 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=paESmZKc; arc=none smtp.client-ip=209.85.214.179 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="paESmZKc" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2b052562254so29705ad.0 for ; Wed, 25 Mar 2026 13:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774470274; x=1775075074; 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=cd13UlKNCcUyqY4tTtGEjc2CPeu8xCNqWeWEmMFV/5Q=; b=paESmZKcFtG4CV57asQkGX48Vfah/kqk+0acHOeRJVztTa87Lz6QXzxPnMC+LPxNC8 7hb9hg/7YtGHE3NbjTwEMzUuOs6gUVMEwk5ulOVZXzBRKZYNT3AAPIFn539ovl2dn4SO IRftf7x+umuD7ZGplTzK0Q+LAfNknAYprw2ZXHqR+GFlTyaU5W487oKKmPTtsg3lnuXO t7L+WhA5OaBZ6c01ni0kMVrkdRfx3v32ya/Lyo0miCVEjK24OSX4sE50ttDejhCkuES0 mI/Dg+vKoLGBj9IjffMW5mdQM9jgsRhDDNhdafiY13eCJb4E0dp6oS5/aVMJySB+th1t rkBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774470274; x=1775075074; 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=cd13UlKNCcUyqY4tTtGEjc2CPeu8xCNqWeWEmMFV/5Q=; b=ZpHj8LSHROw19lFE+W0L8rmMja+OBYPBy0IXVNzUehb7n4dS6RcPd552dRxiHJE8tv sL9RMr7GddKH6q53BUKZWvoSkubx/PIrQIu94H0vwOuLxcipkJ+GDSqw5zj5I3WgiWm5 TTUCi51VKWZ2XoZCS6tpwTJa1apKzrHi9rBwVjRI/UDjSJl7jPSibPwIC+Cc7l2nx/23 1tu5rgKhl2Koz5ZIlmNTmvu6b5tE5h4RXxEHlfJ7SqVFa0hfe6oac6Y+WPA8+GJl9X1K D87P21mQeyAw2C0eEAQ3fcmlEHUbEur5GaNkHcpcXNf4SKdFf8nip3qUnjTyqGStvPRf 2uSg== X-Forwarded-Encrypted: i=1; AJvYcCWgFn3IqVbAF7CK9sokfy6IiPkt7AWj4pPC3S8I3IR//S8WXCNx+QfItHZjXX1zc4WZXO+fjuLYbSuj+eU=@vger.kernel.org X-Gm-Message-State: AOJu0YwfpUTH+re/a2FtCnxfh+LK/KGQyA1LCMlTfGqUZjYvgDNyH6Y4 Wxrfs9cyXe/uLiuNy3WUyShEjJfwg3fcGFJyoJ9F6xIE1r8KHTJTutcUNsxsTW/wyQ== X-Gm-Gg: ATEYQzzyAJ434rGQllBfDs+UUNw0dahfPNTf7/2Qo6WO/m5EGTCet4If+jZ/muuW/zA 3Lu6xE+3i0cK8pOJxDIxT7wY5Q/2RdaXg8+4Rv4r8SEltZQFclimctO8pMXz1jFPVBgU0o6yhv5 A298T1VXPd3miAsIOgdd7806ybocD1hhwTrzF+JVxJoBuZ8a3Zu+adR2xbDAWCZX1Ptbq5kSV54 +1CunCKAz2F7MJQvpuxy9HVQIaXREFWiP/WUq47SsipRLVE7hBCT5n2UTL6aglAtCoocKaZBzCg viMy+FQEXRT6uEglEjV5scFIxWQfs25dpmY/yyEQ4It2zOS/TPWy3eAvVSJeScteV6mxFAczuhz wxrugvnMJWE8etrlp3iSxAPDg12H92+5ds7uauFwnI8GnMMSPcHo5pByC2BlqW0LkUN48JNDgD8 S7yuWYHLNf7ucCHtWhM35ga8tPfrcfbPVgog+b2OpZA36/1ysZxF8w9ScVyg== X-Received: by 2002:a17:902:ce88:b0:2b0:5fb4:c1a3 with SMTP id d9443c01a7336-2b0bfedac62mr339855ad.15.1774470273769; Wed, 25 Mar 2026 13:24:33 -0700 (PDT) Received: from google.com (10.129.124.34.bc.googleusercontent.com. [34.124.129.10]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b0bc76be40sm7135815ad.8.2026.03.25.13.24.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Mar 2026 13:24:33 -0700 (PDT) Date: Wed, 25 Mar 2026 20:24:24 +0000 From: Pranjal Shrivastava To: Samiullah Khawaja Cc: David Woodhouse , Lu Baolu , Joerg Roedel , Will Deacon , Jason Gunthorpe , 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 , Vipin Sharma , YiFei Zhu Subject: Re: [PATCH 12/14] iommufd: Add APIs to preserve/unpreserve a vfio cdev Message-ID: References: <20260203220948.2176157-1-skhawaja@google.com> <20260203220948.2176157-13-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-13-skhawaja@google.com> On Tue, Feb 03, 2026 at 10:09:46PM +0000, Samiullah Khawaja wrote: > Add APIs that can be used to preserve and unpreserve a vfio cdev. Use > the APIs exported by the IOMMU core to preserve/unpreserve device. Pass > the LUO preservation token of the attached iommufd into IOMMU preserve > device API. This establishes the ownership of the device with the > preserved iommufd. > > Signed-off-by: Samiullah Khawaja > --- > drivers/iommu/iommufd/device.c | 69 ++++++++++++++++++++++++++++++++++ > include/linux/iommufd.h | 23 ++++++++++++ > 2 files changed, 92 insertions(+) > > diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c > index 4c842368289f..30cb5218093b 100644 > --- a/drivers/iommu/iommufd/device.c > +++ b/drivers/iommu/iommufd/device.c > @@ -2,6 +2,7 @@ > /* Copyright (c) 2021-2022, NVIDIA CORPORATION & AFFILIATES > */ > #include > +#include > #include > #include > #include > @@ -1661,3 +1662,71 @@ int iommufd_get_hw_info(struct iommufd_ucmd *ucmd) > iommufd_put_object(ucmd->ictx, &idev->obj); > return rc; > } > + > +#ifdef CONFIG_IOMMU_LIVEUPDATE > +int iommufd_device_preserve(struct liveupdate_session *s, > + struct iommufd_device *idev, > + u64 *tokenp) > +{ > + struct iommufd_group *igroup = idev->igroup; > + struct iommufd_hwpt_paging *hwpt_paging; > + struct iommufd_hw_pagetable *hwpt; > + struct iommufd_attach *attach; > + int ret; > + > + mutex_lock(&igroup->lock); > + attach = xa_load(&igroup->pasid_attach, IOMMU_NO_PASID); By explicitly looking up IOMMU_NO_PASID, we skip any PASID attachments the device might have. Since PASID live update is NOT supported in this series, should we check if the pasid_attach xarray contains anything other than IOMMU_NO_PASID and return -EOPNOTSUPP? Otherwise, we silently fail to preserve those domains without informing the VMM? > + if (!attach) { > + ret = -ENOENT; > + goto out; > + } > + > + hwpt = attach->hwpt; > + hwpt_paging = find_hwpt_paging(hwpt); > + if (!hwpt_paging || !hwpt_paging->lu_preserve) { > + ret = -EINVAL; > + goto out; > + } > + > + ret = liveupdate_get_token_outgoing(s, idev->ictx->file, tokenp); > + if (ret) > + goto out; > + > + ret = iommu_preserve_device(hwpt_paging->common.domain, > + idev->dev, > + *tokenp); > +out: > + mutex_unlock(&igroup->lock); > + return ret; > +} > +EXPORT_SYMBOL_NS_GPL(iommufd_device_preserve, "IOMMUFD"); > + > +void iommufd_device_unpreserve(struct liveupdate_session *s, > + struct iommufd_device *idev, > + u64 token) > +{ > + struct iommufd_group *igroup = idev->igroup; > + struct iommufd_hwpt_paging *hwpt_paging; > + struct iommufd_hw_pagetable *hwpt; > + struct iommufd_attach *attach; > + > + mutex_lock(&igroup->lock); > + attach = xa_load(&igroup->pasid_attach, IOMMU_NO_PASID); > + if (!attach) { > + WARN_ON(-ENOENT); WARN_ON takes a condition.. if we want this to be printed always, why not WARN_ON(1, "...") ? What's the significance of having -ENOENT as a condition? > + goto out; > + } > + > + hwpt = attach->hwpt; > + hwpt_paging = find_hwpt_paging(hwpt); > + if (!hwpt_paging || !hwpt_paging->lu_preserve) { > + WARN_ON(-EINVAL); Same here for -EINVAL? > + goto out; > + } > + > + iommu_unpreserve_device(hwpt_paging->common.domain, idev->dev); > +out: > + mutex_unlock(&igroup->lock); > +} > +EXPORT_SYMBOL_NS_GPL(iommufd_device_unpreserve, "IOMMUFD"); > +#endif [ ----- >8 ----- ] Thanks, Praan