From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD1874C66 for ; Tue, 15 Oct 2024 10:15:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728987331; cv=none; b=FORF5btrrgSWoQpPkID50VIldVdSEVQWnKZABW0c4rb3RBkJV5JiFg7NwykY4P1XUeD4+5rm/hplrsTKkvS++BL+IdQN1o3Ml5P7dB0ncLJn2nDOmoPC5dYWRQEyE7hW2EbbF7D0u81V78H+RfjneiMS8IX0wAx3W4Wqp+qk1mM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728987331; c=relaxed/simple; bh=kP4Rt0LwgM3lUXvoZlBxu96gt02191EsWBoPeIDUUgU=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=q3Zy7e4LECMHRQKMitmwJzMtKmOtbKllG/CFk8oLK0NHsLTph3FnraVDuKmqVQh20YkNpeaTU0dCJI4u7g21oJdkH4il9YKczpqV6GDHNFkfqzFusq8o4ndLooyMWY2gWpzdWOdflWZG6I3X/GcyGPj2h5O8UuzG7o6KGhXiw2w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ppwwFkDW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ppwwFkDW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4AA78C4CEC6; Tue, 15 Oct 2024 10:15:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728987331; bh=kP4Rt0LwgM3lUXvoZlBxu96gt02191EsWBoPeIDUUgU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ppwwFkDWLNrRauOGg2sc4WJingY2UfcsB1/UGXQyls3UAp/KA4dpkOPeSOyU+eWFf 1vTRyb5yEYyfOumD2mFXarAXrb7bCyEnSl1WJAcVijb15vBqHCCJ6OtsuKZws8548m ECULauiVpiXRCTuiOlXlc0++4Y+fJn4quR4HH4kncQPOprVxmtV07fUTFf1jJ6+azz 13NhQKdiyvEzFGiWHhik+tS2w6FpO2noPLLGL3u7+FzVfc425P0ABZioGZK1CyQcug dCY8uLfWf1CI4luN8ysYvXjTy4ecoHvVQu9hxIDcwbbInF/x0euF0QVj6iBc4SsPwj 7ALkXiDh7OjKA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1t0eaO-003fik-P9; Tue, 15 Oct 2024 11:15:28 +0100 Date: Tue, 15 Oct 2024 11:15:28 +0100 Message-ID: <864j5d65a7.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: kvmarm@lists.linux.dev, oliver.upton@linux.dev, catalin.marinas@arm.com, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, will@kernel.org, christoffer.dall@arm.com Subject: Re: [PATCH v1 0/4] KVM: arm64: Update KVM_VCPU_MAX_FEATURES and refactor to avoid same issue In-Reply-To: References: <20241014165809.984883-1-tabba@google.com> <865xpu61v4.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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: tabba@google.com, kvmarm@lists.linux.dev, oliver.upton@linux.dev, catalin.marinas@arm.com, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, will@kernel.org, christoffer.dall@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 14 Oct 2024 19:17:19 +0100, Fuad Tabba wrote: > > Hi Marc, > > On Mon, 14 Oct 2024 at 18:17, Marc Zyngier wrote: > > > > On Mon, 14 Oct 2024 17:58:05 +0100, > > Fuad Tabba wrote: > > > > > > The value of KVM_VCPU_MAX_FEATURES has not been updated since > > > adding new features in commit 89b0e7de3451 ("KVM: arm64: nv: > > > Introduce nested virtualization VCPU feature"). > > > > Could you please expand on what is broken? 89b0e7de3451 makes a point > > in *not* exposing this to userspace, as outlined in the commit > > message -- this is done on purpose, because NV is not functional yet. > > I understand. I was wondering how you would test NV when this feature Testing????? Fool!!! KVM is a *write-only* code base. More seriously, we have zillions of out-of-tree patches that actually enable the thing, just like for pKVM. > isn't settable, which is why I thought it was broken. That said, maybe > a comment by the definition of KVM_VCPU_MAX_FEATURES to that effect > might make things less confusing for people like me :) > > With that, is it worth repinning this patch, or is it not worth the > complexity of trying to hide NV as long as it's not supported? Maybe that's the sort of kick up the bum I need to actually enable *some* NV support upstream. Let me see if I can extract something from the current mess. M. -- Without deviation from the norm, progress is not possible.