From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30B4F1FDA61; Wed, 11 Feb 2026 13:32:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=65.109.113.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770816776; cv=none; b=A4p1He3otYJ+jpaqeBd4CAkvDE0+Rknbdwr7Ba2glO4yrRTpeCH53H5nHslcpcgXjW1y42jqyQ4h6OSJCqy8ulWVkpl88u5fllqyFwI91Cg2m7vH4jf+QqjkS4Qlg8xS3MzR0ImZmeCUgXRtCBOkS3pgMIamO71TD/R8OZjcBAk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770816776; c=relaxed/simple; bh=g/GetwdgXSD/xOBMKj8OrlB9rpaJVIJD4oSieh9mPtE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Q+jfEyWdUG1/CaYt/WP92U5Rin59i/mUoefBr5F25S0evTK/B1mdtBc9aovVqOeQoEMtupGnRGY2nBiAyLRBUp0hw84LikesDbxpoVakA6OK4Na92UVrLasTi/taiq/GMNYF8EOdBVUyy+KNOyrVnLI7+6j+iNLjhT6AZQU6GEg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=alien8.de; spf=pass smtp.mailfrom=alien8.de; dkim=pass (4096-bit key) header.d=alien8.de header.i=@alien8.de header.b=IhQf8LnX; arc=none smtp.client-ip=65.109.113.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=alien8.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=alien8.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (4096-bit key) header.d=alien8.de header.i=@alien8.de header.b="IhQf8LnX" Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id C6E7E40E036A; Wed, 11 Feb 2026 13:32:51 +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 ZRhpbI53fyIZ; Wed, 11 Feb 2026 13:32:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1770816767; bh=+3hvh3COznYSlONvJ1K2yVwHlJ+zq2d4iHs6m3j8Gzw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IhQf8LnXD6E5YwFHuBLwZF4FU5+xYpNv5zljDwkg4/iM7NoImBhFEoMnTReW4Jrya xmPdgsyA/b7OOLig4LMgWvz4NW0Jd9eNqQeAkR0hPhTW5mFRMCcL6GIrsQXc/XK1Vi mjxGL1iy5VuVJ/TKBTB32yMBk8ke9qmtt0nmuZc7Hb8KkPcjwWZ4lebXioJ0s0qDZd WmDjDxVOHSYrvVD+VsT62rkU//dBWSaE/lYouxrt7F66mAnCA05bp9n5yIj7RLFtyo DcOtkheX31niVpVbeUsLKFi6bYBxqlnKZEkXxZ3D75GwaUWhgppxoPHFbXF4m7qY4o jgADIlIJ7EvxF+mmtbNwL6PcnH/wLw1oWpRgbU4tU70OBwZQdwd5pj7vlj282FCdRB D+xy0rvVKGq4pKIWjWNrwGoPNgxOV8LklbVB4nAgNqQIXrpxxIejDapXdOQReNWQcU MFtUKMBOd9SkxpAKoClt9OJhIswlq8aESGeq1YLoGVy0WMNhaQErarRDjanKGbePJL 5cC53p6vK87DnVrb0RlrcIHJuDbKXrOx2mvQRAIJ7YcWMMICR1Zidz08R0n8x4sPAZ Gk0PYvfMdEdQ9+A4xRJHkFdR/+E68cbTsj3mzdPtsP8AjcoU947xK3DSg41t7aV9h/ QM2kuuzqTrdVsaovcuxHwxYs= Received: from zn.tnic (pd95306e3.dip0.t-ipconnect.de [217.83.6.227]) (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 UTF8SMTPSA id A3F0040E0367; Wed, 11 Feb 2026 13:32:35 +0000 (UTC) Date: Wed, 11 Feb 2026 14:32:26 +0100 From: Borislav Petkov To: Sean Christopherson Cc: Carlos =?utf-8?B?TMOzcGV6?= , Jim Mattson , kvm@vger.kernel.org, Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Babu Moger Subject: Re: [PATCH] KVM: x86: synthesize TSA CPUID bits via SCATTERED_F() Message-ID: <20260211133226.GCaYyE6u_IMik5DY4m@fat_crate.local> References: <20260208211342.GBaYj8hhtYM-lYfq-X@fat_crate.local> <20260209153243.GBaYn-G02QE86Fje7g@fat_crate.local> <20260209174559.GDaYodVxWsiesiedLJ@fat_crate.local> <20260210200711.GCaYuP74dOknGNV1DT@fat_crate.local> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Tue, Feb 10, 2026 at 03:48:56PM -0800, Sean Christopherson wrote: > See above regarding scattered. As for synthesized, KVM is paranoid and so by > default, requires features to be supported by the host kernel *and* present in > raw CPUID in order to advertise support to the guest. Yes, it will check for X86_FEATURE to be and then look at CPUID. > Because IMO, that would be a huge net negative. I have zero desire to go lookup > a table to figure out KVM's rules for supporting a given feature, and even less > desire to have to route KVM-internal changes through a giant shared table. I'm > also skeptical that a table would provide as many safeguards as the macro magic, > at least not without a lot more development. Lemme cut to the chase because it seems to me like my point is not coming across: We're changing how CPUID is handled on baremetal. Consider how much trouble there was and is between how the baremetal kernel handles CPUID features and how KVM wants to handle them and how those should be independent but they aren't and if we change baremetal handling - i.e., unscatter a leaf - we break KVM, yadda yadda, and all the friction over the years. Now we have the chance to define that cleanly and also accomodate KVM's needs. As in, you add a CPUID flag in baremetal and then in the representation of that flag in our internal structures, there are KVM-specific attributes which are used by it to do that feature flag's representation to guests. The new scheme will get rid of the scattered crap as it is not needed anymore - we'll have the *whole* CPUID leaf hierarchy. Now wouldn't it be lovely to have a .kvm_flags = EMULATED_F | X86_64_F ... RUNTIME_F which is per CPUID feature bit and which KVM code queries? SCATTERED_F, SYNTHESIZED_F, PASSTHROUGH_F become obsolete. No need for those macros, adding new CPUID feature flags would mean simply adding those .kvm_flags things which denote what KVM does with the feature. Not how it is defined internally. And then everything JustWorks(tm) naturally without having to deal with those macros. And you'd get rid of the KVM-only CPUID leafs too because everything will be in one central place. Now why wouldn't you want that wonderful and charming thing?! :-) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette