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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C72F8C433EF for ; Thu, 9 Jun 2022 07:47:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239293AbiFIHrH (ORCPT ); Thu, 9 Jun 2022 03:47:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232338AbiFIHrF (ORCPT ); Thu, 9 Jun 2022 03:47:05 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2B493B2B6 for ; Thu, 9 Jun 2022 00:47:04 -0700 (PDT) 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 ams.source.kernel.org (Postfix) with ESMTPS id 6D690B82C46 for ; Thu, 9 Jun 2022 07:47:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13BBFC34114; Thu, 9 Jun 2022 07:47:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654760822; bh=CJyPKTOUlEe0lsgm1DOf0I3KC1tRhvJ3KvupKv8Oa5w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=EddcOaiNAZ2ytT+bjF5TQImCbSPTN6O58hPfs0KTLPNrCnFHJBFsilS/8FN4JXf9A Z3qF1GxMpVvgn8FsB38mgFwzBW+R8lc5E4d751a3Jsm3rimsZmuNo9Nx67tGanIhEA 3dqNSL4CHpewLNpvBYO7JECWJsBeKzOq6FXoHeZYr+hLYcbA+y7/RR4xJtnkPXxPLQ HYMg0/dQMR015ChiAzYw6nfLoehlO8KkD/bj/2++IL5zTTTQAH/gmKVg9Z2Tt33xvN cy8nyn3Cpnbm1TeEkRhxEsDb+KEaHxACAMbOSOzLEijd+MA2zTamq3S8k/w7O/sa9A rAabgQ3HlkjLw== 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 1nzCsc-00GnT7-L4; Thu, 09 Jun 2022 08:46:58 +0100 Date: Thu, 09 Jun 2022 08:46:58 +0100 Message-ID: <87fske46tp.wl-maz@kernel.org> From: Marc Zyngier To: Reiji Watanabe Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Linux ARM , kernel-team@android.com, Will Deacon , Mark Brown Subject: Re: [PATCH 06/18] KVM: arm64: Add three sets of flags to the vcpu state In-Reply-To: References: <20220528113829.1043361-1-maz@kernel.org> <20220528113829.1043361-7-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") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: reijiw@google.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kernel-team@android.com, will@kernel.org, broonie@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, 09 Jun 2022 07:10:14 +0100, Reiji Watanabe wrote: > > Hi Marc, > > On Sat, May 28, 2022 at 4:38 AM Marc Zyngier wrote: > > > > It so appears that each of the vcpu flags is really belonging to > > one of three categories: > > > > - a configuration flag, set once and for all > > - an input flag generated by the kernel for the hypervisor to use > > - a state flag that is only for the kernel's own bookkeeping > > > > As we are going to split all the existing flags into these three > > sets, introduce all three in one go. > > > > No functional change other than a bit of bloat... > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/include/asm/kvm_host.h | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > > index 5eb6791df608..c9dd0d4e22f2 100644 > > --- a/arch/arm64/include/asm/kvm_host.h > > +++ b/arch/arm64/include/asm/kvm_host.h > > @@ -338,6 +338,15 @@ struct kvm_vcpu_arch { > > /* Miscellaneous vcpu state flags */ > > u64 flags; > > > > + /* Configuration flags */ > > + u64 cflags; > > + > > + /* Input flags to the hypervisor code */ > > + u64 iflags; > > + > > + /* State flags, unused by the hypervisor code */ > > + u64 sflags; > > Although I think VCPU_SVE_FINALIZED could be considered "state" rather > than "configuration", I assume the reason why it is handled by cflags > in the following patches is because VCPU_SVE_FINALIZED is set once > for all. If my assumption is correct, it would be clearer to add > "set once and for all" in the comment for cflags. Yes, that's indeed the reason for this categorisation. In general, these flags are, as you put it, set once and for all extremely early (before the vcpu can run), and are never cleared. I'll update the comment accordingly. > Also, if we end up using VCPU_SVE_FINALIZED in hypervisor code later, > then should it be handled by iflags instead of cflags ? That'd be my expectation if they ended up changing state at some point. My view is that the cflags are immutable once the vcpu has run, and flags that can change state over the life if the vcpu shouldn't be in that category. > > My understanding of how those flags should be used is as follows. > Is my understanding correct ? > > iflags: flags that are used by hypervisor code Yes. Crucially, they are used as an input to the hypervisor code: it either consumes these flags (INCREMENT_PC, PENDING_EXCEPTION), or consult them to decide what to do. > cflags: flags that are set once for all and unused by hypervisor code Yes. > sflags: flags that could be set/cleared more than once and unused > by hypervisor code Yes. They are really bookkeeping flags for the kernel code. I'll try to incorporate some of that in the comments before reposting the series. Thanks, M. -- Without deviation from the norm, progress is not possible.