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 F23C2C2D0D1 for ; Mon, 24 Jun 2024 18:02:10 +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-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=GmIpeWOMkuaph7Wse1udylidw2f4E1g5R0L3+pEMmh8=; b=uppwRkii+bpUqbG1sGrAlBaIZz 7lf8dX3e5u8kQ76J72YpfnjYl7xmiqIWHkrCBfEO5lqWWT9wg0a1MWvV98zjka+pbe3IM+NNdv6zQ QhVt0/8VfF/O7rtrtBrmTp6mxEqUUhni3uJ7e506zwEST/3FhLIucbbhZTwNHgOs2fSOQrPsprbal Ur7IL2mCv0evOJuFTTQ2Av92HUUbY6XYrg7diWxnZw7s/P6Nq9lZWcKuhnyS1xvmR6RE+kwxgtI2g NDkaLhsq4XdaTk90hWqUYFIP8xd68rqGry9/V/EQjwBxX4iD0VU4rTtUL7WNfeHYCTjRHdL1Wok6n 2lTMmj3w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sLo0q-00000000DJJ-3SZB; Mon, 24 Jun 2024 18:01:56 +0000 Received: from mail-qk1-x730.google.com ([2607:f8b0:4864:20::730]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sLo0l-00000000DIF-0Ibq for linux-arm-kernel@lists.infradead.org; Mon, 24 Jun 2024 18:01:52 +0000 Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-79bd2de2157so316447585a.0 for ; Mon, 24 Jun 2024 11:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1719252109; x=1719856909; darn=lists.infradead.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=GmIpeWOMkuaph7Wse1udylidw2f4E1g5R0L3+pEMmh8=; b=MAnYDf0+8XD5JEZ0eETgo4P8AXX4JI00uzoq0fl2JAjw2TM084XYITBK385TVJbRfv yQvndWoeMIPHaeCdj/oBtW0pzprFL6zmCYPwj/Xvd/wiGfo7goyTRYn4P6pUZIVtJ7/w LHbfw5KmprT9DJupKGfdSSX4CKEF745IH0KMOkoAVCL+d55vzF75HVoSRMiqrscwgPs6 LyyrPXxGbJoDdrEZoFh1EzVzcnDzOeTbQLgxdR0z9p7TnkY52gxqFIYNq3dKNaYbqUXY jW4o5cvLzC1eMOG13hn2ycWO8wW51JvPTCTc75dUHciXSfZ6xA/H0EKNC1rtJouAN2hg i+Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719252109; x=1719856909; h=in-reply-to: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=GmIpeWOMkuaph7Wse1udylidw2f4E1g5R0L3+pEMmh8=; b=LmxwMG/0HArOBy2ZtKQHQ325eXRtmeeTjKXk2PygVZB0Kdm1yF7ZYDWL2uikygJ6kO od35Ya6UyuyXDSLIgPjPu8TXTHCnOsV5fXV1yvOmssMBQqtqBXoc+4pXLTB0SKqX76em KlLGWtHakWVQYzkQiVgAH8E9dUq++0wxrqQYrof1wra+e86PIGMFAJE9SaqlXzS9C+sk PsnlXGXE0VsfwEovZ59F46CtQji0mTZR7nWXaA00t4RXH+DBPnaOQFy+qO9voUqJS+bE F167mhlAKXMkKXlL0fl9/sYKxEFYHKiFNgP/T6Htq7xBPdFIhB4PsE92d5WrHQT7XDyB xQuQ== X-Forwarded-Encrypted: i=1; AJvYcCXtsYldXV85zapUuf6XZIBOavSVsjwwS8Uz5Rm49nKFw/Eu37pi44IfChXKd99Mlh6j4MeZi/f1ioGXfwPHs8A5wsmlQJpopjnONj8WK5a+HaIBHrk= X-Gm-Message-State: AOJu0Yyg3xUq8H5raaXY6kOaRE9EyV2IvAGRxoFBD93aNnMWBMqwisZV bT8Mxos21Oe9r0bQ7rukeP+RoCm758iG7cnDvXx7iIF2ksVTkU0zReguHh4SEgs= X-Google-Smtp-Source: AGHT+IFj+SWlMU3kAFGeffbqDksRzMPhWzPlC1lsJ2MKYmQSrom/5Zzv8Cda2KE+V/MbrIeLa8IiIQ== X-Received: by 2002:a05:620a:470b:b0:795:58f1:7808 with SMTP id af79cd13be357-79be6e507d3mr640899185a.22.1719252109417; Mon, 24 Jun 2024 11:01:49 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-68-80-239.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.80.239]) by smtp.gmail.com with ESMTPSA id af79cd13be357-79bcf465449sm328401485a.98.2024.06.24.11.01.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jun 2024 11:01:48 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1sLo0i-006Y8Q-D1; Mon, 24 Jun 2024 15:01:48 -0300 Date: Mon, 24 Jun 2024 15:01:48 -0300 From: Jason Gunthorpe To: Sean Christopherson Cc: Shameer Kolothum , kvmarm@lists.linux.dev, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linuxarm@huawei.com, kevin.tian@intel.com, alex.williamson@redhat.com, maz@kernel.org, oliver.upton@linux.dev, will@kernel.org, robin.murphy@arm.com, jean-philippe@linaro.org, jonathan.cameron@huawei.com Subject: Re: [RFC PATCH v2 4/7] iommufd: Associate kvm pointer to iommufd ctx Message-ID: <20240624180148.GV791043@ziepe.ca> References: <20240208151837.35068-1-shameerali.kolothum.thodi@huawei.com> <20240208151837.35068-5-shameerali.kolothum.thodi@huawei.com> <20240208154210.GP31743@ziepe.ca> <20240624170747.GA1515249@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240624_110151_133677_17FD9C51 X-CRM114-Status: GOOD ( 23.24 ) 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 Mon, Jun 24, 2024 at 10:54:37AM -0700, Sean Christopherson wrote: > > > And assuming that pinnable VMIDs are a somewhat scarce resource, it wouldn't > > > suprise me if someone wanted to add cgroup integration, e.g. similar to the > > > misc cgroup that's used to manage SEV(-ES) ASIDs on KVM AMD (IIUC, an SEV ASID > > > is analagous to an ARM VMID). > > > > Yeah, but if someone is using such a cgroup then I expect they will > > also have an up to date VMM that doesn't trigger this VMID allocation > > in the first place... > > I suspect we're talking about two different things. Either that, or I am really > lost. I mean KVM will have already allocated and charged the cgroup for it's use of the VMID. The IOMMU side just has to match it, no second allocation of a VMID. We wouldn't charge a cgroup for iommu and kvm sharing the same vmid. > > When a KVM is present then the iommu needs to adopt the VMID of KVM, > > and that should have a mechanism to ensure the VMID is valid so long > > as the IOMMU is using it (eg because the KVM FD is open) > > Right, and that's what I'm referring to as "on-demand pinning". For the IOMMU > to adopt a KVM VMID, the VMID needs to be pinned (or KVM would need to notify > the IOMMU every time the VMID changed), i.e. every KVM+IOMMU pair pins a VMID > that is managed by KVM. Ok, right, yes, the expectation is that KVM allocates a VMID at some point and it stays fixed for the life of that kvm. If KVM can change VMID on the fly then that is a further complication :\ > Hmm, kvm_arm_pinned_vmid_get() doesn't fail, it just falls back to VMID=0. Which > seems odd. I had the impression the KVM always had a fixed VMID, but I don't really know. Jason