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 7B210C5320E for ; Sun, 25 Aug 2024 16:47:47 +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:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID: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=A9Qam1dswHPl6xWtg+DfQChCfW2KmYIrUUYahshLLAw=; b=S6dzWCrUd0DqJAv7J//jUQ20Z8 DXKLzvkQxjdU3HjKR6CBV27U/y5Wfn/CRtrdtYqBygp1CAFLVE2OUbiZOwYmvLuEK7amIU3zEPIs8 gQw5gfUfQAxJE9MQt4CYur/ZbJZgBXp9E1tT2qacaj0nbL2A6FKI79py3Q5ng+pNQVpSrPgDgT+vp N5VoLcQYkJB42APMgVzunhtTs+HMAO5Y4ARLI/1adYsPnnfWmg0uTyTCEDGmBEQJM4m/tQEYISo/S vm04U520UuU4Hm2rQOxJY7W8IeRihUTDl4c2Q2JWRLjsbdDbEuF4sTgEvZXpAOqs9q/KcOTdW+0SO Uu+NClEQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1siGOq-00000004fi5-0A4F; Sun, 25 Aug 2024 16:47:32 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1siGO3-00000004fb4-2BzP for linux-arm-kernel@lists.infradead.org; Sun, 25 Aug 2024 16:46:45 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id D2391CE0ABE; Sun, 25 Aug 2024 16:46:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFFF9C32782; Sun, 25 Aug 2024 16:46:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724604399; bh=ZoCeY/nGvicUbwynsgEk0MCHr1pxhUGttHarltMd2SI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hWjZdXuRTUyYB1URlqmOJ/zJYqVlPvVMAya7LMyigSuhG2hAdd1DGwLhYeH+2U/S/ Upi5M5VQjSixDrsUeuHA5EKmkUQhqJpI0tVzgNwEO90OnBxPe+65VtWjF3tWmXQGDB 4pt8JtXX9u4392jHkqXvv5jXHBFB0LZ+yPDekmuLoUmKwvnskdy8XQxb2aeyq6rR/+ 0/xCsSKjpzkDieAxLxJE1CLtkTHOpW+FVVGBQavEp8cPvICv+6Q3bb/504Iwohvj+g RtuMRRfJg8g0UERzMqCOdGB7gwU88nL53a21o606rFVfdsvDP/WvrBrtt6hvaTlJbP 9W/uF2g2BKCSw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1siGNx-006hAo-54; Sun, 25 Aug 2024 17:46:37 +0100 Date: Sun, 25 Aug 2024 17:46:36 +0100 Message-ID: <86ttf8wnwz.wl-maz@kernel.org> From: Marc Zyngier To: Shaoqin Huang Cc: Oliver Upton , kvmarm@lists.linux.dev, Mark Brown , Eric Auger , Sebastian Ott , Cornelia Huck , Catalin Marinas , James Morse , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Paolo Bonzini , Shuah Khan , Suzuki K Poulose , Will Deacon , Zenghui Yu Subject: Re: [PATCH v5 0/4] Allow userspace to change ID_AA64PFR1_EL1 In-Reply-To: <20240723072004.1470688-1-shahuang@redhat.com> References: <20240723072004.1470688-1-shahuang@redhat.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: shahuang@redhat.com, oliver.upton@linux.dev, kvmarm@lists.linux.dev, broonie@kernel.org, eauger@redhat.com, sebott@redhat.com, cohuck@redhat.com, catalin.marinas@arm.com, james.morse@arm.com, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, pbonzini@redhat.com, shuah@kernel.org, suzuki.poulose@arm.com, will@kernel.org, yuzenghui@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240825_094644_156208_1DA21453 X-CRM114-Status: GOOD ( 27.41 ) 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 Tue, 23 Jul 2024 08:19:59 +0100, Shaoqin Huang wrote: > > Hi guys, > > This is another try to allow userspace to change ID_AA64PFR1_EL1, and we want to > give userspace the ability to control the visible feature set for a VM, which > could be used by userspace in such a way to transparently migrate VMs. I think this looks OK now, thanks for going through the motions and doing the right thing. What is missing is similar handling for 32bit ID registers, but I'm not sure we keen on going down that road -- machines capable of running those are on their way out. This can be done later anyway, should anyone care. > > The patch series have four part: > > The first patch disable those fields which KVM doesn't know how to handle, so > KVM will only expose value 0 of those fields to the guest. > > The second patch check the FEAT_SSBS in guest IDREG instead of the cpu > capability. > > The third patch allow userspace to change ID_AA64PFR1_EL1, it only advertise the > fields known to KVM and leave others unadvertise. > > The fourth patch adds the kselftest to test if userspace can change the > ID_AA64PFR1_EL1. > > Besides, I also noticed there is another patch [1] which try to make the > ID_AA64PFR1_EL1 writable. This patch [1] is try to enable GCS on baremental, and > add GCS support for the guest. What I understand is if we have GCS support on > baremental, it will be clear to how to handle them in KVM. And same for other > fields like NMI, THE, DF2, MTEX.. At that time, they can be > writable. I expect that Broonie would look into this as part of his series. Thanks, M. -- Without deviation from the norm, progress is not possible.