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 X-Spam-Level: X-Spam-Status: No, score=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48434C4338F for ; Wed, 25 Aug 2021 10:05:07 +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 13DD061163 for ; Wed, 25 Aug 2021 10:05:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 13DD061163 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=N0lNADLjzmNolqyS0FhD/0aNI+huPtdW2cQY0y/z0ZE=; b=pCUth3jTxXSwKn ILO9418ch30qqeqgh4TFjJHiZu/IvJOo/7hgBodS0uLZ8b716Y6tmLz6AerN2CbzfcEPJvgMUcUAM 6yLkrzqru8HwUnerabXEMym++1fZTtlqSeNvPS3KK5BpTVCcOmuJ+fYiL35hprH9Yr4ZMFXZskACp ZeEFAvoujYFD0yg4IFMSw20b4RAeH6tIg+RiGSvVrG8RsqjJdFLcI+Wr5ozlASqb31ULyO6xFXP27 xnKDpbD1iTpwiLtZey83Ws3GIiEZuq8HP2yn0hMqRppO1LkZnRGWMD8mWYm9n4H7ilS9xNR9gPmAO cI55TKMAc4OYj8Iyozkw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIpkN-006KAA-ND; Wed, 25 Aug 2021 10:03:03 +0000 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIpkC-006K0Q-7D for linux-arm-kernel@lists.infradead.org; Wed, 25 Aug 2021 10:02:58 +0000 Received: by mail-lj1-x22e.google.com with SMTP id w4so41126809ljh.13 for ; Wed, 25 Aug 2021 03:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k3coRg+J3p197hAlCFr3Vj1C8Vm9KFllOcMKF9YzS/k=; b=cUCTblyL7c27KuwJuwJwQBvBF+zGyPs1LoT5cyb1NhbCWvEsgHwTS6wl/PEiO303Cw gJJRULtOxqWElvOp/NXfn3kI0QPgq+csxIwej+GRq71MCI3wyIBEn/NSVB5tGFwkPTnf EneqBzFzs7qVMGE6nDOBtyHlV05OrOVkJrrFQRsTt6bN+W3F4qdDcU3CECaFf7f361Bf 1n3XgDV0zWubWVCGgT9pAkYKSmZbCqQ4no8593xoWzxgPxA10aBBCLfWQHVouS8qAIi3 Bn4IfggRl6ekReQHAd5BL0gQO2jxUhFREzZdRfO+rqE3AYViw3ewVvcz8UcBzrbHNc58 Kz0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k3coRg+J3p197hAlCFr3Vj1C8Vm9KFllOcMKF9YzS/k=; b=I/PPROFERtPuB818Dm/11P9h86Fnrx5u42BNXihfLAfb/gl9CPZAq0ifRAmdXsi3vo vQ8XTbk1IDSrnh/Wi2v53bb+tTkxqdpyBAqd0NdX7fRWbG85aMeSdYhsduErXxWW/cCg yg0uVbvnCi5Ff4ziwrgVJ9Eb76Z2EUHoAvwkvE8WOfn3WQHTMRMV1AhCsYj10In6qDUl lMMtWN/yfLCyjD4CvHhhgYHyalmJyJbhvS01wakGOAXjua85M/JqLeqlx5bcTdmHsuPk pa13BJlIGafj3ortw5E+Uv/HDy0y8RdqIQvdu4OtphN47bAY6s/uSTBHpDlumqOYG6D3 TYlA== X-Gm-Message-State: AOAM532U2Sx8jDbJGVWnx/sqVyT2RHAw9F/wZx0+XNs4841QPmujaJmk 7SXO8g5TCdo4FBQDoJF/cocrI49sU07QuGPhcr73wA== X-Google-Smtp-Source: ABdhPJwvsAjsRykTCreTtC16fO1xL5nuWVpWNxzP6GpLgqqYLx9mvjmH2w0HkFOJ93i9pThzDyeIsCSDi55qWS19CpY= X-Received: by 2002:a05:651c:33b:: with SMTP id b27mr36824255ljp.314.1629885759909; Wed, 25 Aug 2021 03:02:39 -0700 (PDT) MIME-Version: 1.0 References: <87mtp5q3gx.wl-maz@kernel.org> In-Reply-To: <87mtp5q3gx.wl-maz@kernel.org> From: Oliver Upton Date: Wed, 25 Aug 2021 03:02:28 -0700 Message-ID: Subject: Re: KVM/arm64: Guest ABI changes do not appear rollback-safe To: Marc Zyngier Cc: 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, Drew Jones , Peter Maydell X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210825_030252_328634_3BA75965 X-CRM114-Status: GOOD ( 28.63 ) 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 On Wed, Aug 25, 2021 at 2:27 AM Marc Zyngier wrote: > > Exposing new hypercalls to guests in this manner seems very unsafe to > > me. Suppose an operator is trying to upgrade from kernel N to kernel > > N+1, which brings in the new 'widget' hypercall. Guests are live > > migrated onto the N+1 kernel, but the operator finds a defect that > > warrants a kernel rollback. VMs are then migrated from kernel N+1 -> N. > > Any guests that discovered the 'widget' hypercall are likely going to > > get fussy _very_ quickly on the old kernel. > > This goes against what we decided to support for the *only* publicly > available VMM that cares about save/restore, which is that we only > move forward and don't rollback. Ah, I was definitely missing this context. Current behavior makes much more sense then. > Hypercalls are the least of your > worries, and there is a whole range of other architectural features > that will have also appeared/disappeared (your own CNTPOFF series is a > glaring example of this). Isn't that a tad bit different though? I'll admit, I'm just as guilty with my own series forgetting to add a KVM_CAP (oops), but it is in my queue to kick out with the fix for nVHE/ptimer. Nonetheless, if a user takes up a new KVM UAPI, it is up to the user to run on a new kernel. My concerns are explicitly with the 'under the nose' changes, where KVM modifies the guest feature set without userspace opting in. Based on your comment, though, it would appear that other parts of KVM are affected too. It doesn't have to be rollback safety, either. There may simply be a hypercall which an operator doesn't want to give its guests, and it needs a way to tell KVM to hide it. > > Have I missed something blatantly obvious, or do others see this as an > > issue as well? I'll reply with an example of adding opt-out for PTP. > > I'm sure other hypercalls could be handled similarly. > > Why do we need this? For future hypercalls, we could have some buy-in > capabilities. For existing ones, it is too late, and negative features > are just too horrible. Oh, agreed on the nastiness. Lazy hack to realize the intended functional change.. > For KVM-specific hypercalls, we could get the VMM to save/restore the > bitmap of supported functions. That would be "less horrible". This > could be implemented using extra "firmware pseudo-registers" such as > the ones described in Documentation/virt/kvm/arm/psci.rst. This seems more reasonable, especially since we do this for migrating the guest's PSCI version. Alternatively, I had thought about using a VM attribute, given the fact that it is non-architectural information and we avoid ABI issues in KVM_GET_REG_LIST without buy-in through a KVM_CAP. > 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