From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 95CEC1A3AB8 for ; Wed, 11 Sep 2024 15:37:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726069076; cv=none; b=aOyDQNtXzdIObE2a47C02t3yJcMDBIO15Evrd9BP5+NmlJrYmeuGf8VoiTCsMkiDjrkhhBZ7mINy5p3gkeSNUex6OqyxoSY8ishZ6W+3umbNK2FGdgXKA0wgMM3XB6C6y0gtkDYeP1bWqNMpmY6f35uEO2p3NkJC5hmAuW0lhnA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726069076; c=relaxed/simple; bh=/9mGBPcz6bEEuta300HLDU/i5hbGKt+GMHZF6+0ToCI=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=V0e5PPMJqvGIfbybCWrwjTUVJzsh3w0rIutN5bbKdiosTQzAiCPcYsx+2wIagtpUJDHc5I3Ux1lQ4OgEc/Xl1IX4F0F8IpXOpkccFdTJBGUl70BnYBqtE/7yNg0le73OGLcVSC/btgSRJqdiGvpgMwUcW10HJ/u0mZ6gKVX99XE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=fkqiYNgm; arc=none smtp.client-ip=209.85.215.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="fkqiYNgm" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-778702b9f8fso848663a12.1 for ; Wed, 11 Sep 2024 08:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1726069074; x=1726673874; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=KOyOIRL3lgO9opRsCrN+ghOFkRsLNHeHkE/P6t+PUfs=; b=fkqiYNgmwZVx1oEG6cEKzjiVE+hLjKOhnABOiozMGZwk64t7n2mEgiTGCbK7iGKgY6 Nc/yrCDgqmQYai1KWKiXcYetDzBxYNVGPhHhDTa4dMwCvOk/1z/peMvEMRW3PjcL6PoL LJA9eparptv2eUMshwOtqEfmAesZ8amBCfCUqk/vaQCk+lH3puHZuRJhjT452ZuF6Ndw O1Yl5aaHS19fH5v8VTtwWj8LMS2Zd1ipciusn7N6vB36bMv68/vfKZAkYjTnSmKIKszI IA55lDAHLttQLPK7FylF5p8nCfaBtlyIZF8TDVM7yP9qmQjftL1itsz4Z33x93CBg7ZF 9lXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726069074; x=1726673874; 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=KOyOIRL3lgO9opRsCrN+ghOFkRsLNHeHkE/P6t+PUfs=; b=VC8o3lUX0j4NvHEYfY5VQTC8evVo7giFtfx44Mhwq2AU54lmH28mvBqdTULI7DsQqZ fhlZh8IPFepHAA/A2eGnATaz6nNrnw9Hgk7WQ5jU1B1BvtwDiQqup6gq4ldLnlRxe1Ug aWU788QhKSo+Eu3WCBtEgrK8jfvAmnH58s+iU3B291C4+reKZM5k5ekNxartyn8Ge8aU MWPWtW2yQVibXkjZvfkobY52QZLQCRWWvYOu+nBhd2igwj4AoKvAbdLoFhAvqDSKvt17 zqvNQ4M+LuCJXHFJGC6YhDfoCrgLeAstO3m3AR1JeEIdku7zaUGtua49SCIC0XLArVWT Hn9w== X-Forwarded-Encrypted: i=1; AJvYcCXslZQscKmbR1pVrraARPhJYXEVO5tNd7+lzxUB3CIzecTo9iM/V00Sb1JQqE+dXC2KBw0O1MtqP3SnV3Q=@vger.kernel.org X-Gm-Message-State: AOJu0Yxa1WpY9bjFSsM9kJ0oHQ6UIx1BNYadUtJtaJaZ2udb0YrCEToM 5UI3+DJgGnHig9okG4C6e2r6bz7BJAhovNfhcfBuEG5bYckEv4G6YwV1QYMe5THf0TLLAGM+YCP gKw== X-Google-Smtp-Source: AGHT+IEhfSIYMnsJNwhqfisaN5qoyB38Lao3g7nOTEDCmftPeFTt71jA12MSRIMm6JGo9mZ+1idIw20uA3s= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a02:f85:b0:7a1:6a6b:4a5b with SMTP id 41be03b00d2f7-7db0850b96bmr18853a12.2.1726069073748; Wed, 11 Sep 2024 08:37:53 -0700 (PDT) Date: Wed, 11 Sep 2024 08:37:52 -0700 In-Reply-To: <44e7f9cba483bda99f8ddc0a2ad41d69687e1dbe.camel@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240517173926.965351-1-seanjc@google.com> <20240517173926.965351-23-seanjc@google.com> <43ef06aca700528d956c8f51101715df86f32a91.camel@redhat.com> <3da2be9507058a15578b5f736bc179dc3b5e970f.camel@redhat.com> <8f35b524cda53aff29a9389c79742fc14f77ec68.camel@redhat.com> <44e7f9cba483bda99f8ddc0a2ad41d69687e1dbe.camel@redhat.com> Message-ID: Subject: Re: [PATCH v2 22/49] KVM: x86: Add a macro to precisely handle aliased 0x1.EDX CPUID features From: Sean Christopherson To: Maxim Levitsky Cc: Paolo Bonzini , Vitaly Kuznetsov , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Hou Wenlong , Kechen Lu , Oliver Upton , Binbin Wu , Yang Weijiang , Robert Hoo Content-Type: text/plain; charset="us-ascii" On Tue, Sep 10, 2024, Maxim Levitsky wrote: > On Mon, 2024-08-05 at 15:00 -0700, Sean Christopherson wrote: > > If we go with ALIASED_F() (or ALIASED_8000_0001_F()), then that macro is all that > > is needed, and it's bulletproof. E.g. there is no KVM_X86_FEATURE_FPU_ALIAS that > > can be queried, and thus no need to be ensure it's defined in cpuid.c and #undef'd > > after its use. > > > > Hmm, I supposed we could harden the aliased feature usage in the same way as the > > ALIASED_F(), e.g. > > > > #define __X86_FEATURE_8000_0001_ALIAS(feature) \ > > ({ \ > > BUILD_BUG_ON(__feature_leaf(X86_FEATURE_##name) != CPUID_1_EDX); \ > > BUILD_BUG_ON(kvm_cpu_cap_init_in_progress != CPUID_8000_0001_EDX); \ > > (feature + (CPUID_8000_0001_EDX - CPUID_1_EDX) * 32); \ > > }) > > > > If something tries to use an X86_FEATURE_*_ALIAS outside if kvm_cpu_cap_init(), > > it would need to define and set kvm_cpu_cap_init_in_progress, i.e. would really > > have to try to mess up. > > > > Effectively the only differences are that KVM would have ~10 or so more lines of > > code to define the X86_FEATURE_*_ALIAS macros, and that the usage would look like: > > > > VIRTUALIZED_F(FPU_ALIAS) > > > > versus > > > > ALIASED_F(FPU) > > > This is exactly my point. I want to avoid profiliation of the _F macros, because > later, we will need to figure out what each of them (e.g ALIASED_F) does. > > A whole leaf alias, is once in x86 arch life misfeature, and it is very likely that > Intel/AMD won't add more such aliases. > > Why VIRTUALIZED_F though, it wasn't in the patch series? Normal F() should be enough > IMHO. I'm a-ok with F(), I simply thought there was a desire for more verbosity across the board. > > At that point, I'm ok with defining each alias, though I honestly still don't > > understand the motivation for defining single-use macros. > > > > The idea is that nobody will need to look at these macros > (e.g__X86_FEATURE_8000_0001_ALIAS() and its usages), because it's clear what > they do, they just define few extra CPUID features that nobody really cares > about. > > ALIASED_F() on the other hand is yet another _F macro() and we will need, > once again and again to figure out why it is there, what it does, etc. That seems easily solved by naming the macro ALIASED_8000_0001_F(). I don't see how that's any less clear than __X86_FEATURE_8000_0001_ALIAS(), and as above, there are several advantages to defining the alias in the context of the leaf builder.