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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40726C433EF for ; Thu, 30 Sep 2021 07:34:14 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 1085E61265 for ; Thu, 30 Sep 2021 07:34:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1085E61265 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=yANrtbpMs++sKr2kv1yi8Wox4eeLnj9QISQ8ztZDvK8=; b=JzUc3byfR1VTYB rg9oBDilg2QDTiBNjhf/4annji/wICfwsFa1DvamPf1qYyExhHtwH4dvfxJDUWAPUVCvh9dswQOew 7y6HIeYSbNX431HRwfkUOdOOux5yM7bcNoLBiLh+evCOYSfvzhy2SxtCXMSTGxmkgy8AyyKyq5Abw uuJog7TQmnv0lc6OKyNpEGYAFBikDxWov0IiC6cH/CmuvCWEcBUEuoBwydJUCzPOwL8AQ9PNndlhw 5Jgy6IjvnoDnQAdPGsZo5t8FiswPE3a/xwE5iRZR3N2QesHWnU3AlQaZox3KT7YIy6R9SdQ3gJ8qI qsROIDiUQlUmryM62U2g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVqYS-00DCcG-9v; Thu, 30 Sep 2021 07:32:32 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVqYO-00DCbS-IC for linux-arm-kernel@lists.infradead.org; Thu, 30 Sep 2021 07:32:30 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EFAE4613A6; Thu, 30 Sep 2021 07:32:27 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mVqYL-00DtzK-V8; Thu, 30 Sep 2021 08:32:26 +0100 Date: Thu, 30 Sep 2021 08:32:25 +0100 Message-ID: <87ilyitt6e.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: Andrew Jones , kvmarm@lists.cs.columbia.edu, pshier@google.com, ricarkol@google.com, rananta@google.com, reijiw@google.com, jingzhangos@google.com, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com, Alexandru.Elisei@arm.com, suzuki.poulose@arm.com, Peter Maydell Subject: Re: KVM/arm64: Guest ABI changes do not appear rollback-safe In-Reply-To: References: <87mtp5q3gx.wl-maz@kernel.org> <87fsuxq049.wl-maz@kernel.org> <20210825150713.5rpwzm4grfn7akcw@gator.home> <877dg8ppnt.wl-maz@kernel.org> <20210827074011.ci2kzo4cnlp3qz7h@gator.home> 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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oupton@google.com, drjones@redhat.com, kvmarm@lists.cs.columbia.edu, pshier@google.com, ricarkol@google.com, rananta@google.com, reijiw@google.com, jingzhangos@google.com, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com, Alexandru.Elisei@arm.com, suzuki.poulose@arm.com, peter.maydell@linaro.org 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-20210930_003228_651596_EBB8F52C X-CRM114-Status: GOOD ( 22.69 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Oliver, On Wed, 29 Sep 2021 19:22:05 +0100, Oliver Upton wrote: > > I have some lingering thoughts on this subject since we last spoke and > wanted to discuss. > > I'm having a hard time figuring out how a VMM should handle a new > hypercall identity register introduced on a newer kernel. In order to > maintain guest ABI, the VMM would need to know about that register and > zero it when restoring an older guest. Just as it would need to be able to discover any new system register exposed by default, as it happens at all times. Which is why we have a way to discover all the registers, architected or not. > Perhaps instead we could reserve a range of firmware registers as the > 'hypercall identity' registers. Implement all of them as RAZ/WI by > default, encouraging userspace to zero these registers away for older > VMs but still allowing an old userspace to pick up new KVM features. > Doing so would align the hypercall identity registers with the feature > ID registers from the architecture. The range already exists in the form of the "coprocessor" 0x14. I don't see the need to expose it as RAZ/WI, however. If userspace doesn't know about how this pseudo-register works, it won't be able to program it anyway. I don't buy the parallel with the ID-regs either. They are RAZ/WI by default so that they don't UNDEF at runtime. The meaning of a RAZ id-register is also well defined (feature not implemented), and the CPU cannot write to them. In a way, the ID-regs *are* the enumeration mechanism. Our firmware registers don't follow the same rules. Userspace can write to them, and there is no such "not implemented" rule (case in point, PSCI). We also have a separate enumeration mechanism (GET_ONE_REG), which is (more or less) designed for userspace to find what is implemented. For these reasons, I don't immediately see the point of advertising a set of registers ahead of time, before userspace grows an understanding of what these registers mean. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel