From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 4E4B92E3397 for ; Mon, 18 May 2026 18:33:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779129230; cv=none; b=cyDBlgP5ivA3Zc0SZVs2bpwh7ZaxAoIzqVrXJW84x7TZDVbEPx/W2IFfJ8p7wJmlfM5uAa0ewRDQIkJ4bhEg+k4JU7blcB/Y8Zh9PC1QFH8K8+/rccXGBlMGfKL2WpSdBNAVio8JNROYjx1F/oSOFEqwORkh2RC+r07s7LYiwcw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779129230; c=relaxed/simple; bh=TyOWWPWoGocXqSwMD+MG/Lr0Gd5wpTyR5wdZ+yXhOuM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BjGNZ1csfDIie1f7REQVp/ZV1Vtfr5lB1GDHvannhVXNwqMJt9gxs8QbxWtfcJW8mqw++nfNwVXkZDdHb71n1dXKf1rLW57hZJPJG72WvRrk0hGTmvWQjjAJAivwiGsyxe4wHNnwIMCVbnqbwbUMlWfUT2tCwSKk+gkYykD9dUU= 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=j92Z+zs4; arc=none smtp.client-ip=209.85.214.177 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="j92Z+zs4" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2ba180a022dso1195ad.1 for ; Mon, 18 May 2026 11:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779129229; x=1779734029; 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=1KANnHv0swkPJJWZfqLe5jM5UVpVbFidl0DzMhA68oc=; b=j92Z+zs4S7fV94e7p3+nwNS+bYD+KyHW0rrIgz8HJilqTSYBo3/GN5pc0+Ntt9ebTG IJxA0ztall3PUK7d03DpKium1ecZZP9Fn/eeXUVub3LRfYBqEMt1NVDZgtMWR6k58+3Z ScMfEciW7tZmqtuY+WKlXCPGKkw0Dm+Ti4rnjoMc1TBevtZESWiF/MI6IWl7pE2xrQd0 WojOa99b6D+d9/ItAY7ZbMWjGSLTerKN+3J4pRzBqqdGFypj1L/2Ci/HOe5Qfqj3mqyE /TPXJ9aBF99v06vZV0DvunepCPvBoxFqoefepaGbXBbyuKFOyyck1vK0hGVTHcccLP9K k/XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779129229; x=1779734029; 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=1KANnHv0swkPJJWZfqLe5jM5UVpVbFidl0DzMhA68oc=; b=E4BsIGTOQCkcMpjBd+rQiGK1EgEk8tb9GV82TvaCJzo+qGLs1P3z0dgcWqL6QmZdT4 cMB0NrDE7lq9/4FRlIK4+SqXDpAvtvawmXucpLxBWhZj1n6rhbizHr/kD0R/esvt5Red /6ey8SnSkd+tKZ1Wy6FMc9JO/ipE3EAopGgEOicDSRwwMdz58uZ4CQxWsB4D8riTKAA5 bPUYapolWc5wZzHWjcCyZvr8ySwRuU8uMsDzdOKHe9bH6HcQ5DrzHiiLFQqqLKGaymsb 83W25SnkY76K7ViwaoUoqKP1RO4wZhRCCKqEJS60eybtGf9VkVQ8s5UDAeeXMc+c9SAc ORuA== X-Forwarded-Encrypted: i=1; AFNElJ/s8D8WFWUYtJPtLnhWffShqHPpGMBJ3sqrk/5hwrpiucdAcCiut5IKMvNsopZtARFsGKyMQ+EP2Gn+i/o=@vger.kernel.org X-Gm-Message-State: AOJu0Yz7huYQtmhta/bPZI7MvC2YmwWboJTCr7/zV1jT3b1dWOfCHhAU qAxXcFI9Uruu3LkUsuI+nzfGiYPUvG46BZODP9Iwltcg28xGZnfCisE+LNGd0ANkpw== X-Gm-Gg: Acq92OEtJ3VBlKOZgLcwGog1l5PEQyLdzyEFiVl7Et6QeXaCiLr2vqCY4bgI3hVt6Y2 sTNA527epu6Caph41IQQoJBuf1rAkAlbZK033E8RarH/utIX0x/Dib+QtC+1ekciLg+unQwBIOl gIaLULMXLMxjhcpG0ILSpb1+ErEetgoJmh8G04jDe/Njp9FfSr+T8nmuz/0wXCqb3BKQyUuhRPK prVcNZgX1tsFF56vxYD56cT4IQp7IYqlL/isUYBaL4ZKb+n2BNTRbivzMFBqGzSfbvK8YhY8dkj 1zvZRpZOdxTEWrRicpGUv7BITSuFB5KCcXK4/8GqmNOa+kNHkMcKZoMRJgIj/CjPJa0ZkuI3V8F 4j+dKjxSR2A+yiq4xm2HLlwqqziAdbjwWLQLFUYJkb+ptw3EibYHjBUefhUalFGhOydM2WTHPij eEm/5acgQnfkEUVGG+9hJufq5GFlGSXZyh1Mz3vij0j1pA2te4XBnlv4kdYU+BGnBUKHtFHQ== X-Received: by 2002:a17:903:32c5:b0:2b9:e831:5e5c with SMTP id d9443c01a7336-2bdb03a42c2mr3898675ad.4.1779129227834; Mon, 18 May 2026 11:33:47 -0700 (PDT) Received: from google.com (153.46.83.34.bc.googleusercontent.com. [34.83.46.153]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2bd5cfe6487sm156913305ad.54.2026.05.18.11.33.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 11:33:47 -0700 (PDT) Date: Mon, 18 May 2026 18:33:44 +0000 From: Samiullah Khawaja To: Pranjal Shrivastava Cc: Baolu Lu , David Woodhouse , 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 v2 04/16] iommu: Implement device and IOMMU HW preservation Message-ID: References: <20260427175633.1978233-1-skhawaja@google.com> <20260427175633.1978233-5-skhawaja@google.com> <3874a086-98ae-4b94-8c1b-20e13f5a92fb@linux.intel.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; format=flowed Content-Disposition: inline In-Reply-To: On Mon, May 18, 2026 at 02:01:25PM +0000, Pranjal Shrivastava wrote: >On Thu, May 07, 2026 at 06:47:07PM +0000, Samiullah Khawaja wrote: >> On Thu, May 07, 2026 at 10:07:43AM +0800, Baolu Lu wrote: >> > On 4/28/26 01:56, Samiullah Khawaja wrote: >> > > Add IOMMU ops to preserve/unpreserve a device. These can be implemented >> > > by the IOMMU drivers that support preservation of devices that have >> > > their IOMMU domains preserved. During device preservation the state of >> > > the associated IOMMU is also preserved as dependency. >> > > >> > > Signed-off-by: Samiullah Khawaja >> > > --- >> > > drivers/iommu/liveupdate.c | 162 +++++++++++++++++++++++++++++++ >> > > include/linux/iommu-liveupdate.h | 33 +++++++ >> > > include/linux/iommu.h | 20 ++++ >> > > 3 files changed, 215 insertions(+) >> > > >> >> [snip] >> > > + >> > > +int iommu_preserve_device(struct iommu_domain *domain, >> > > + struct device *dev, u64 *preserved_state) >> > > +{ >> > > + struct iommu_flb_obj *flb_obj; >> > > + struct iommu_device_ser *device_ser; >> > > + struct dev_iommu *iommu; >> > > + struct pci_dev *pdev; >> > > + int ret; >> > > + >> > > + if (!dev_is_pci(dev)) >> > > + return -EOPNOTSUPP; >> > > + >> > > + if (!domain->preserved_state) >> > > + return -EINVAL; >> > > + >> > > + if (!iommu_group_dma_owner_claimed(dev->iommu_group)) >> > > + return -EINVAL; >> > > + >> > > + pdev = to_pci_dev(dev); >> > > + iommu = dev->iommu; >> > > + if (!iommu->iommu_dev->ops->preserve_device || >> > > + !iommu->iommu_dev->ops->preserve) >> > > + return -EOPNOTSUPP; >> >> I will check for unpreserve ops here also. > >[snip] > >> > > + pdev = to_pci_dev(dev); >> > > + iommu = dev->iommu; >> > > + if (!iommu->iommu_dev->ops->unpreserve_device || >> > > + !iommu->iommu_dev->ops->unpreserve) >> > > + return; >> > >> > Is it considered a driver bug if it implements the preserve hooks but >> > not unpreserve ones? This would at least cause a silent memory leak. How >> > about adding a WARN like this? >> >> I think the preservation should not be done if the unpreserve ops are >> not implemented by the driver. I will add these checks in the _preserve >> functions and return EOPNOTSUPP if it is not implemented by the driver. >> > >> > if (WARN_ON_ONCE(!iommu->iommu_dev->ops->unpreserve_device || >> > !iommu->iommu_dev->ops->unpreserve)) >> > return; >> >> We can add this warning here also. > >I'd rather have the iommu device registration fail instead of solely >relying on these WARN_ONs here. We can simply add a snippet inside >iommu_device_register(): > >#ifdef CONFIG_IOMMU_LIVEUPDATE >if ((iommu->ops->preserve && !iommu->ops->unpreserve) || > (!iommu->ops->preserve && iommu->ops->unpreserve)) { > pr_err("IOMMU: %s: Asymmetric live-update operations detected\n", > dev_name(iommu->dev)); > return -EINVAL; >} >#endif > >This prevents a half-baked iommu driver from ever spinning up, completely >eliminating the need to check for it inside the live-update session paths. >We anyway don't support hot-pluggable liveupdate ops atm. Hmm.. I understand your point, But I think we should let the registration go through so the IOMMU can be used. Its just that the liveupdate preservation will not be supported. Failing the registration would be a big hammer that I think is not really needed. > >Thanks, >Praan Sami