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 23748CE7AA3 for ; Fri, 6 Sep 2024 11:33:35 +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=Udbu1uIWP4j4MINPqgqM58X+79eAgEAS4xRqqOQw2xU=; b=K7BBfOxVXM/4Vhncpp18eD8SJh Ss8q7nb6tC+kt93BvhdXWW9Bqy2HEDYQr9QnHq/BSWwQFDXw32smME2PIKU3K10+a5hxtX20v1Ttr iKGJcSHtySpbMgaJAwmY8b6jHHZdqMc7v/TjTN5oj2suWU9yxcS/uoEpGrYBIeRRrLNZ4ISjkQGF7 2IpkodzcFM7tkJ46+YITpl2G+3urMnqDIsfsAwDl03epjRKdpTPtfFRSljmiRA4R15ExjDyfN1ovA mlcJIWFLcEfsHjTmz0nXWqKgg1PM6uwtaNhENXKOE1ALQiLVdo+HesigY53s7FNCTKQCYACZ76TP/ B564buEg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1smXDQ-0000000BzyH-0xGl; Fri, 06 Sep 2024 11:33:24 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1smX08-0000000Bwdv-082U for linux-arm-kernel@bombadil.infradead.org; Fri, 06 Sep 2024 11:19:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=Udbu1uIWP4j4MINPqgqM58X+79eAgEAS4xRqqOQw2xU=; b=MzsflOWI+vH85EVgwCitBF3s+T 016kg+F46dxB4bwhP5Wsu9I1HQ8fo+WYsOpTwjFZ7nbbw++nmFkqEIWosevcDUDxj1jZA0W2iAvSj k4CxotkJFO33GTJptBL8vXjMiZrmxoorzDZEXLxz3TCyuOuvQ4fvhxdUM3Af/F1sMD2Kw/K/byW4T xO/n/pZi3QCjqwaRumg0vSCfn3fRv3t7zzgEAmi1lWVQSdCK3ZnlrIRq79HdZBJgkQ1IitrAXGrlA lCBS2Hlx7Gd5f7SAEQWU4A1iIdZb/L6iLh1LBCWMQ6W7SpLFGBZP2nffpCX8JdWfG6y61FX8UOXrZ wcPj5cYg==; Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]) by desiato.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1smX00-00000000eHx-1goZ for linux-arm-kernel@lists.infradead.org; Fri, 06 Sep 2024 11:19:37 +0000 Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-427fc9834deso36555e9.0 for ; Fri, 06 Sep 2024 04:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725621565; x=1726226365; 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=Udbu1uIWP4j4MINPqgqM58X+79eAgEAS4xRqqOQw2xU=; b=xjxAXa16VrpZtc4AC+870Qa1JgyHbT9VEtw44dAASieYg80lSi7wqFqwxZxk21kF9Q Hh2U3P9doqSUetPVPh1SIqXMm2kSzZkVT2n775QSmj6VTiLCS2UodY0vPDZMrXm1BsND OjQ6+OnNtUpyIK/zDCUPt7WCzzRu3xuHUcH8qdAgZZGUeHwwNKmUvhp22oGGaQhKcgq6 Q3Bvd+ovg4ksGDV/mu9Su2i1KSqXUK5TXPi7OIZnr5ewfPg97HoU4rq9swoJIvpowkx/ EDmZ2S4P76TbqIGg/nSng1/pXZ9yo45dizA/FOQ37Fj8t7pxVL/sekDbUp4+H2amnXG5 9cqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725621565; x=1726226365; 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=Udbu1uIWP4j4MINPqgqM58X+79eAgEAS4xRqqOQw2xU=; b=AyW4546ckk4tFBDOiU1yaFuLq97bj5K5i0VdxNl2Ko0o4YvWQuhxB9ADcVY0L5ZiZ/ JcQ8htdkAcebHUiQhfR6oQPbvnUjO5UGqHcGTK8uZ6YELOHDgnZJ/yrkJUOr1GB3DMHh R6NtFfb9OY+5rwJ6pDF0Qaq1oENrfV0Eg8ernwGvbT6LB0ihZ+bPak8OsNY1nhvKHI1p DOQ6Q5LkUXKOJPgHCGG362QQ3r/Ekd3dAqiku4IcGcW72pnazvYM97PgBVFfz/pKRSVu 7Y3PpyuRgT01ruTTfQ70EWKW/isdghRfI/Av7YDqPX3ia0eV9O6B2FgW5uiYKjhRY+pJ W/mA== X-Forwarded-Encrypted: i=1; AJvYcCU8tcYgqNr8TsuuxWZ9Ee2EyNh4L4UWyGZVpRb55b7FgtjvoZGNeSvq0NYvvV9hAXFHHldFyOzMB38j5e9bFyLp@lists.infradead.org X-Gm-Message-State: AOJu0Yxq2j1wRe2lX1J5v0qVRk3f4ST4ErhYIXFVQHVSeV+tbrmr26Zs SHpfDaqbVxmERmNaHYZO7QG6xn5NDVL4oV+0c4UBRjIc9ibhmOzb9aOdGIOEDA== X-Google-Smtp-Source: AGHT+IF28frk+mNvBQvzqNFR1XDVIRQtdpQ86tusQ1uuAu2EpW1M17z6bTXUWoFUjfxKXzcEdY+eFA== X-Received: by 2002:a05:600c:cc3:b0:42c:9e35:cde6 with SMTP id 5b1f17b1804b1-42ca0592bbemr713575e9.2.1725621564295; Fri, 06 Sep 2024 04:19:24 -0700 (PDT) Received: from google.com (109.36.187.35.bc.googleusercontent.com. [35.187.36.109]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42ca05ca63bsm17229795e9.12.2024.09.06.04.19.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Sep 2024 04:19:23 -0700 (PDT) Date: Fri, 6 Sep 2024 11:19:20 +0000 From: Mostafa Saleh To: Jason Gunthorpe Cc: Shameerali Kolothum Thodi , "acpica-devel@lists.linux.dev" , "Guohanjun (Hanjun Guo)" , "iommu@lists.linux.dev" , Joerg Roedel , Kevin Tian , "kvm@vger.kernel.org" , Len Brown , "linux-acpi@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Lorenzo Pieralisi , "Rafael J. Wysocki" , Robert Moore , Robin Murphy , Sudeep Holla , Will Deacon , Alex Williamson , Eric Auger , Jean-Philippe Brucker , Moritz Fischer , Michael Shavit , Nicolin Chen , "patches@lists.linux.dev" Subject: Re: [PATCH v2 6/8] iommu/arm-smmu-v3: Support IOMMU_GET_HW_INFO via struct arm_smmu_hw_info Message-ID: References: <0-v2-621370057090+91fec-smmuv3_nesting_jgg@nvidia.com> <6-v2-621370057090+91fec-smmuv3_nesting_jgg@nvidia.com> <20240830171602.GX3773488@nvidia.com> <20240903001654.GE3773488@nvidia.com> <20240903234019.GI3773488@nvidia.com> <9e8153c95b664726bd7fcb6d0605610a@huawei.com> <20240904120103.GB3915968@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240904120103.GB3915968@nvidia.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240906_121933_910866_FD551A83 X-CRM114-Status: GOOD ( 25.93 ) 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 Wed, Sep 04, 2024 at 09:01:03AM -0300, Jason Gunthorpe wrote: > On Wed, Sep 04, 2024 at 07:11:19AM +0000, Shameerali Kolothum Thodi wrote: > > > > On Tue, Sep 03, 2024 at 08:34:17AM +0000, Mostafa Saleh wrote: > > > > > > > > > For example, KVM doesn’t allow reading reading the CPU system > > > > > > registers to know if SVE(or other features) is supported but hides > > > > > > that by a CAP in KVM_CHECK_EXTENSION > > > > > > > > > > Do you know why? > > > > > > > > I am not really sure, but I believe it’s a useful abstraction > > > > > > It seems odd to me, unpriv userspace can look in /proc/cpuinfo and see > > > SEV, why would kvm hide the same information behind a > > > CAP_SYS_ADMIN/whatever check? > > > > I don’t think KVM hides SVE always. It also depends on whether the > > VMM has requested sve for a specific Guest or not(Qemu has option to > > turn sve on/off, similarly pmu as well). Based on that KVM > > populates the Guest specific ID registers. And Guest /proc/cpuinfo > > reflects that. > > > > And for some features if KVM is not handling the feature properly or > > not making any sense to be exposed to Guest, those features are > > masked in ID registers. > > > > Recently ARM64 ID registers has been made writable from userspace to > > allow VMM to turn on/off features, so that VMs can be migrated > > between hosts that differ in feature support. > > > > https://lore.kernel.org/all/ZR2YfAixZgbCFnb8@linux.dev/T/#m7c2493fd2d43c13a3336d19f2dc06a89803c6fdb > > I see, so there is a significant difference - in KVM the kernel > controls what ID values the VM observes and in vSMMU the VMM controls > it. Yes, that’s for guests. What I meant is that the host sysregs are not read from userspace which is the synonym of reading SMMUv3 IDRs from userspace, instead the kernel controls what features are visible to userspace(VMM) which it can enable for guests if it wants, as SVE, MTE... Thanks, Mostafa > > Jason