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 F06FBC433F5 for ; Thu, 30 Sep 2021 17:26:44 +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 AA7FE61262 for ; Thu, 30 Sep 2021 17:26:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AA7FE61262 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com 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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8hHqBfIozlGadYsvBM7iKDevnCx5djkWvXxy72m2CXE=; b=1CvBjAiaobj3/n t1N0aJC+k+Lu3kmy55xNIp5iaSeZV90syD+c3YuWFrla7kbYb5Rl8Fc4H6mxY28+bEfvBoRT2A30a zGDrbbwaWl1axa4E+hTpMS586851giMntnXQj8UBSx21R9Qz/Xw47y8B4ZVFDXGU43Gydt5VgsaUR X4qRLZeBpcK+Sb9aexKyJvBVaHf5n2gFKL2SBc/sxxWPu9KZXF959AKfcPOx/5OWos1+Gmvldu8P5 Fx9MrFSDZZHVblCkDtbbcPtmCYuzWpqZW1eLGtH0Z8BvTmQhX8FybVyEu/Sp3++8sLgtddeOJRmqN echgK+fKw3PzXip+YDcg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVznX-00FML9-M2; Thu, 30 Sep 2021 17:24:44 +0000 Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVznQ-00FMJZ-SH for linux-arm-kernel@lists.infradead.org; Thu, 30 Sep 2021 17:24:38 +0000 Received: by mail-lf1-x12a.google.com with SMTP id j5so23550813lfg.8 for ; Thu, 30 Sep 2021 10:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IOus6RZAODeflkitNKNtNRm/hVuYigDJWYb8TVA+haU=; b=D2uC1NpXnCez3Ytp4VABnJkvuhi+0CS1VaFTV4avogW3x4OrLuLLvWQMiRKr1WKS4j PTcaPWmLAuGANDqHrTiVVzKCY9yfkwlb8WF6Tf+gfa3rZe5IEYkji7+xmGl3rOEYvXJW b5Sk2IDU4tM0PNkXD2K9uOT9iGAlVWXGtu/xvJUhdVEf1oEVw79VV3xiqTZJ6GPco5Hj qI41SIPc3djWuAzkAyNJtK2/wFu3txyPfUazgTIrYiidLHB31U5f7cuCCV1DDN0mNPyT Ayftn5S5JLoPEABEMCy6hvZqZX0QfyiS0qtlyoTlroaVcP740VEQqqWnj8H9ezw/JFos Z8IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IOus6RZAODeflkitNKNtNRm/hVuYigDJWYb8TVA+haU=; b=Mi2juVTv3TczneNh4rVDI2vFAL02RG0lOYxn5ojW53MnByrHF0Z3/zyCcpG9A+a3Uw vajRvWA8ESeg1x13oEMBglTkCV8evL9NrY/co1FYKGdAxTErko5uAPVoEDLTOAOR01aN 4aYtrDaF7xhKYAIRZuNu2HWp4gP4egSOJ+zE1Be8rpCabY/OwK/WrFq3aK71MNBd0Xzt CdWBjIQI6VPAnvxhFHkO/rRi/TBRP6qT0HFt7aHa8NQaHC7u3lt0K00eQ3hpPN776s7y 7lkbR1QPPe0FjAC5smQzPRYqOe30WOuxCBDzMvpundSKuZmDTOpcO+2EG8fEIg0aCRFY QOCw== X-Gm-Message-State: AOAM532Q4ZGNBPrLbqvsZXysbbdfqyQZIpyu5yvCNgshpL1dAPe9QLdH vKOhUO65Ot2w/J5SoCpglunHfRawyD8YnUa/TfN97A== X-Google-Smtp-Source: ABdhPJwfSVC7//d6/e+fZoayLkD2H1zJPhp0sz/K7FbaHBHjYfcsEHPJ7CByH+JJAViNtjzQ2spoMMRGnDDx4TU0YSE= X-Received: by 2002:a2e:95cc:: with SMTP id y12mr7165903ljh.337.1633022674911; Thu, 30 Sep 2021 10:24:34 -0700 (PDT) MIME-Version: 1.0 References: <87mtp5q3gx.wl-maz@kernel.org> <87fsuxq049.wl-maz@kernel.org> <20210825150713.5rpwzm4grfn7akcw@gator.home> <877dg8ppnt.wl-maz@kernel.org> <20210827074011.ci2kzo4cnlp3qz7h@gator.home> <87ilyitt6e.wl-maz@kernel.org> In-Reply-To: <87ilyitt6e.wl-maz@kernel.org> From: Oliver Upton Date: Thu, 30 Sep 2021 10:24:23 -0700 Message-ID: Subject: Re: KVM/arm64: Guest ABI changes do not appear rollback-safe To: Marc Zyngier 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210930_102436_971665_07B8E3F6 X-CRM114-Status: GOOD ( 33.95 ) 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 Hey Marc, On Thu, Sep 30, 2021 at 12:32 AM Marc Zyngier wrote: > > 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. Supposing we don't preallocate some hypercall ID registers, how can we safely migrate a guest from an older kernel to newer kernel? Ideally, we would preserve the hypercall feature set across the migration which could work for a while with the first set of registers that get defined, but whenever a new hypercall firmware register comes along then the VMM will be clueless to the new ABI. Fundamentally, I don't think userspace should need a patch to preserve ABI on a newer kernel. Despite that, it would seem that userspace will need to learn of any firmware registers that control hypercall features which come after the initial set that gets proposed. If KVM_GET_REG_LIST were to disambiguate between ID registers (hypercall, architectural feature ID registers) from other parts of the vCPU state, it would be clear to what registers to zero on a newer kernel. Apologies if it is distracting to mention the feature ID registers here, but both are on my mind currently and want to make sure there is some consistency in how features get handled on newer kernels, architected or not. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel