From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E0507CDD1B2 for ; Fri, 27 Sep 2024 14:24:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=hhj4ZQ6Xld1eIudfd0RTNxx6Jiz8E1lbDuETxH/nQZM=; b=pt3jx52EfgW7+ftgWW6LqWMK2J Chob1VXJNBSkcnUzt/KLghh3MmIHsjroSbrAN4gKUJoUMI0vXul2GTDendYx9w37LH/0iauYl2CW+ 0s+N6pJJ7Ki+z3gAuSWEWziNO5Kxz7JkCm4RjTadvBLsv/q0EdHldW5ByoHH520o/j5zdGTZWTylt q5PW+OnyvRUQgZ/yUNToPjTAitjGrXI6U3eVZ0AqGmCBGKnR8c9Dd1c+UrleR2DYl5SADXGRB/kwA f5ojYrKr2abLWOhaSgv+b3j/b0/SstSB7blniJoi6qLaU/eg/7zAYX0QK8C9E+ZHqYOTBd6v6WQ19 Y2SQ6kVQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1suBt9-0000000BSQl-37NS; Fri, 27 Sep 2024 14:24:07 +0000 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1suBrW-0000000BRwT-3Ige for linux-arm-kernel@lists.infradead.org; Fri, 27 Sep 2024 14:22:28 +0000 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-42cb1dd2886so259875e9.0 for ; Fri, 27 Sep 2024 07:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1727446945; x=1728051745; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=hhj4ZQ6Xld1eIudfd0RTNxx6Jiz8E1lbDuETxH/nQZM=; b=SvjB8NGqeUHPkClueMr9uCmzbhbATq9Vz3FjGBYUQb2grvKEpcTlPbVAsojdD7IvY+ nxbYdLRYwGpZq7O8uSW9gufhw5xWTC2DHFg7iIzK910xUB+CNW1Of5k8rV84vPPaAC+I Kq02MGpwPDKOAkQT+MP7DKf/lRhI8d1nsYADHZJz75XT8h84ziY17DsiW+XYLy3mm7BR zoYFL0D5ENhlHAos1hjHacgNabY1QyOB8aK/8/HUfjD5HIEB0KQ8Yb5ZcFvEwes+yRQu C9hiEjuVMKtBehlCXi/1SaFjciMlLMydAzASAJKzHM/w36naPnR70Ww6vl5xORpV96FI RmNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727446945; x=1728051745; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hhj4ZQ6Xld1eIudfd0RTNxx6Jiz8E1lbDuETxH/nQZM=; b=vwQrcmrpL4j2PCVkFF98WSyF2haOvv9kxG0FNn7xBDIViJ92cledF5ToLJVPsjT2k1 RyRPMKUc+jlHMOBX5GFvZsrQdcypWhKa4vIY+mVx3DiwOJGoTyj01lUERNa1A8RNJrhN HSS+8e0kL1dlRl2pFRSbkmKnJerRdc2ntUZFTjMeXcS6IljLlMUHngUlkTm0Xw8i5zI+ 4pk3Ir6XMYGoOvUHsB0QGvnXV7wWTJqN4QRtEzTwNWfyWX2xOiFfEF0fJNdkoIgynmm8 3ClXt/D2ZJcFZXsgjP8fMbQVYMdA2fxYemHTlVf+WnzykEBT3z4Yk+I2D5LHLCqC+azX lbSw== X-Forwarded-Encrypted: i=1; AJvYcCVVJ2coUVILi48t6h0IN2c0Q3qFWd+3WPR1rUe5b5RSSBJE58Deo1COIwXpKkcK5jH5/DkDE8WUyBaCR16mr2uE@lists.infradead.org X-Gm-Message-State: AOJu0YzP82oTbV/5cVqn9E342/MTwKIrPUZ6BllAS2Fvh/dWm5FxqkY7 JMZuEP+UIbCVB9rYUomRZh99BM+JSLCAfm8i0PLgWGXrEPoxLWgIirKHpglPXA== X-Google-Smtp-Source: AGHT+IEyha9B5v1BC8Ql2C8y6hVRirTJDh8x//Y8F1dggxgjTZk/aBm90T880breDpO4GrzY3E7fHQ== X-Received: by 2002:a05:600c:3d9b:b0:426:7018:2e2f with SMTP id 5b1f17b1804b1-42f59b52c0amr3701145e9.5.1727446944666; Fri, 27 Sep 2024 07:22:24 -0700 (PDT) Received: from google.com (105.93.155.104.bc.googleusercontent.com. [104.155.93.105]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42f57e13944sm28884195e9.30.2024.09.27.07.22.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Sep 2024 07:22:24 -0700 (PDT) Date: Fri, 27 Sep 2024 14:22:20 +0000 From: Mostafa Saleh To: Jason Gunthorpe Cc: Nicolin Chen , kevin.tian@intel.com, will@kernel.org, joro@8bytes.org, suravee.suthikulpanit@amd.com, robin.murphy@arm.com, dwmw2@infradead.org, baolu.lu@linux.intel.com, shuah@kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org, eric.auger@redhat.com, jean-philippe@linaro.org, mdf@kernel.org, mshavit@google.com, shameerali.kolothum.thodi@huawei.com, yi.l.liu@intel.com Subject: Re: [PATCH v2 06/19] iommufd/viommu: Add IOMMU_VIOMMU_SET/UNSET_VDEV_ID ioctl Message-ID: References: <6348cc7a72ce9f2ac0e9caf9737e70177a01eb74.1724776335.git.nicolinc@nvidia.com> <20240927140141.GA4568@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240927140141.GA4568@nvidia.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240927_072226_856846_59E048A9 X-CRM114-Status: GOOD ( 27.65 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Sep 27, 2024 at 11:01:41AM -0300, Jason Gunthorpe wrote: > On Fri, Sep 27, 2024 at 01:50:52PM +0000, Mostafa Saleh wrote: > > > My understanding of IOMMUFD is very little, but AFAICT, that means that > > it’s assumed that each device can only have one stream ID(RID)? > > > > As I can see in patch 17 in arm_smmu_convert_viommu_vdev_id(), it > > converts the virtual ID to a physical one using master->streams[0].id. > > > > Is that correct or am I missing something? > > > > As I am looking at similar problem for paravirtual IOMMU with pKVM, where > > the UAPI would be something similar to: > > > > GET_NUM_END_POINTS(dev) => nr_sids > > > > SET_END_POINT_VSID(dev, sid_index, vsid) > > > > Similar to what VFIO does with IRQs. > > > > As a device can have many SIDs. > > We don't support multi SID through this interface, at least in this > version. > > To do multi-sid you have to inform the VM of all the different pSIDs > the device has and then setup the vSID/pSID translation to map them > all to the HW invalidation logic. Why would the VM need to know the pSID? The way I view this is quite close to how irq works, the VM only views the GSI which is the virtualized number. The VMM then would need to configure vSID->pSID translation, also without knowing the actual pSID, just how many SIDs are there per-device; very similar to how it configures IRQs through VFIO_DEVICE_GET_INFO/VFIO_DEVICE_SET_IRQS. And as long as we only allow 1:1 vSID to pSID mapping, I guess it would be easy to implement. > > Which is alot more steps, and we have no use case right now. Multi-sid > is also not something I expect to see in any modern PCI device, and > this is VFIO PCI... > Ah, I thought IOMMUFD would be used instead of VFIO_TYPE1*, which should cover platform devices (VFIO-platform) or am I missing something? And multi-SIDs is common in platform devices and this would be quite restricting, and I was hoping to support the pKVM vIOMMU through IOMMUFD interface. If possible, can the UAPI be designed with this in mind, even if not implemented now? Thanks, Mostafa > Jason