From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (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 D99A0389DF0 for ; Wed, 13 May 2026 17:03:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778691817; cv=none; b=YX85vx7Lk0IPR5sZcgrmBRLSsUIydiKbe8GFFQnskK6VVpA9LZoZmCz0Qc8Yoxy1TP9xOWDar6iByDTXQeetRAnh6bCxuB7snm/PLfGCpCsKRvXTVO/D4Oi9A+mV4c3dWxEyPi5L/u1SZql8kpNWpwA+y+bx2Ntek7TUGOddOxA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778691817; c=relaxed/simple; bh=CgWakxMq1PQlgdIp9azFXsj1Hh4Z/jvIAFgCTQdI11M=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=aXwkgLRp887bNu3+8OuI15AWXagcxzmbOagMAiqOT6DR+cQA+BmOi2CTEHrpXvx6XZGLISchTSQ7V9nx5WtyexckLNM3tDTc41E7QH02hbVih7+FNitkZRCdGhtW4KRRadN1fCjX2vOQHtNCRVZ+zwM/Ur6m+mJOQrXYbqoTbOM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--joonwonkang.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Y/nFj7At; arc=none smtp.client-ip=209.85.214.202 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=flex--joonwonkang.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Y/nFj7At" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2bd1dbcccf6so29358325ad.2 for ; Wed, 13 May 2026 10:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778691815; x=1779296615; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=XWwRMJn4ysC40SZu5iEtoxx7CK76uQCrAvLKY0VkjCM=; b=Y/nFj7AtgfcftT0K/tT8UjvQy8T/LECpPGIV0spDpp/iSRYgZNJOVth+oZBVG8+BZn 6CdxxxgjTSdBtf7m03+IClZpC0KHSOBdYMRpTr/85A0zC1raoHoJlC/tBlR8o+4wkztu /TPu/tMLjekmQmE4H5uHPdJrX1DGIZBego398Hl2yB1T3FCa6SDfobptOlhKICUxo0n/ rdloGQfF4GeDVQU7qETA+bgLqR7e/8wlM4jAVItTa8EOzOB+Txwe0JJib58wtyHiBAkG gMUy0GOx0vvMGbAa2cgxrDiy68NU6E0UcMBGmewrmAyAmuq7Z7q7kCqcp6F9sfzXy1NL MpQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778691815; x=1779296615; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XWwRMJn4ysC40SZu5iEtoxx7CK76uQCrAvLKY0VkjCM=; b=Q4bfoKkScXAftPV+NfJyIHZpAQIHAxruzELV8FNytgA06gtJCsvZuT7zsXG2vGfzAR OX6udijEyN+dJTzCRpqn+HFZKH4Vk+yKPofK7mxubpQlcITa4gDPTqScyf/kBQ+zOvCW 7WIo96N/2S9jaMBJmKEQtPXMQYHcOJvYBctG6BYuMI11oygrVUgRox6+KuB6QRKygC2K NnnpG0GaqppwEB8glki4Yby9TLyvKIo4G0qHzBpohajTjk4gW1BgiCY8cJ2hnutkBxlC AyimwSOey8XrCrlosP2klFAlMw/ojmfrPxAYsy236N5AfzzmN46xZNKKs07lsBdHqU0B O9Mw== X-Forwarded-Encrypted: i=1; AFNElJ88M1FqY/6Oa0wkh2aHqdByqEcIL0ZxKHpCi21vpgi/cry4N5KelZ6rnbip5Nc/a8MqKM3X7R2O9graeHI=@vger.kernel.org X-Gm-Message-State: AOJu0YxOHz7rNjfl/owFuGoyB259Q1dEO41sACim/LTdbq8E6Qmqx+zk qapEb3Z+2KfWfblxhmkRP+5bITL5mVSFFSmqdzMstaDobqRSe9BHS4F20/IB88QBKz618Rj+Y4O sCY8X23jDpKHl3un1fWvgMC1gRQ== X-Received: from plbkf6.prod.google.com ([2002:a17:903:5c6:b0:2b9:53bb:4a09]) (user=joonwonkang job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:46c4:b0:2bd:2de3:51ad with SMTP id d9443c01a7336-2bd3043ca95mr42686725ad.34.1778691814901; Wed, 13 May 2026 10:03:34 -0700 (PDT) Date: Wed, 13 May 2026 17:03:33 +0000 In-Reply-To: <20260512151133.GD7702@ziepe.ca> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260512151133.GD7702@ziepe.ca> X-Mailer: git-send-email 2.54.0.563.g4f69b47b94-goog Message-ID: <20260513170333.1235601-1-joonwonkang@google.com> Subject: Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA From: Joonwon Kang To: jgg@ziepe.ca Cc: Alexander.Grest@microsoft.com, amhetre@nvidia.com, baolu.lu@linux.intel.com, easwar.hariharan@linux.microsoft.com, iommu@lists.linux.dev, jacob.jun.pan@linux.intel.com, joonwonkang@google.com, joro@8bytes.org, jpb@kernel.org, kees@kernel.org, kevin.tian@intel.com, 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 Content-Type: text/plain; charset="UTF-8" > On Tue, May 12, 2026 at 02:51:38PM +0000, Joonwon Kang wrote: > > > Appreciate all your clarifications here. So, my understanding is that if > > our system does not support ST64BV and ST64BV0 or if our device does not > > distinguish between the posted write and the non-posted write regarding > > PASID, then we can lift the use of the global PASID space. Can I say this? > > You should do what Robin said - just have your driver use a per-device > PASID that it allocates and never use the global pasid allocator. > > To do this lightly re-organize the SVA code so the driver can supply > its own PASID, and in this mode we wouldn't activate the ENQCMD > features in the mm. Ah, we could actively disallow EL0 to execute ENQCMD-like instructions when the device driver explicitly shows the intention via a new API like `iommu_sva_bind_device_pasid()` that Tian mentioned earlier. And the new API only uses the per-device PASID space. It makes a lot of sense. It also means that ENQCMD-like instructions are only allowed when the PASID is allocated from the global PASID space. If a process communicates with only one device with the PASID allocated from the per-device PASID space, however, there should be no blocker for the process to execute ENQCMD-like instructions, technically speaking. In this case, should we allow the process to execute them? and later if the process tries to allocate another PASID for another device, should we disallow the instruction execution then? I guess this way may complicate the implementation without much benefit, though. To allocate a per-device PASID, I think we should do it using `dev->iommu_group->pasid_array` instead of making the device driver create its own PASID set since all the devices in the same `iommu_group` are supposed to share the same PASID space. Will create a new patch with the establishment so far. Thanks, Joonwon Kang