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 D1632C4167B for ; Tue, 5 Dec 2023 18:53:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232200AbjLESwz (ORCPT ); Tue, 5 Dec 2023 13:52:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229569AbjLESwx (ORCPT ); Tue, 5 Dec 2023 13:52:53 -0500 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69DA1BA for ; Tue, 5 Dec 2023 10:52:59 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 705DA40E01AD; Tue, 5 Dec 2023 18:52:57 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id J6-BrYYixBWq; Tue, 5 Dec 2023 18:52:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1701802375; bh=COpgCkikT3z+JRnd2ns06QRSDfXH8wlW9tuJ0ai1Q54=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=L2LDMDZgpAK8mc+Y+JnHsQLOgod5dbCCOkwTjSoU5GWU4Iiw7QLIv5P7l2KV35keA vnm9DUxHxKPU9ShsZWSOIC8qIM1fAc8jnxAdwmqRSKibWVLmZfCLs+xeeNmT8RNXFy ycLZzX25TjUGQwyfSulbzjCZR1OkWG0nraW9vMK0JOffoVriyuwYKW7xO1aU0AAJjO 7DZkXnUudBEevfOxa+WfreQK5I9EV5+x5HgH0PPQZsgcI/wTUc2iTpUFRECJ4KLwpu eizRrxra395oxqFTGnHjQ3tOchDdwBGt2wpA/UMzcZSAjjlhbv+tJrkhqy90pYcIe3 vRbv5dIeKEjFteKEnQD/jzEEWJ/FVgXtwoj7cid8s3I0+TKFYCcOKJh4t8Lqty6ZYa +qfIsFWWI283HyQmz1veW7nkZGAdQ5ZXgixBhMJoAhzp+AHSytp/Lkvf3/5yT4Kmfm V2YC95zRco0aUNJYZ3dus+xX2GBd6Zc+F2Umt89CkHpAHY0OKxqbazLsdq/9CPZiv9 wUpY4O2p7YvCq+/IFhV/wqNdb2fqC9XNkEFerRrUtskr8OZ+k5E7K8N+UZoGCtFwjD 1MeJDBGlLRY2/Z3WgD2Lfz5FRWo/nbnZMm9SaZvvBljtFdksmno2pLRur7UE0egyps SyeMIpyx1zo6VoeiwAqxroHs= Received: from zn.tnic (pd95304da.dip0.t-ipconnect.de [217.83.4.218]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 7823440E0239; Tue, 5 Dec 2023 18:52:46 +0000 (UTC) Date: Tue, 5 Dec 2023 19:52:41 +0100 From: Borislav Petkov To: "Kirill A. Shutemov" Cc: Tom Lendacky , Thomas Gleixner , Ingo Molnar , Dave Hansen , "H. Peter Anvin" , x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/coco, x86/sev: Use cpu_feature_enabled() to detect SEV guest flavor Message-ID: <20231205185241.GGZW9xeTtiG6sORMTr@fat_crate.local> References: <20231205143738.2875-1-kirill.shutemov@linux.intel.com> <20231205144619.GCZW83uzAomKmupn7j@fat_crate.local> <20231205150012.6lma2wzcellr7pz7@box.shutemov.name> <20231205150648.GDZW88iAjBzYoIJ0+o@fat_crate.local> <20231205151437.aqmuydosfmnq3zr4@box.shutemov.name> <20231205160035.GEZW9JI8eKENXBo6EO@fat_crate.local> <20231205171643.zg7fwxjyccab53kf@box.shutemov.name> <20231205172436.GFZW9c1EaCaguGhglb@fat_crate.local> <20231205180813.phbxg5jdumfovshz@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20231205180813.phbxg5jdumfovshz@box.shutemov.name> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 05, 2023 at 09:08:13PM +0300, Kirill A. Shutemov wrote: > It is here and it is broken. It is not broken - it is getting improved as we go. > I think legitimate use case for cc_platfrom_has() is to check platform > capability, not specific implementation. Yes, and I already agreed that it is used the wrong way there. > And we have much more mature infrastructure around X86_FEATURE_ comparing > to CC_ATRR_. If we can use it, we should. Mature, shmature. X86_FEATURE_ has its own issues - don't even get me started on it. You want it because you use TDX_GUEST and it works fine for you. Yes, we can always do X86_FEATURE_ but X86_FEATURE_ doesn't belong in arch-agnostic code. cc_platform_has() does, OTOH. So yes, we will fix your issue, no worries. I'm figuring out the details as we speak. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette