From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (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 DC1232F5A34 for ; Sat, 9 May 2026 17:10:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778346619; cv=none; b=ckXPaoeXbs2UUgq61wmkCXEwrhQ/q2brY5I/OivYjEfr/6Y0Nz4mJxcH1jRyLvOoDWQhoU9/8hUWDnVKr1RqmjwA47ZZ7OmA60VW4F5CknvnnWehfwHboA28w/RqinGzNL6ZkMDl84Pa5EqQRLcos0wd6Wh651GJVf2pQigVrXw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778346619; c=relaxed/simple; bh=Ib4XRsG2e4tlDimBfCEgugHOngPORoyq0KGAVzHdcZE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=L1BDlVIrdNPJCjhMXSSnaSnDLUcGPUO+cLPJEUgoN96gw62VPCHc9m1i8K5nK5PfZG+CiC6M1Tvf4Ocu8lqDLLJRRfENuZ34X1t+NIoenAEPJ+DYGH3v07BEfME9TgJK49zjECggtdMj8EfbzqNrJamblnYzKsUuF6b8ZgL0DD0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=b8xEgYg7; arc=none smtp.client-ip=209.85.222.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="b8xEgYg7" Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-8cbc593a67aso276687185a.2 for ; Sat, 09 May 2026 10:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1778346617; x=1778951417; 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=Ib4XRsG2e4tlDimBfCEgugHOngPORoyq0KGAVzHdcZE=; b=b8xEgYg7OkDL10zKV/ZCDRugmb7bqHIdcUHBbmQGAcFGqBRB3Pji/tLrZWWRXhxicy PO+cbt1+xMBvsWBLejAvJ2qc9HRBARsJSQ9d3mG1Ooj1a2FBD+uzL4iyfaqcaE0HcEvo Qlcgoo374v7Y+8/4BMzgzQN/pL+3IY3sY1GU9Rd34ndaqjqY01Oo5E+xVxFTMmKXl6J4 Qv7kXyWzbyMuPcj4KnNTRAVF8rKuz9GmiQ6W7Fe19F/t1eBta9ZOjPe5ryvTU+LvrK1p +QLC8z50RZBxe6oVydtsY2HIrZ2/Ct1yOXWVmXX3mbj665OXufYWYPlWhBRlQuEw6k+Q Z7yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778346617; x=1778951417; 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=Ib4XRsG2e4tlDimBfCEgugHOngPORoyq0KGAVzHdcZE=; b=YUSpOGRHRJfwbvFliyVuZP1DnRoo+xZI3kIpVQmmCyoNEdiZuz2cxAKngAVWiwkweN 1vk5oIK+VPjiOZNKk65Q242fQvIIMztylXFA4AI/NaXFI93KdE0Z2MATgqYHE5gG0sqM Bp2Yo6KQ1FTNmv18Xuax+qlj6Z+DgOMVAnhCqlgo6ZtMbX3CBkxsjVrxxgJCNGOcQtXm r1eonNucGu01JcyC3OZzSHuR1I0BHzp8KNtHkzddjYNz/gMZX3La3RNAukqCXBQghgVP gUMGmcL0ixlF9ZnzUU5CyAcDpfgMD6K22DucTnCw0+Zm2nuIHC2CSYVkfo6Vf5sBmrWJ c7Wg== X-Forwarded-Encrypted: i=1; AFNElJ9Z6P/pV21pOE+9dfjJ7rHBzgyU0IiVabxHb9nrcHrjhyV5hD83TfMhfjPku8jgFlFwdhOkcbDREGMxgVA=@vger.kernel.org X-Gm-Message-State: AOJu0Yz7P0Lnyh1ZqqeW9AmiglK0bingaS5/S0llMWM4rWzk1dFcRf76 n2J88fbEO9lWcXX16VxqQ51muNV+eZDULOMXopAm0Wz+mvfIZPvU0ykyn7lWqmMWvs4= X-Gm-Gg: Acq92OHeMdElVkwHDv9TE9KTHsi+KtQNwlpnT/dbVCEcDJOxnaZ9Bk/p0HD2lQa4dmo a9XC8jqa+PgUH5WQ5uxFWx1Mz6hRDQgk9gnnAz72IEwkbEFswFEs0vpk8oXJ0rMGe8JzBODGZd1 mD0RvLCh1ltlZUiDXMgFpqaM7tcBYLkL4m5h0kZkLcmGRvnyOOMNerhbyjgaZE/syxIhaeLXZRM epR9biqgeQM0sjOrQNSN5JqfV6Pa2g/Shww3xH1U06NSh67x30Bh+2IRkW5NyP6LxHOrkvFKZv7 +8Y6coL+4a/zTUYcLZbh9OYeB7lm/xbFaoaJSCCJh8Oe13LJWnFmKBNeT230WA9DMnbxgVz4mVY GeJDyDmF6VWQZnR/awTS4o3y7mjCiirkgYT+AzrNMmACfbkdvDMPWR6ytxYStEsZbv1IV6nxCqn iPiQup9PeDlPLNu7aP1TbNNlh797lfEcw+8Lu7yl5otFZyeZr3NAX2xR0/CQ59FmMhwC/VKqzUG g/ayg== X-Received: by 2002:a05:620a:44cf:b0:8ee:cbf0:8311 with SMTP id af79cd13be357-9091072fa59mr433663085a.54.1778346616735; Sat, 09 May 2026 10:10:16 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id af79cd13be357-907b8d9eed0sm552694685a.19.2026.05.09.10.10.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 May 2026 10:10:14 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wLlBt-00000001qju-3hnc; Sat, 09 May 2026 14:10:13 -0300 Date: Sat, 9 May 2026 14:10:13 -0300 From: Jason Gunthorpe To: Joonwon Kang Cc: Alexander.Grest@microsoft.com, amhetre@nvidia.com, baolu.lu@linux.intel.com, iommu@lists.linux.dev, joro@8bytes.org, jpb@kernel.org, kees@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, nicolinc@nvidia.com, praan@google.com, robin.murphy@arm.com, smostafa@google.com, will@kernel.org, jacob.jun.pan@linux.intel.com, easwar.hariharan@linux.microsoft.com, kevin.tian@intel.com Subject: Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA Message-ID: <20260509171013.GF9285@ziepe.ca> References: <20260424133953.GY3611611@ziepe.ca> <20260507095851.3220765-1-joonwonkang@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: <20260507095851.3220765-1-joonwonkang@google.com> On Thu, May 07, 2026 at 09:58:51AM +0000, Joonwon Kang wrote: > By "similar instruction" on ARM, I guess you mean ST64BV0, which fetches > the bottom 32 bits data from ACCDATA_EL1. Please let me know if you meant > others as it will matter. If ST64BV0 is supported on ARM, however, it > would mean that ST64B and ST64BV are also supported already according to > the ID_AA64ISAR1_EL1's LS64 field. The latter 2 instructions are just to > atomically store whatever user wants to a memory location without > referring to ACCDATA_EL1 and all the 3 instructions can be run at EL0. So, > the userspace driver would have enough capability to designate arbitrary > PASID as it wants via the latter 2 instructions when communicating with > multiple devices. IDK exactly what ARM did. IIRC on Intel ENQCMD forms a special non-posted write TLP and the device can tell the TLP came from ENQCMD and so it trusts the encoded PASID. ARM has to have done the same thing - allowing anyone to forge the PASID by using a different instruction misses the point of the Intel design. Honestly, I'm not sure why they even implemented it. SMMUv3 can't do the translation scheme required to use ENQCMD from a VM anyhow, so it is pretty useless. > We have multiple processes and a single device, those processes want to > do SVA with the same device, and only one process will do SVA with the > device at a time. Though, the problem occurs even when irrelevant > processes allocate the PASIDs from the global PASID space for their own > irrelevant purposes. The only way to allocate a PASID from the global PASID space is to establish another SVA, so you have multiple devices doing SVA? Jason