From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 56A1E30BF7D for ; Mon, 9 Feb 2026 21:12:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770671569; cv=none; b=aVWnamZoaCRZ7coJhI54rd80fMb5u5qLfwSgUTPlhmzTv8h0Bff2guULYay8S6fAE/D2EI+QIBG8X1VgCid7cMba0RP7kRu1YCYo2/T7pvMV8bvqDo//Ycxbo9eqPsqBz1E0QN/uBYovU9ZRWQ4r/A1WdALVH07nT4e/p67cLAE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770671569; c=relaxed/simple; bh=Uxn+SvC4cwV/a8hZpODkPu6yuzOnTkz5evR3xUhgIBA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=KbPRjlWFTNmb1XHYAZaG2I2NkOUDllUn7hMyhYHdc/FaCuINacpdZaMXBRpa3OuGc6Hzv1LT0J+5tXfXOTigHj55MDDCpimM87E2mtAZyfQWoVUSm9SvtO7Zd6ljQlzPBwGhe7Hr/rVkTvyk5Isa6y86bvNo837ABM3/tWBAPmQ= 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=htyr5pDT; arc=none smtp.client-ip=209.85.216.74 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="htyr5pDT" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-3561f5bd22eso133682a91.2 for ; Mon, 09 Feb 2026 13:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770671568; x=1771276368; 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=5JLkCGyOFIJqN8NxvIX+7FWicQMfpPV6EbEazy85XpY=; b=htyr5pDTymjWTtVyfsLaVIvaraI8RuD4Z00QSFJGZqCt61VqpVhSxdZcWuw7OBryAT YRlKWBXE8niz7Jnfm8BtBS5Und86thDtylum0rJG+MLkejrlXLk9g2Pj16bcTpUBYWy+ VIXrNSs7eE6YaST3VxqfshAFlg+R7f73aE6QAPJGnROKXPcvEn1oVly4Kh4+oLuv9puO fVSiODHGyJ3LgiNRz1CX72315NF9lATbma2mh2z46+zWd+Xab4f+KA1rQzp7PjCWZHgX GlPWjRBcMS7wD7ng287+nxeAVoPRHJ1BJf6ppjqOdQm/YSNKT0yzPJ8JFOSGFXk99zaY KLAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770671568; x=1771276368; 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=5JLkCGyOFIJqN8NxvIX+7FWicQMfpPV6EbEazy85XpY=; b=jr2rWaE4QGo5Dufe09MAneUYicz8UP18QBmoe3n9shcU+16jnhte106JXDA6rRy10J BcoL7sTQZHuvZYyJIRLD2gFLa5iBq6tzWTPNEq+giATmBgyAyhTy5MCj4Qw89mDN2CDt BvS4SskAMsCyktpRzhkknPa/JvSSiNXGyM4QQllXQAU759g/55sfXxl6Rty0BDonjDUR jOiGAimF7hD6DGSKo29LbtzAW1Wngh7p58K4UqssDYroxHZSh6l8SPrVRIjwDAm1m4wc /wti7Dbs37ES/UQO1Lg62ZsoSvZZ8yQBUMZWFq9UgZAal/0BAKk5tbY2Gn8LluqAb9tl qNAw== X-Forwarded-Encrypted: i=1; AJvYcCVBOUDWKV/RUPu564ZnDEpBcvrdutXvn8Jf6VtQzlWJB+qX+Ck1oNQS0WdT5jLPOs/hkn0=@vger.kernel.org X-Gm-Message-State: AOJu0YzxslRWakHCHYTu2AfqZ505hJwwR32yFSfvfJl5i3LeRrCwECRS vdDJcn7dHNkAR++vyI5TNEVZAR5o76e2hYzQLyK+vj5nFn3PXQ7BMb8JlKUpEd+wRDN3dgAlTLc 19IfTAg== X-Received: from pjbei13.prod.google.com ([2002:a17:90a:e54d:b0:354:aa76:8270]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:6c8:b0:356:2872:9c50 with SMTP id 98e67ed59e1d1-35628729fb0mr5833088a91.35.1770671567603; Mon, 09 Feb 2026 13:12:47 -0800 (PST) Date: Mon, 9 Feb 2026 13:12:45 -0800 In-Reply-To: <20260209174559.GDaYodVxWsiesiedLJ@fat_crate.local> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260208164233.30405-1-clopez@suse.de> <20260208182849.GAaYjV4Vh8i0kznTEK@fat_crate.local> <20260208211342.GBaYj8hhtYM-lYfq-X@fat_crate.local> <20260209153243.GBaYn-G02QE86Fje7g@fat_crate.local> <20260209174559.GDaYodVxWsiesiedLJ@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 Mon, Feb 09, 2026, Borislav Petkov wrote: > On Mon, Feb 09, 2026 at 08:29:36AM -0800, Sean Christopherson wrote: > > Nope. KVM cares about what KVM can virtualize/emulate, and about helping userspace > > accurately represent the virtual CPU that will be enumerated to the guest. > > So why don't you key on that in those macros instead of how they're defined? > > EXPOSE_TO_GUEST_F() > > and then underneath we can figure out how to expose them. Huh? That's what the macros do, they describe KVM's handling of the associated feature. SYNTHESIZED is a bit weird because it bleeds some kernel details into KVM, but ultimately it's still KVM decision as to whether or not "forced" features can be synthesized for the guest. > We could have a helper table which determines what each feature is and how it > should interact with raw host CPUID or something slicker. > > > F : Features that must be present in boot_cpu_data and raw CPUID > > SCATTERED_F : Same as F(), but are scattered by the kernel > > X86_64_F : Same as F(), but are restricted to 64-bit kernels > > EMULATED_F : Always supported; the feature is unconditionally emulated in software > > SYNTHESIZED_F : Features that must be present in boot_cpu_data, but may or > > may not be in raw CPUID. May also be scattered. > > PASSTHROUGH_F : Features that must be present in raw CPUID, but may or may > > not be present in boot_cpu_data > > ALIASED_1_EDX_F : Features in 0x8000_0001.EDX that are duplicates of identical 0x1.EDX features > > VENDOR_F : Features that are controlled by vendor code, often because > > they are guarded by a vendor specific module param. Rules > > vary, but typically they are handled like basic F() features > > RUNTIME_F : Features that KVM dynamically sets/clears at runtime, but that > > are never adveristed to userspace. E.g. OSXSAVE and OSPKE. > > And for the time being, I'd love if this were somewhere in > arch/x86/kvm/cpuid.c so that it is clear how one should use those macros. I'll a patch with the above and more guidance. > The end goal of having the user not care about which macro to use would be the > ultimate, super-duper thing tho. And impossible, for all intents and purposes. The user/contributor/developer needs to define KVM's handling semantics *somehwere*. Sure, we could to that in a big array or something, but that's just a different way of dressing up the same pig. All of this very much is an ugly pig, but it's the concepts and mechanics that are ugly and convoluted. E.g. if we define a giant array or table, the contributor will need to map the feature to one of the above macros. In other words, kvm_initialize_cpu_caps() _is_ the helper table. If someone wants to try and do better, by all means, have at it. But I won't hold my breath.