public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Reiji Watanabe <reijiw@google.com>
Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Oliver Upton <oupton@google.com>, Will Deacon <will@kernel.org>,
	Fuad Tabba <tabba@google.com>,
	Quentin Perret <qperret@google.com>,
	Mark Brown <broonie@kernel.org>,
	kernel-team@android.com
Subject: Re: [PATCH v2 05/19] KVM: arm64: Add helpers to manipulate vcpu flags among a set
Date: Sun, 12 Jun 2022 09:59:03 +0100	[thread overview]
Message-ID: <87zgiip8a0.wl-maz@kernel.org> (raw)
In-Reply-To: <CAAeT=Fxu+s7JNYP-U-ov2yqhLVp7Nvf_yox0JaVZh06a=rHwzg@mail.gmail.com>

On Sat, 11 Jun 2022 19:37:50 +0100,
Reiji Watanabe <reijiw@google.com> wrote:
> 
> On Fri, Jun 10, 2022 at 2:28 AM Marc Zyngier <maz@kernel.org> wrote:
> >
> > Careful analysis of the vcpu flags show that this is a mix of
> > configuration, communication between the host and the hypervisor,
> > as well as anciliary state that has no consistency. It'd be a lot
> > better if we could split these flags into consistent categories.
> >
> > However, even if we split these flags apart, we want to make sure
> > that each flag can only be applied to its own set, and not across
> > sets.
> >
> > To achieve this, use a preprocessor hack so that each flag is always
> > associated with:
> >
> > - the set that contains it,
> >
> > - a mask that describe all the bits that contain it (for a simple
> >   flag, this is the same thing as the flag itself, but we will
> >   eventually have values that cover multiple bits at once).
> >
> > Each flag is thus a triplet that is not directly usable as a value,
> > but used by three helpers that allow the flag to be set, cleared,
> > and fetched. By mandating the use of such helper, we can easily
> > enforce that a flag can only be used with the set it belongs to.
> >
> > Finally, one last helper "unpacks" the raw value from the triplet
> > that represents a flag, which is useful for multi-bit values that
> > need to be enumerated (in a switch statement, for example).
> >
> > Further patches will start making use of this infrastructure.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  arch/arm64/include/asm/kvm_host.h | 44 +++++++++++++++++++++++++++++++
> >  1 file changed, 44 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 372c5642cfab..6d30ac7e3164 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -415,6 +415,50 @@ struct kvm_vcpu_arch {
> >         } steal;
> >  };
> >
> > +/*
> > + * Each 'flag' is composed of a comma-separated triplet:
> > + *
> > + * - the flag-set it belongs to in the vcpu->arch structure
> > + * - the value for that flag
> > + * - the mask for that flag
> > + *
> > + *  __vcpu_single_flag() builds such a triplet for a single-bit flag.
> > + * unpack_vcpu_flag() extract the flag value from the triplet for
> > + * direct use outside of the flag accessors.
> > + */
> > +#define __vcpu_single_flag(_set, _f)   _set, (_f), (_f)
> > +
> > +#define __unpack_flag(_set, _f, _m)    _f
> > +#define unpack_vcpu_flag(...)          __unpack_flag(__VA_ARGS__)
> > +
> > +#define __vcpu_get_flag(v, flagset, f, m)                      \
> > +       ({                                                      \
> > +               v->arch.flagset & (m);                          \
> > +       })
> > +
> > +#define __vcpu_set_flag(v, flagset, f, m)                      \
> > +       do {                                                    \
> > +               typeof(v->arch.flagset) *fset;                  \
> > +                                                               \
> > +               fset = &v->arch.flagset;                        \
> > +               if (HWEIGHT(m) > 1)                             \
> > +                       *fset &= ~(m);                          \
> > +               *fset |= (f);                                   \
> > +       } while (0)
> > +
> > +#define __vcpu_clear_flag(v, flagset, f, m)                    \
> > +       do {                                                    \
> > +               typeof(v->arch.flagset) *fset;                  \
> > +                                                               \
> > +               fset = &v->arch.flagset;                        \
> > +               *fset &= ~(m);                                  \
> > +       } while (0)
> 
> Reviewed-by: Reiji Watanabe <reijiw@google.com>
> 
> IMHO I would prefer to have 'v' enclosed in parentheses in the
> implementation of __vcpu_{get,set,clear}_flag rather than in
> the implementation of vcpu_{get,set,clear}_flag though.
> (That was what I meant in my comment for v1)

I understood what you were asking the first place, but I don't think
this has any advantage over what is above. __vcpu_{get,set,clear}_flag
are not meant to be used directly, and adding extra bracketing to
these only makes them more painful to read.

If you can show a case where it breaks, I'll be happy to revisit this.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2022-06-12  8:59 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10  9:28 [PATCH v2 00/19] KVM/arm64: Refactoring the vcpu flags Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 01/19] KVM: arm64: Always start with clearing SVE flag on load Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 02/19] KVM: arm64: Always start with clearing SME " Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 03/19] KVM: arm64: Drop FP_FOREIGN_STATE from the hypervisor code Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 04/19] KVM: arm64: Move FP state ownership from flag to a tristate Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 05/19] KVM: arm64: Add helpers to manipulate vcpu flags among a set Marc Zyngier
2022-06-10 13:05   ` Fuad Tabba
2022-06-11 18:37   ` Reiji Watanabe
2022-06-12  8:59     ` Marc Zyngier [this message]
2022-06-10  9:28 ` [PATCH v2 06/19] KVM: arm64: Add three sets of flags to the vcpu state Marc Zyngier
2022-06-11 18:41   ` Reiji Watanabe
2022-06-10  9:28 ` [PATCH v2 07/19] KVM: arm64: Move vcpu configuration flags into their own set Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 08/19] KVM: arm64: Move vcpu PC/Exception flags to the input flag set Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 09/19] KVM: arm64: Move vcpu debug/SPE/TRBE " Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 10/19] KVM: arm64: Move vcpu SVE/SME flags to the state " Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 11/19] KVM: arm64: Move vcpu ON_UNSUPPORTED_CPU flag " Marc Zyngier
2022-06-15 13:14   ` Alexandru Elisei
2022-06-15 13:23     ` Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 12/19] KVM: arm64: Move vcpu WFIT " Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 13/19] KVM: arm64: Kill unused vcpu flags field Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 14/19] KVM: arm64: Convert vcpu sysregs_loaded_on_cpu to a state flag Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 15/19] KVM: arm64: Warn when PENDING_EXCEPTION and INCREMENT_PC are set together Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 16/19] KVM: arm64: Add build-time sanity checks for flags Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 17/19] KVM: arm64: Reduce the size of the vcpu flag members Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 18/19] KVM: arm64: Document why pause cannot be turned into a flag Marc Zyngier
2022-06-10  9:28 ` [PATCH v2 19/19] KVM: arm64: Move the handling of !FP outside of the fast path Marc Zyngier
2022-06-14  4:15   ` Reiji Watanabe
2022-06-29  9:58 ` [PATCH v2 00/19] KVM/arm64: Refactoring the vcpu flags Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zgiip8a0.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alexandru.elisei@arm.com \
    --cc=broonie@kernel.org \
    --cc=james.morse@arm.com \
    --cc=kernel-team@android.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oupton@google.com \
    --cc=qperret@google.com \
    --cc=reijiw@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox