From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 975802F1FEC for ; Wed, 14 Jan 2026 05:45:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768369524; cv=none; b=A2OdpReoiE0u/2TYAn5x3TbUTapB3TAR8UBymuOOp5QfW8VevyBYB2nwqG+7XA/ITiJKkEVpT054LtmY/cBERdlz+Cx5BvDcck6IS3vu+SDph+QO1wZNUoH1KIMpJwXHX0flpngFSJncqhybaRdFS4XDjKbqcHXIAj7Oh6unk4I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768369524; c=relaxed/simple; bh=aMeL2laT0NhLCwJfSRDJEB8bVxQ/LT7NOk83/6mB4vc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KG8tM35yxUHXIcEF6xpG1Gc0PUjv00ikfQcEzGqJY8QDO6tnDQYhpOVBSQn4038HllMwSm/scQGL9DtCifRl1Q+ZHt1TRJ10AtYZAH5wFxmsGyl2ODxxKwAlm6D9x2p1PGMZpF9OJeJYfwlH7jJYYh4WkhkPeKIyKyKJVdZ7/Wo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=T9jLLfqb; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="T9jLLfqb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768369517; x=1799905517; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=aMeL2laT0NhLCwJfSRDJEB8bVxQ/LT7NOk83/6mB4vc=; b=T9jLLfqbqWs29hw1sk49do/Zfbq81Vt5/ycPd0nPVmhzgq40ISKYZqgC u0AyRuLqsJnvkFDRduRoIt6qx3Y9avyEZKDJikLsRdTGLl6L4CCYm3OTU m3+OEF6Dm2VpmAZGzpPqiVWXiMYQghxeLkD/AptMAoPGX0f+v8LN7yCbO t6YXlO8dEgry0qYVHZiJ7j3btCFQ5XyuZ6626TR8M1SRc1gJq9wnlTB78 Z+UVOv/a4ehebSypgEiw49uApBEXbbVI7wslgfqiYyk2WaY1PiKC+GG+Z dObUrGbjTap0jo/IoK00vRKV10eZzbWg1sVT4yUXGndj/oIIjZYyyTX8F Q==; X-CSE-ConnectionGUID: VDqgetZBRsOStgbSJoDksQ== X-CSE-MsgGUID: B8epIDb1SROn/h83EJJmZA== X-IronPort-AV: E=McAfee;i="6800,10657,11670"; a="73518868" X-IronPort-AV: E=Sophos;i="6.21,225,1763452800"; d="scan'208";a="73518868" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2026 21:45:13 -0800 X-CSE-ConnectionGUID: lT4+8GHkQK2IY0OY7UrCjA== X-CSE-MsgGUID: /xwQOJRXS9e910HJBYxe/w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,225,1763452800"; d="scan'208";a="204377298" Received: from allen-sbox.sh.intel.com (HELO [10.239.159.30]) ([10.239.159.30]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2026 21:45:10 -0800 Message-ID: Date: Wed, 14 Jan 2026 13:45:16 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] iommu/vt-d: Rework hitless PASID entry replacement To: Samiullah Khawaja Cc: Joerg Roedel , Will Deacon , Robin Murphy , Kevin Tian , Jason Gunthorpe , Dmytro Maluka , iommu@lists.linux.dev, linux-kernel@vger.kernel.org References: <20260113030052.977366-1-baolu.lu@linux.intel.com> <20260113030052.977366-4-baolu.lu@linux.intel.com> Content-Language: en-US From: Baolu Lu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/14/26 03:27, Samiullah Khawaja wrote: > On Mon, Jan 12, 2026 at 7:03 PM Lu Baolu wrote: >> The Intel VT-d PASID table entry is 512 bits (64 bytes). Because the >> hardware may fetch this entry in multiple 128-bit chunks, updating the >> entire entry while it is active (P=1) risks a "torn" read where the >> hardware observes an inconsistent state. >> >> However, certain updates (e.g., changing page table pointers while >> keeping the translation type and domain ID the same) can be performed >> hitlessly. This is possible if the update is limited to a single >> 128-bit chunk while the other chunks remains stable. >> >> Introduce a hitless replacement mechanism for PASID entries: >> >> - Update 'struct pasid_entry' with a union to support 128-bit >> access via the newly added val128[4] array. >> - Add pasid_support_hitless_replace() to determine if a transition >> between an old and new entry is safe to perform atomically. >> - For First-level/Nested translations: The first 128 bits (chunk 0) >> must remain identical; chunk 1 is updated atomically. > Looking at the specs, the DID is part of the first 128 bits (chunk 0), > so I guess for the first level the hitless replacement would not be > supported since each domain will have a different DID? It's not necessarily true that each domain will have a different DID. On Intel IOMMU, all SVA domains can share a single DID. Similarly, multiple nested domains sitting on top of the same second-stage page table can also share a DID. Thanks, baolu