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 8F04CC636CC for ; Tue, 31 Jan 2023 21:28:10 +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=hXuRjVllvIoBUOt6FGMxpU9TGsp3T+gaR2tRgVoKnLM=; b=ScTV/gw/GvDOBJ qDldfRtWelFnWSZeBqWZNSRn9z3TolqEFpBk5I/TrxqEMnPg/Q9f6WtazYcssQHeecUy2g3fvDH3l xhN4uLO7bMxAkdjIge8R4tWj+cU8ToRJaSt5+n4CbeqLuFdGya9P91Cf+/rTE7eHfDSfv9Da4NUCE 7UsKACHbuVE0yiTa4ykwJKEjVDLKtIQl5T/Be/tvuyeHmLVio2MSFBY+l63R9L2cgv/xTo//JF9Up HdMzlBUCoWJcOgdnlm13NON3coSZ1gBxxv9WUV2BY8SUsnXCiJLCZ9ptP8fg6ezQ1EqId4y5G9BcR ATsb/AuuzGNY6G7odl8Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pMy9e-009P8r-T8; Tue, 31 Jan 2023 21:27:03 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pMy9c-009P8O-1V for linux-arm-kernel@lists.infradead.org; Tue, 31 Jan 2023 21:27:01 +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 67A556153E; Tue, 31 Jan 2023 21:26:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA0ABC433EF; Tue, 31 Jan 2023 21:26:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675200418; bh=9Zg0O6TBm+rTRWrq941GVC7/jc+aBKw/h5KKsoSoJ68=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=T2ZseHNas9jSrcJfRk+s5Q4dk8gXu4K6DCqYWFTEExV5gIBBIrVNyd6xRwxvYRZ5K m/BB3mo8v7DoX7tyF6QwSR1YYhUFxI1b0BtFcYmum9AqGSg2cXlXqIwymxKM6Dy2/E 2hxVTNa/hruJt/CQ9W9x363wUvUTDx+hUWP7etbxfs1rgMdw7B1gDzJD8Hfnq1aXQb M9i+dL+eCvJBM8RzpxjSoH2rk948A6qDlrI6BTJD4ANphmXGpq56AWclWC/e/6bpgK IViPzXh6WQKcv+hyMW0U7nSTEkKGTOvCykHFU5nshO7H4AAvO7ykFRKp7cOmG2L1qO zEkZnkF5Hofpw== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.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 1pMy9Y-006KPL-FC; Tue, 31 Jan 2023 21:26:56 +0000 Date: Tue, 31 Jan 2023 21:26:56 +0000 Message-ID: <871qnae6ov.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: Suzuki K Poulose , kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Alexandru Elisei , Andre Przywara , Chase Conklin , Christoffer Dall , Ganapatrao Kulkarni , Jintack Lim , Russell King , James Morse , Zenghui Yu Subject: Re: [PATCH v8 01/69] arm64: Add ARM64_HAS_NESTED_VIRT cpufeature In-Reply-To: References: <20230131092504.2880505-1-maz@kernel.org> <20230131092504.2880505-2-maz@kernel.org> <86cz6u248j.wl-maz@kernel.org> <3c15760c-c76f-3d5d-a661-442459ce4e07@arm.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/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: oliver.upton@linux.dev, suzuki.poulose@arm.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, alexandru.elisei@arm.com, andre.przywara@arm.com, chase.conklin@arm.com, christoffer.dall@arm.com, gankulkarni@os.amperecomputing.com, jintack@cs.columbia.edu, rmk+kernel@armlinux.org.uk, james.morse@arm.com, 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-20230131_132700_205281_0497C74C X-CRM114-Status: GOOD ( 29.61 ) 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, 31 Jan 2023 20:04:15 +0000, Oliver Upton wrote: > > On Tue, Jan 31, 2023 at 05:34:39PM +0000, Suzuki K Poulose wrote: > > On 31/01/2023 14:00, Marc Zyngier wrote: > > [...] > > > > What is exactly the objection here? NV is more or less a VHE++ mode, > > > but is also completely experimental and incomplete. > > > > I am all in for making this an "optional", only enabled it when "I know > > what I want". > > > > kvm-arm.mode=nv kind of seems that the KVM driver is conditioned > > mainly for running NV (comparing with the other existing options > > for kvm-arm.mode). > > > > In reality, as you confirmed, NV is an *additional* capability > > of a VHE hypervisor. So it would be good to "opt" in for "nv" capability > > support. > > > > e.g, > > > > kvm-arm.nv=on > > > > Thinking more about it, either is fine. > > Marc, I'm curious, how do you plan to glue hVHE + NV together (if at > all)? We may need two separate options for this so the user could > separately configure NV for their hVHE KVM instance. I really don't plan to support them together. But if we wanted to support something, I'd rather express it as a composition of the various options, as I suggested to Suzuki earlier. Something along the lines of: kvm-arm.mode=hvhe,nested But the extra complexity is mind-boggling, frankly. And the result will suck terribly. NV is already exit-heavy, compared to single-level virtualisation. But now you double the cost of the exit by moving all the load/put work into the entry-exit phase. To give you an idea, an L2 guest under a hVHE L1 is ~30% slower than the same guest running under a VHE L1 with an exit-heavy workload (virtio-9p + hackbench). Making the L0 host hVHE would be even worse. We may be able to improve it to some extent, but it will always be the sucky option. Also, given where we are at the support stage (we basically offer an ARMv8.1 L1 environment), the impetus to support this sort of contraption is.. hrmm... low. I'd rather spend my energy on architecture correctness and feature-parity with single level. 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