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 E3970C001E0 for ; Wed, 16 Aug 2023 14:21:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245757AbjHPOU4 (ORCPT ); Wed, 16 Aug 2023 10:20:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343564AbjHPOU1 (ORCPT ); Wed, 16 Aug 2023 10:20:27 -0400 Received: from mail-pf1-x449.google.com (mail-pf1-x449.google.com [IPv6:2607:f8b0:4864:20::449]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BB13E1FC8 for ; Wed, 16 Aug 2023 07:20:25 -0700 (PDT) Received: by mail-pf1-x449.google.com with SMTP id d2e1a72fcca58-68874dec6c6so1909783b3a.1 for ; Wed, 16 Aug 2023 07:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692195625; x=1692800425; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=i1oB5KGOGGLmV8Hyuw5qnVZxUUxc0xqzMrgN+ZeuyH4=; b=ZWxhwbj3Flt0bO9lmrGhVUO1z+viu7lhI7DFNndVfioCj9WPrrs6Tufw6Mn7SGYGq1 4M0GGXiHXdtmAshh8/EEgts4uwl3YmCLx4XdYUMuU3ocYkYU/MxiIvKgdBQ1Mrq7V7He P+IUoQ/KVu/PkEylxmDHU0SdZtLrAFZpnn6c8eNNRH5phOpdhpqZVwRBh+Ehri+tOoLY rKqYhyJLG0YWOFi9MD+JnUBd0ThjY3cZW7UzRFetJPEm2RltcoJdolGVljIEVxkpO177 1hbSnmPn5dhUtbExAbJNqHfEGI2IQ1mpv2jaeYlmy806HVaWgQgSgk1yVbf25ABk94vN yX7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692195625; x=1692800425; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=i1oB5KGOGGLmV8Hyuw5qnVZxUUxc0xqzMrgN+ZeuyH4=; b=U9CFPrr+DK12WRjNJMkeI52dJQViBBPU9Qc1cYP3x4h2AJlqIShPOzi/Ob+1ly4OeN lTyC27YwTLAwOLyHtEoylOl1LR5WyFLcb4qTh10a3S1eulS9Qy2q4ONTKau7A+12xXWe 3lT60Oaz9er6CKtw/uepZmsyE8jz/B+TFSinw+MN8CufruffSjYS26YcEWIO8UmZdVvj o30ayb4b2O2A8XGAz/+Srso8iMCgoAPbb10fqWwkZlnM85Jb8BiAXWfEEJ7RgZgnOps3 KBKpfS8GEHPhrty6flHgbRpumf+EFCDhe4bQpe2WyPv0RE+/56siy/vhcOk7PWh+/r6q rq7g== X-Gm-Message-State: AOJu0YyG8TLZBL2LBKNn3PxkYZt7bvf6J61eDvgpNNzG87Y9z6zVQnjh gyKqykVmURnXqF7bvyBWsp1GULNEUqY= X-Google-Smtp-Source: AGHT+IHOZY+1RtbT+IwGQsfEVWjr8BXEVN7ReSuu487cknuQa9n8HgvNydglPHkYuZK0Jgji8yN7fuLP8qQ= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:aa7:8884:0:b0:686:df16:f887 with SMTP id z4-20020aa78884000000b00686df16f887mr949855pfe.6.1692195625320; Wed, 16 Aug 2023 07:20:25 -0700 (PDT) Date: Wed, 16 Aug 2023 07:20:23 -0700 In-Reply-To: <6370c12ff6ec2c22ed5e1f1f37c1cf38a820a342.camel@intel.com> Mime-Version: 1.0 References: <20230815203653.519297-1-seanjc@google.com> <20230815203653.519297-2-seanjc@google.com> <6370c12ff6ec2c22ed5e1f1f37c1cf38a820a342.camel@intel.com> Message-ID: Subject: Re: [PATCH v3 01/15] KVM: x86: Add a framework for enabling KVM-governed x86 features From: Sean Christopherson To: Kai Huang Cc: "pbonzini@redhat.com" , "vkuznets@redhat.com" , "kvm@vger.kernel.org" , Guang Zeng , "linux-kernel@vger.kernel.org" , Yuan Yao Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 16, 2023, Kai Huang wrote: > > diff --git a/arch/x86/kvm/governed_features.h b/arch/x86/kvm/governed_features.h > > new file mode 100644 > > index 000000000000..40ce8e6608cd > > --- /dev/null > > +++ b/arch/x86/kvm/governed_features.h > > @@ -0,0 +1,9 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +#if !defined(KVM_GOVERNED_FEATURE) || defined(KVM_GOVERNED_X86_FEATURE) > > +BUILD_BUG() > > +#endif > > + > > +#define KVM_GOVERNED_X86_FEATURE(x) KVM_GOVERNED_FEATURE(X86_FEATURE_##x) > > + > > +#undef KVM_GOVERNED_X86_FEATURE > > +#undef KVM_GOVERNED_FEATURE > > Nit: > > Do you want to move the very last > > #undef KVM_GOVERNED_FEATURE > > out of "governed_features.h", but to the place(s) where the macro is defined? > > Yes there will be multiple: > > #define KVM_GOVERNED_FEATURE(x) ... > #include "governed_features.h" > #undef KVM_GOVERNED_FEATURE > > But this looks clearer to me. I agree the symmetry looks better, but doing the #undef in governed_features.h is much more robust. E.g. having the #undef in the header makes it all but impossible to have a bug where we forget to #undef KVM_GOVERNED_FEATURE. Or worse, have two bugs where we forget to #undef and then also forget to #define in a later include and consume the stale #define. And I also want to follow the pattern used by kvm-x86-ops.h.