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 2E1ECC433EF for ; Tue, 25 Jan 2022 08: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: 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=CBpiJA30YpGvMvUXYAwd60Qr6AiPPCqhr6IDnIOZk3Y=; b=F7gqch3U1+25lR NiVwfTSLphMY2BCtIUx2GEFu3JZxecFr4uBn9LSwYr8/ge+6YeDi9jo8PkU4pSjlRnpEopMdQaLnq Cvw2DcLOFwZkVY69YoR/pB563Ekv2GIc2J2FlC+odJ6L2FR9PB9haktcMyM6ws/fIOAMY8rSfk5Vw eWIfQEF6SMUis2Ud3r/O717jgZl/3+PqF19VKQijti69joepzgStvfSR+J14zMD/NnkbyjnR0Mgg4 iIqVe3sZ8Vge+5TUOTNx3IShDe666hLLSk7G09jTjDDtSG24daF8uR54YE4rRxn3n4iW4bLlAQOML yJ+ywyGv4RMMdAuh/fdg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCHSl-006t32-3u; Tue, 25 Jan 2022 08:46:03 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCHSh-006t2e-32 for linux-arm-kernel@lists.infradead.org; Tue, 25 Jan 2022 08:46:00 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 94DBD6134F; Tue, 25 Jan 2022 08:45:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01173C340E0; Tue, 25 Jan 2022 08:45:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643100358; bh=o5P0EESqXEiVqLSm7A8kn65YVJDoZnbdLQ/5TGwA6to=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AEtTFdCq0bI0DCfv/5Ls9NQG93g5YJ6Wf4Anx9xGjdianL5hrM0D8s78lGOPZpcua Jz7jRQoGPJpvOj4PQGRIcZLoLTAaNvIcwkMabkmepjehhkJ0tDkfFoPTYLxkM6+lpb jY8WJmEPoc0K38vP0kZHAI/5sVgVkII2ysOPVqHKx9crzpGxy6I9LZd+TnrxsT6HUB eKiGfDJ/ZoJS/4AgjESgdGMTBKJL5Pjc3CwEjs0xAiKY13k8PWO+nNdyYMtJEfrwYX 1ecGC968iT2a1uHckwxaq6i7ICowBvjzkqMFcwgDtXuXW/oXopeQgA3EWfh0DgPPPH Kj04X7tpRdPxw== 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 1nCHSd-002nE7-CG; Tue, 25 Jan 2022 08:45:55 +0000 Date: Tue, 25 Jan 2022 08:45:54 +0000 Message-ID: <875yq88app.wl-maz@kernel.org> From: Marc Zyngier To: Raghavendra Rao Ananta Cc: Andrew Jones , kvmarm@lists.cs.columbia.edu, pshier@google.com, ricarkol@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 , Sean Christopherson , Oliver Upton 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> <87ilyitt6e.wl-maz@kernel.org> <87lf3drmvp.wl-maz@kernel.org> 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: rananta@google.com, drjones@redhat.com, kvmarm@lists.cs.columbia.edu, pshier@google.com, ricarkol@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, seanjc@google.com, oupton@google.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-20220125_004559_252577_19BFAA9B X-CRM114-Status: GOOD ( 28.52 ) 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 Tue, 25 Jan 2022 03:47:04 +0000, Raghavendra Rao Ananta wrote: > > Hello all, > > Based on the recent discussion on the patch '[RFC PATCH v3 01/11] KVM: > Capture VM start' [1], Reiji, I (and others in the team) were > wondering, since the hypercall feature-map is technically per-VM and > not per-vCPU, would it make more sense to present it as a kvm_device, > rather than vCPU psuedo-registers to the userspace? I really don't think so. > If I understand correctly, the original motivation for going with > pseudo-registers was to comply with QEMU, which uses KVM_GET_REG_LIST > and KVM_[GET|SET]_ONE_REG interface, but I'm guessing the VMMs doing > save/restore across migration might write the same values for every > vCPU. KVM currently restricts the vcpu features to be unified across vcpus, but that's only an implementation choice. The ARM architecture doesn't mandate that these registers are all the same, and it isn't impossible that we'd allow for the feature set to become per-vcpu at some point in time. So this argument doesn't really hold. Furthermore, compatibility with QEMU's save/restore model is essential, and AFAICT, there is no open source alternative. > Granted that we would be diverging from the existing implementation > (psci versioning and spectre WA registers), but this can be a cleaner > way forward for extending hypercall support. Cleaner? Why? How? You'd have the exact same constraints, plus the disadvantages of having to maintain a new interface concurrently with the existing ones. > The kvm_device interface > can be made backward compatible with the way hypercalls are exposed > today, it can have the same registers/features discovery mechanisms > that we discussed above, and majorly the userspace has to configure it > only once per-VM. We can probably make the feature selection immutable > just before any vCPU is created. What is the problem with immutability on first run? Or even with a 'finalize' ioctl (we already have one)? > > Please let me know your thoughts or any disadvantages that I'm overlooking. A device means yet another configuration and migration API. Don't you think we have enough of those? The complexity of KVM/arm64 userspace API is already insane, and extremely fragile. Adding to it will be a validation nightmare (it already is, and I don't see anyone actively helping with it). So no, I have no plan to consider anything but the GET/SET_ONE_REG interface, and until someone writes another open source VMM that has the same save/restore capabilities and proves that this interface isn't fit for purpose, I see no incentive in deviating from a model that is known to work. 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