Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1519366rwd; Wed, 31 May 2023 15:22:37 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5YXi5WAUz/ndIiQ/6Qo2rbA6DTraCwS/f6jLZhxiQbLvbGHj9E7cXDNf0j0MuwKr+wFJM9 X-Received: by 2002:a05:6830:1e34:b0:69f:578a:d1ea with SMTP id t20-20020a0568301e3400b0069f578ad1eamr3460519otr.32.1685571757607; Wed, 31 May 2023 15:22:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685571757; cv=none; d=google.com; s=arc-20160816; b=mw+ibPxstB/U1d5LIuA11ot9wZdjZoj8zfhlRftsORUhH2oot2QtFhJQJXB2bAT0iE Ks64TVfxE1I8MVqBDGjJwLFeijbHB+qElEjtF5OCJTuJJxaAqJFsd5A0iyoPVY0aK2Ya YSUxcgmu3FMpKvJtdugxkwghwA6MU9Yj1giDt9By87TnLFiw23AbUmDMqGRlFkI0DHNn AsCvZyJwr8lPp8Kfun4yqlvCNApsuoe/zktNV1O+aOXSx344KP4bvxJlAiZbei9R4f3n ZLWo7mX1Mmu4R4AmGtPKcAZl27VP9pP14ilWAGpEZmUNBHaN0PGY0g3i2jWqXv+COllC yAbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=KixHZBMA+6FI7Pfjf38bXK5H1vgh9ysGY6HKye84LxA=; b=NYVRpQfSCtBwZyNTXOGsbhakZ+jGZt0D/Mvs9MVsjM6d/jPdMLT8v3x5HUPdoTPo+U XG7ZmAlwS4pVpQx7+52jqgCbZ0nB5bnxB+3GyhFKk0p1rDtepolQDfS3wZmJU9gqSgC9 2K5pQEmg1sPuFa2dcr6R3E0iqWuHlvv0Yi63YC1k65aKrA6k6Zab7V901sigFSOpAptU Cu/g/Oi9ABmeVDvMAc9kRSieilz7C4pz5FlsHByBoQ8rUeSmCM3BhFS6sgbriR3ICU/G gym7pDdMrXjMH67y0acclD2z7rR5GfJIpnuieQjzEyVSxBfIkj0i3QFO+UA9pW6dwXHi lxOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=cKjCxybK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x12-20020aa7956c000000b00648628d30f5si4302962pfq.379.2023.05.31.15.22.24; Wed, 31 May 2023 15:22:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=cKjCxybK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229603AbjEaWCd (ORCPT + 99 others); Wed, 31 May 2023 18:02:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229563AbjEaWCb (ORCPT ); Wed, 31 May 2023 18:02:31 -0400 Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com [IPv6:2607:f8b0:4864:20::1049]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81527121 for ; Wed, 31 May 2023 15:02:29 -0700 (PDT) Received: by mail-pj1-x1049.google.com with SMTP id 98e67ed59e1d1-2569298a074so15203a91.1 for ; Wed, 31 May 2023 15:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1685570549; x=1688162549; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=KixHZBMA+6FI7Pfjf38bXK5H1vgh9ysGY6HKye84LxA=; b=cKjCxybKIBlY6BvZhjgsMAJYJjgYSoSIDbguxswRODUBqYxXlbMS6zTlr3jKf2WWLO a0iV7g8hPFwM/0DjIwrgyToe1Oy1xRVNqCNVKG86o9VWxLj6q/eTUzbwPINkD1J50LfQ EUKiJxrXUqr5ZTX67Joo1YZleIP0mOgwAJ92X16sB0054X+V+llNUgvrezWbmKSmwBXL z9FPpSEOtEuHpw5hhTjXww4kLrz/fYX7BCkJHueqgA2jlIaAer2rU/CYkg9HkAe3rUE3 Woqu7PjMGTA0e16oFwQtPeNmzYnY2QqY1SE9zzNOiFPaG5F0I3XQaEZWDcmwFPRw8ar4 BoBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685570549; x=1688162549; 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=KixHZBMA+6FI7Pfjf38bXK5H1vgh9ysGY6HKye84LxA=; b=g0HBC2sMuXtTZgcpswgHlOmvnq4h2dMIFicO7734ODiwzwLTbrjcZRhpcHiihBTHdX 1XtukXKd0iF0D0INUL/s4e3+pTiFmtK7HrTQYXb6ikagkkkH7pHrXVTpGzMBB2QrSoAO DSuOvaBrSoyIR6gewe4O5Vy5QCtF0ZE9wX9qXDDZMb+H4eSFad4BDnVCVCZY6MBRMejD +pTor+UFFRlPfUE6Dz2dQTCYWXcch+u6BNBmEx2hehQ4kuFIe/oLi5Kb7s0LemgRiNEy E5ozpywYcP4Bmu0K75Mtf8TYn2huWpyacT9Fkyc/0+HZnF07g6ntvmt1IZgUcnKmVpaA 4LIA== X-Gm-Message-State: AC+VfDwSLKS6dHJ0GzcLUdaCw0BvYZV46e8gX6cjevggFI6FDfMjBEun IqidM6iIki5UTDZ/Ywk9oLGLJEsBcDQ= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90b:943:b0:253:38f0:eff0 with SMTP id dw3-20020a17090b094300b0025338f0eff0mr1461277pjb.0.1685570548974; Wed, 31 May 2023 15:02:28 -0700 (PDT) Date: Wed, 31 May 2023 15:02:27 -0700 In-Reply-To: <20230531212907.GHZHe8I/DZUyzIXI2Q@fat_crate.local> Mime-Version: 1.0 References: <20230530200152.18961-1-jon@nutanix.com> <2a6502e3-ba87-0355-af09-825e8467b81f@intel.com> <20230531212907.GHZHe8I/DZUyzIXI2Q@fat_crate.local> Message-ID: Subject: Re: [PATCH] x86/fpu/xstate: clear XSAVE features if DISABLED_MASK set From: Sean Christopherson To: Borislav Petkov Cc: Jon Kohler , Dave Hansen , Thomas Gleixner , Ingo Molnar , Dave Hansen , "x86@kernel.org" , "H. Peter Anvin" , "Chang S. Bae" , Kyle Huey , "neelnatu@google.com" , Andrew Cooper , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , Paolo Bonzini Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 31, 2023, Borislav Petkov wrote: > On Wed, May 31, 2023 at 08:18:34PM +0000, Sean Christopherson wrote: > > Assert that the to-be-checked bit passed to cpu_feature_enabled() is a > > compile-time constant instead of applying the DISABLED_MASK_BIT_SET() > > logic if and only if the bit is a constant. Conditioning the check on > > the bit being constant instead of requiring the bit to be constant could > > result in compiler specific kernel behavior, e.g. running on hardware that > > supports a disabled feature would return %false if the compiler resolved > > the bit to a constant, but %true if not. > > Uff, more mirroring CPUID inconsistencies. > > So *actually*, we should clear all those build-time disabled bits from > x86_capability so that this doesn't happen. Heh, I almost suggested that, but there is a non-zero amount of code that wants to ignore the disabled bits and query the "raw" CPUID information. In quotes because the kernel still massages x86_capability. Changing that behavior will require auditing a lot of code, because in most cases any breakage will be mostly silent, e.g. loss of features/performance and not explosions. E.g. KVM emulates UMIP when it's not supported in hardware, and so advertises UMIP support irrespective of hardware/host support. But emulating UMIP is imperfect and suboptimal (requires intercepting L*DT instructions), so KVM intercepts L*DT instructions iff UMIP is not supported in hardware, as detected by boot_cpu_has(X86_FEATURE_UMIP). The comment for cpu_feature_enabled() even calls out this type of use case: Use the cpu_has() family if you want true runtime testing of CPU features, like in hypervisor code where you are supporting a possible guest feature where host support for it is not relevant. That said, the behavior of cpu_has() is wildly inconsistent, e.g. LA57 is indirectly cleared in x86_capability if it's a disabled bit because of this code in early_identify_cpu(). if (!pgtable_l5_enabled()) setup_clear_cpu_cap(X86_FEATURE_LA57); KVM works around that by manually doing CPUID to query hardware directly: /* Set LA57 based on hardware capability. */ if (cpuid_ecx(7) & F(LA57)) kvm_cpu_cap_set(X86_FEATURE_LA57); So yeah, I 100% agree the current state is messy and would love to have cpu_feature_enabled() be a pure optimization with respect to boot_cpu_has(), but it's not as trivial at it looks.