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 73D00C30653 for ; Mon, 24 Jun 2024 19:52:00 +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=a/ily8zf1tNre6lVxEBeVHCfF/n+Ja8rvulfaJ3WRUQ=; b=oY02Lh2hQauoW0wL++V0D3uw/u yU71d8ykCvmWmdk0U3jCPRY2plwEmQZlMBIXhRQDn/KD3tv2MS1dV21jLcALs10Pn1QMGg/9zunHy Vb+O0vVKNuWpcTUsmrGtsegAQrmEHQPo9UyTp507l3zdZa23M5korZ7/hHv9JynHL+7X5kyztSwyK wT0/I4ax1S1npf9DLqBtXc4OyOrK6i2Tv+4r7G245iqFi6QBFwD08P8yDZ8VjfeAHnHfXIyX6ISBT g5HV5ZwoCpyNS8DzVAEtlal0Kyabte1GB2QzfGqMvj9Kev7GNdwSAoX363sxSWuxYAMKgOQKOmzAk spq4TM0Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sLpjB-00000000TvI-2lPk; Mon, 24 Jun 2024 19:51:49 +0000 Received: from out-177.mta0.migadu.com ([2001:41d0:1004:224b::b1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sLpj5-00000000TuJ-3q1r for linux-arm-kernel@lists.infradead.org; Mon, 24 Jun 2024 19:51:45 +0000 X-Envelope-To: seanjc@google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1719258702; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=a/ily8zf1tNre6lVxEBeVHCfF/n+Ja8rvulfaJ3WRUQ=; b=qGYwucPWKDCqh/dFigzwobI4DeD5oo95P6PExM/FKc4f+duoEbiRNtqreNlECzap2I3xCQ v4hlHuuNz9//plF3i1SFKohXnx5n9xIscUujSCTA6QwZjdLjqMsspRotEF3v9geC6VSRHY T6fucsBfDelkh6doVRdWKflCAggG9nk= X-Envelope-To: jgg@ziepe.ca X-Envelope-To: shameerali.kolothum.thodi@huawei.com X-Envelope-To: kvmarm@lists.linux.dev X-Envelope-To: iommu@lists.linux.dev X-Envelope-To: linux-arm-kernel@lists.infradead.org X-Envelope-To: linuxarm@huawei.com X-Envelope-To: kevin.tian@intel.com X-Envelope-To: alex.williamson@redhat.com X-Envelope-To: maz@kernel.org X-Envelope-To: will@kernel.org X-Envelope-To: robin.murphy@arm.com X-Envelope-To: jean-philippe@linaro.org X-Envelope-To: jonathan.cameron@huawei.com Date: Mon, 24 Jun 2024 12:51:34 -0700 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Sean Christopherson Cc: Jason Gunthorpe , 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, 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: 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> <20240624180148.GV791043@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240624_125144_180356_99203C66 X-CRM114-Status: GOOD ( 24.51 ) 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 12:29:07PM -0700, Sean Christopherson wrote: > On Mon, Jun 24, 2024, Oliver Upton wrote: > > On Mon, Jun 24, 2024 at 03:01:48PM -0300, Jason Gunthorpe wrote: > > > If KVM can change VMID on the fly then that is a further complication > > > :\ > > Ya, as written today, KVM doesn't assign a VMID when the VM is created, and instead > allocates VMIDs on-demand when a vCPU is run. > > The KVM changes in this series allow "pinning" the currently assigned VMID, i.e. > tries to address that further complication. But because of the on-demand > allocation, there might not be a currently assigned VMID for VM, or the VMID might > be stale, i.e. re-assigned to a different VM. > > Thus, kvm_arm_pinned_vmid_get() can effectively trigger VMID allocations, and > thus cgroup charging and failure. > > If I'm reading the ARM code correctly, the intent is to cycle through VMIDs as > necessary so that it's possible for every actively running VM to have a VMID. > And maybe also to also minimize the number of TLB + I$ invalidations? The commentary about TLBIs + I$ invalidations is in relation to how rollover is handled. The kernel's ASID allocator does some deferred invalidation, the VMID allocator does some eager invalidation at rollover because it is believed to be a rarer occurrence. But generally speaking, it's what you expect, we have some structures in hardware that use VMID to form a tag, and we wnat to avoid blasting them if at all possible. > > > > > > > Hmm, kvm_arm_pinned_vmid_get() doesn't fail, it just falls back to VMID=0. Which > > > > seems odd. > > > > This is bleeding a bit of implementation detail where VMID=0 is known to > > be reserved (thus invalid), it'd probably be better if the > > implementation actually just returned an error. > > Oof, I assumed using VMID=0 just caused a loss of performance, but this makes > it sound like the IOMMU mappings will fault? Bit worse than that :) Having the SMMU participate in broadcast TLB maintenance means TLBI instructions on the CPU invalidate translations in the SMMU, which is useful for SVA usecases. However, if the host is using different VMIDs for the CPU and SMMU, then guest TLBIs no longer match the guest's SMMU context... Pinning / sharing the VMID between CPU and SMMU is a hard requirement if you advertise BTM support to the guest. -- Thanks, Oliver