From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (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 51DC4284B3B for ; Fri, 20 Mar 2026 01:05:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773968743; cv=none; b=gZ5VjuJl6XhgVOrc9G1fIOItuCJGbi6DwDCIQ/lISOjSmiUMdTtvkctvYKDvEqnPbO2mHMXSXWOG7e64f8893jPJTkBQmAwjVkkM5x1n81KgMN8ZTvqRSIMphhHgZuiHP/KzESEt6AecD5GzwDnUcHiGXdM4WVtXEmrOewitDsQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773968743; c=relaxed/simple; bh=QIqXKeW1izdWNR8jM1NhwLjTo9tqpcgolnf5WC9Fg60=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=J0qLV4UVo9u4wpbKh/mOYAaOOMlPNolYuo84qhn+M1LjoqWMSrFiPXFJT3R3EAUvryxUi864IT0/JErnduqwb/PRZbnnHdZcFrMw/RtBK3k0gGyqIslz2tO5X6ywFm1gfN3FquXAF4kjDdVQ1e2wygm3HfpmYFTOUrphryzw480= 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=QX6oqucH; arc=none smtp.client-ip=209.85.214.169 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="QX6oqucH" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2b04c9e3eb7so40085ad.0 for ; Thu, 19 Mar 2026 18:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1773968739; x=1774573539; 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=xTn3hK2jgdEVmDsb9ax7KRypVVI5dKtyHQlrYUlMo/M=; b=QX6oqucHCmpTNXMM7EleN+m74DkIEC0zIFaGMl/igtGkOKapdJ5+uvk/espDqmtnpF 7JgOLp2fqWeK7P3j6pT8BDnWyPvIGT9YlhurV0mc/pDkWDwev7wsXmnZY4Qk32Av46Tx +vOwFj9D7VffPqpskUioOMTArKl8nuQPnAbjiAdA3xbo2MgdG3UuruG7XMhtox641hxf RjgFV0O388/oz5wAGFBOJEgm9TDtaHdHaDjGdY7BMg4efyGfkcZMv8qgMtmn1DrEprue p9YQ0Ct6BQZjDC4/indkGHBQBW+np5K4cl+aGS+ERD1oPLNpV291HPwk4Ire4kQpKG0G WZ7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773968739; x=1774573539; 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=xTn3hK2jgdEVmDsb9ax7KRypVVI5dKtyHQlrYUlMo/M=; b=Y8r1GS5r4k3r03ISqAdxVmTpOj9HGitDQ8H0Q8oSNgNx2OByrpQyS81UYppEjEtPUe CuyrZAQV1Ae5EM3vHEG8dBYErFWZN8k2EUyiDibOCNHNkN0JzNyzzLB5QtHARhIEG2i1 UTSUnfnq4/G4uoVenMB996oLFrEnHoO6ybaA35rgS1rFcVLYa6BMcYoRtNdq96T1v9+w Ghm/Xe8s5arSp+ucLSQGAPHqrRUJRbl8QFmTcnL9hry8hdf+l2EJzegqndfgOQGy48iJ eOdVFd9p+6Qpr8geBw6HWSWQUclF5wpoqfiMOy04cRqD2M+WqHmndWV2FAV9fKWEqdn9 TmPg== X-Forwarded-Encrypted: i=1; AJvYcCWbe/pPYqBdbflwkDAiZmm/m4K7tKtHV/O2hL+JVWeeFGBhqvYwqHxOzn5hcbKfoRNzCaFyS8uHRUdfaG4=@vger.kernel.org X-Gm-Message-State: AOJu0Yxtu/6DN2iHKnG1+pmhnkDY/wyI9lbs2oW7hnr81rTYA3iY6l6r QtP+IBh11wLVn+oZcIxhxVqr6JFKEBVaI1TWaO4js1PN/0hlpfaAXkAKUSSZ6ppMIg== X-Gm-Gg: ATEYQzySJOOCR4AJfMsIdwGxlsFvO9qa0R687UjES4d094gt+giuk5TFLB+DEWUlpFI ABdWqWr1Kt4673FkUIIWTT9rNBsoIril62qrts4bLseK2XfSELIGCoCKNiHt+vMGvny1FkWabvi S+Po7n3KGdvXESSLJt+/wQ8TF3WgpBZk7leUToeqN5cSgFqk6pUDRHX3C0rGXf4c7ndVi+MbZnm esSptj9DEB3Dn3IMaelt7wpNf8XMKHUUtJzTkG6kvraIXOStvVH98lJp6yJ19tDOwobO3el97Js 29D3xejuGR682Tm9mO3In3ZAmT8reWRS4xwwV8TEfioWXJB9nkZj+Z/vUWDCi1HczgqNALNpnNm 3c2U5IV8l2dRjXyul4rwMyS+I26kvU5MD8OtKdkzYRN+KNUgMwrW//ShVNjFtBtHTZNVd9w+i5N 4OYjM178WBr/YTp+JRwIIhGaZE0Z2rEIFpImplSbAXvARYkENavb/LUbxv+Wclfg== X-Received: by 2002:a17:902:d544:b0:2b0:5cc5:9405 with SMTP id d9443c01a7336-2b08366b3bfmr1001805ad.1.1773968738628; Thu, 19 Mar 2026 18:05:38 -0700 (PDT) Received: from google.com (168.136.83.34.bc.googleusercontent.com. [34.83.136.168]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b0836b97fesm4163285ad.84.2026.03.19.18.05.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Mar 2026 18:05:38 -0700 (PDT) Date: Fri, 20 Mar 2026 01:05:34 +0000 From: Samiullah Khawaja To: Vipin Sharma 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 , Pranjal Shrivastava , YiFei Zhu Subject: Re: [PATCH 07/14] iommu/vt-d: Restore IOMMU state and reclaimed domain ids Message-ID: References: <20260203220948.2176157-1-skhawaja@google.com> <20260203220948.2176157-8-skhawaja@google.com> <20260319190137.GA3983821.vipinsh@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; format=flowed Content-Disposition: inline In-Reply-To: <20260319190137.GA3983821.vipinsh@google.com> Hi Vipin, On Thu, Mar 19, 2026 at 01:54:27PM -0700, Vipin Sharma wrote: >On Tue, Feb 03, 2026 at 10:09:41PM +0000, Samiullah Khawaja wrote: >> During boot fetch the preserved state of IOMMU unit and if found then >> restore the state. >> >> - Reuse the root_table that was preserved in the previous kernel. >> - Reclaim the domain ids of the preserved domains for each preserved >> devices so these are not acquired by another domain. > >Can this be two patches? One just restoring root table and second one to >reclaim device ids. This patch is restoring the state of the preserved IOMMU. The domain ids are part of the iommu state and used in the context entries that are being restored in this patch, that is why I kept these in one patch. I will reword the subject of this patch and add a note on this in commit message. > >> -static void init_translation_status(struct intel_iommu *iommu) >> +static void init_translation_status(struct intel_iommu *iommu, bool restoring) >> { >> u32 gsts; >> >> gsts = readl(iommu->reg + DMAR_GSTS_REG); >> - if (gsts & DMA_GSTS_TES) >> + if (!restoring && (gsts & DMA_GSTS_TES)) >> iommu->flags |= VTD_FLAG_TRANS_PRE_ENABLED; >> } > >I think we can just check in the caller, init_dmars(), and not call this >function. We are already modifying that function, so no need to make >changes here as well. WDYT? Yes, I think we can move the if outside. > >> >> @@ -670,10 +670,16 @@ void dmar_fault_dump_ptes(struct intel_iommu *iommu, u16 source_id, >> #endif >> >> /* iommu handling */ >> -static int iommu_alloc_root_entry(struct intel_iommu *iommu) >> +static int iommu_alloc_root_entry(struct intel_iommu *iommu, struct iommu_ser *restored_state) > >Nit: Since we are using iommu_ser at other places, I will recommend to >keep it same variable name here as well. Hmm... that is a good point. I think I will update the other places and change it to restored_state/preserved_state to better reflect the context. > >> @@ -1636,8 +1643,10 @@ static int __init init_dmars(void) >> intel_pasid_max_id); >> } >> >> + iommu_ser = iommu_get_preserved_data(iommu->reg_phys, IOMMU_INTEL); >> + >> intel_iommu_init_qi(iommu); >> - init_translation_status(iommu); >> + init_translation_status(iommu, !!iommu_ser); > >Just put 'if' here to avoid changes in init_translation_status(). Agreed. > >> +static int __restore_used_domain_ids(struct device_ser *ser, void *arg) > >Nit: Just curious, why two __? I will remove these. > >> +{ >> + int id = ser->domain_iommu_ser.did; >> + struct intel_iommu *iommu = arg; >> + >> + ida_alloc_range(&iommu->domain_ida, id, id, GFP_ATOMIC); > >Should we check if allocation succeeded or not? Good point. This should not fail as we are reserving these ids during init. But I think I will add a WARN here. > >> + return 0; >> +} >> + >> +void intel_iommu_liveupdate_restore_root_table(struct intel_iommu *iommu, >> + struct iommu_ser *iommu_ser) >> +{ >> + BUG_ON(!kho_restore_folio(iommu_ser->intel.root_table)); >> + iommu->root_entry = __va(iommu_ser->intel.root_table); >> + >> + restore_iommu_context(iommu); >> + iommu_for_each_preserved_device(__restore_used_domain_ids, iommu); >> + pr_info("Restored IOMMU[0x%llx] Root Table at: 0x%llx\n", >> + iommu->reg_phys, iommu_ser->intel.root_table); > >Should raw pointer values be printed like this? I will remove this. >