From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (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 64E573016E5 for ; Wed, 11 Feb 2026 15:54:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770825273; cv=none; b=uLPydpP/iG6rdMly0iEKdaiy3YRpnC3Cz41Ic8Bq0UhHOx7pv9E/+Ep8R3VNfRdlb9pB3ppCZoRKVdcXkq9/LE6woDF0vJsEKu9TqFemq7TmUARy4kOyIYfcXzPM7DL0tjv1HtIKKooTKN98i/DVMdHf14M84bd83X1oTWvjmbY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770825273; c=relaxed/simple; bh=udEYJzW/vExQgZ+1QN+mlGM7VGV9PWFLvvV/PuJPXAw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=So7P2B/xjd7FplU+JXe5mLjKSd2a+kfh2JNLvGnsvCKSSDLs4nlfVBijH7fvJLEI2pbU/aEmhwYA4GvGWzE0o7WYGQjh40hKxSXu/GmNB9CZblkcLBEjdAYdx5XtKc/VVV2WH1I/mHAe0CJH9+1yq6NLTVd5H/5uHfCp0lgecXs= 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=eRlHdXf6; arc=none smtp.client-ip=209.85.214.202 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="eRlHdXf6" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2aae0d40a47so121591745ad.2 for ; Wed, 11 Feb 2026 07:54:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770825272; x=1771430072; 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=9n7HkCUm+70QYWul854vYpIiRTrImnKsgAkfNc3Krg4=; b=eRlHdXf6fFauDyDup82rpE5lKs/hLUHXXtVlF497E8Q5c/Nw9fa+zBLepe5SP4u3A6 YshaEycIzhDlnbZn0Ox9sankl9DXxET70kWHuaUp8YapYDb39LwOTHecBH0Wzpod2Ib0 +1Ua6SC7GfLYY51gRlYt64uJITQoRmfJhL4C7519XoJ25D7cUadFww7/4RUUyPWlZ1Xh iYgVPDXtW3bSRQPnSkgfXhwnkrMCAUqkNvQk1UsF99gT7vo7hXdwvLAABkOs0Ou3xPOs DzyHzqK3g2eCi9z9xquxGD+yRmgnJncSVl8p4fMv6efw4nV0v95mbjVSTlONfJmdcN4S I1kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770825272; x=1771430072; 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=9n7HkCUm+70QYWul854vYpIiRTrImnKsgAkfNc3Krg4=; b=Gj3TJ/oivqFlj6rLpOLbc4wcEzBNmcWlVlOS4FncoL/hhxc2Yf0UtdYqAh1v4wFLfI nkDqrtk28Dli627ntDmEo5/d/TYJckO1RKPT2+xaV6rG8PoXZfhQkT2iZr+QKp8cFMau C3tO0D6QVg+vQ4pYRncd3CyXt6yVLZxKR9JI+htU3ePJrEhpHTmrdl6F7azG+AreINwW JazozIhG1w1uRX1rxUoVsW5hpAKDk64XeiOsZz9yWy+6bkgwIkDlt2I0DoQ/ot0yJJ8K n26vgvJtl3RBoGxbooi76nUBxJHESHbdXetqGpo9oJXt5Om2xqDPHp8hREfVvpkvaQn1 V/Eg== X-Forwarded-Encrypted: i=1; AJvYcCWtxf15oXHpcOB+YcM9eB70DP2NBtqBBXY3abs2S9McbGJWWePmvp+8UsiZ2cioF6najuFS0kWrKpDFiuc=@vger.kernel.org X-Gm-Message-State: AOJu0YzP1eyyfM0084fX/9wYjfw1Ax9yjoO2tl58J8ST+FN+9Pb7qSOc jttuQjRRXx91nM7rQIkV+rzR8qOsXhDAdZO7YZ9h0mGso+AB96XOQzmZdspa/HEA9ETjzTVCHst TlypRaA== X-Received: from plblf15.prod.google.com ([2002:a17:902:fb4f:b0:2aa:d3db:54c]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:2c05:b0:2a9:327f:ac56 with SMTP id d9443c01a7336-2ab280c8557mr31541045ad.55.1770825271576; Wed, 11 Feb 2026 07:54:31 -0800 (PST) Date: Wed, 11 Feb 2026 07:54:30 -0800 In-Reply-To: <20260211133226.GCaYyE6u_IMik5DY4m@fat_crate.local> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260209153243.GBaYn-G02QE86Fje7g@fat_crate.local> <20260209174559.GDaYodVxWsiesiedLJ@fat_crate.local> <20260210200711.GCaYuP74dOknGNV1DT@fat_crate.local> <20260211133226.GCaYyE6u_IMik5DY4m@fat_crate.local> Message-ID: Subject: Re: [PATCH] KVM: x86: synthesize TSA CPUID bits via SCATTERED_F() From: Sean Christopherson To: Borislav Petkov 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 Content-Type: text/plain; charset="us-ascii" On Wed, Feb 11, 2026, Borislav Petkov wrote: > 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: I understand what the goal is, I just don't want to buy what you're selling. > 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. Those problems are _entirely_ limited to the fact that the kernel's feature tracking isn't 100% comprehensive. It's completely orthogonal to KVM's enumeration of its supported feature. > 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? No, it honestly sounds rather awful. > SCATTERED_F, SYNTHESIZED_F, PASSTHROUGH_F become obsolete. SCATTERED_F will become obsolete, SYNTHESIZED_F and PASSTHROUGH_F will not. They cannot. It's impossible to express three states with one bit. SYNTHESIZED_F PASSTHROUGH_F F raw CPUID DONT_CARE Y Y kernel caps Y DONT_CARE Y If the kernel tracks both raw CPUID *and* kernel caps, then KVM can use the table without having to (re)do CPUID when configuring KVM's feature set. But KVM would still need to have processing for SYNTHESIZED_F, PASSTHROUGH_F, and F, to derive the correct state from the raw+kernel tables. > 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. Again, that's achieved purely by tracking the full CPUID hierarchy. It has nothing to do with EMULATED_F, X86_64_F, RUNTIME_F, SYNTHESIZED_F, PASSTHROUGH_F, etc. > Now why wouldn't you want that wonderful and charming thing?! Because from my perspective, centralizing *everything* is all pain, no gain. It would bleed KVM details into the broader kernel, unnecessarily limit KVM's ability to change how KVM emulates/virtualizes features, and require querying a lookaside table to understand KVM's rules/handling. No thanks.