From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (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 67EFF13D281 for ; Mon, 27 Jan 2025 15:24:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737991492; cv=none; b=J2i048yZyO3E8OWmUTYnkmfzlp27qHr/00/sL9z6xcRk3aJAhvKDA9p2/fGPbSm69pYenAWy4DZ39xQBYUlTXk2gliFhO2IitEGcz/edchDhwZSN/vglovWnd3DZg+VGA5Srs3UMY5IQPPVMl0l6wvWbkfKtS4Png5wERrwmklY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737991492; c=relaxed/simple; bh=MEueiGx/CLwPsfh2pRO44ZyYAyS3IlpdV7imm8VQ6Mo=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=bau37Ld+WFLVbb3CyxGmed5YTCpx6Sa7SPSpqZnerDbPMRu9FY0tY0q5a2nqRNNUONc6SC0ZroC9O/h8svNkdmIT56RWxLQKUVk+z9CS+HUDq+1ElGmFjAr5pvlqyFm13ilYU2AwR9N5nNAbJmZ6DZT2FRmWuIZoxOYlc+DwPOM= 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=KzQhmbMo; arc=none smtp.client-ip=209.85.214.201 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="KzQhmbMo" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-216750b679eso59879515ad.1 for ; Mon, 27 Jan 2025 07:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737991488; x=1738596288; 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=ZoeCnFd5J5xnYNqBdU/ogFWqB8J8v68mjfzwpWs3ZH8=; b=KzQhmbMo/mDMJCETzdx3R4liMfMNBr7z4vR08sWBbM7v2yAPToM/lVfCfkGlnsnGFQ WhI3fU8Bulrf8qiWe8QNgfYps+u1KLhsjDq+FwHwtrYQSnS0SlHHJPoD+/3AW+PJAgYi ++12sjhT38K+z9pc2CrJG6kx2UJgRad82qgKfME3ecXjoFWu4PferYe8FhWP0K0QI6xg mec4htibiXj97HRRPh/AOf1c13a6CL3xfcuRFPUS4KlQn14g/yiVPBzxS6jpqRazFrYK 4YSWDfoq/LnwRNQnR4YQgaOoBqAciBaOfLZigfBxTNQjRmFR/aVpjiFxl6tDJR9eG+MS +kIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737991488; x=1738596288; 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=ZoeCnFd5J5xnYNqBdU/ogFWqB8J8v68mjfzwpWs3ZH8=; b=kZatldIMc6nF2/MuyRaV6Jx4uupi4g45hMXcNrFfmbQuEhiiAZkSx8qV97HTxc28vA 4gUOu22tnQfOHuiHkb9n2JiSDchysVFta0GuHsF4OGMoaqwMyuXin4ag2jOtXpyDsIx6 VNAg164OEkHZaK2CuA50clT2uUDKWVH7DFUk1Ez3L3AgRMHNUQ07lo781nnSqS1D0Wvc zOnGFjao35/JYhdMcxylNWsLdTjTuLSezMAslUj2Lkyp8keIV2eT8zhVjvd/p9wWfIF9 BPVSPK0kvq7ETLN1Lz/mS882SQnEtwBIbk9I/oTZGclsR4IWzD9kXUBLzHNG67258xOE nN8g== X-Forwarded-Encrypted: i=1; AJvYcCV0dp7vUW7hlUyd+SnnKfRslmgdMBBcdPUhAq2ezNMZWJIoj9TWyIUksXbhqwCvWj3QxoK7ZWutz42l748=@vger.kernel.org X-Gm-Message-State: AOJu0Yw2Il40qz3QUrCt3oQ6KvdD5x2/8WZYfzgpzN3v9cbOyrxhgoWa UyjZYiH/mSkGRpHxuIQ6xZh7U8eYEVP8ybyAIKwa7bhUJJ+gVY6T4VAMd3i9GqFR2fw7B+LpMfc XqQ== X-Google-Smtp-Source: AGHT+IHYoJa0BkqdkhXtUYNXMnIfXT2Kp07cJDVu8LU5YEcGtlhbUTPDhn5/CB6e3hG2xZH+iB3g+iJMLng= X-Received: from pgbcl22.prod.google.com ([2002:a05:6a02:996:b0:7fd:5461:1ff6]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:3d86:b0:1e0:9cc2:84b1 with SMTP id adf61e73a8af0-1eb2158d07amr68681560637.30.1737991488591; Mon, 27 Jan 2025 07:24:48 -0800 (PST) Date: Mon, 27 Jan 2025 07:24:42 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250124163741.101568-1-pbonzini@redhat.com> Message-ID: Subject: Re: [GIT PULL] KVM changes for Linux 6.14 From: Sean Christopherson To: Linus Torvalds Cc: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Sat, Jan 25, 2025, Linus Torvalds wrote: > On Fri, 24 Jan 2025 at 08:38, Paolo Bonzini wrote: > > > > but you can throw away the <<<< ... ==== part completely, and apply the > > same change on top of the new implementation: > > > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > > index edef30359c19..9f9a29be3beb 100644 > > --- a/arch/x86/kvm/cpuid.c > > +++ b/arch/x86/kvm/cpuid.c > > @@ -1177,6 +1177,7 @@ void kvm_set_cpu_caps(void) > > EMULATED_F(NO_SMM_CTL_MSR), > > /* PrefetchCtlMsr */ > > F(WRMSR_XX_BASE_NS), > > + F(SRSO_USER_KERNEL_NO), > > SYNTHESIZED_F(SBPB), > > SYNTHESIZED_F(IBPB_BRTYPE), > > SYNTHESIZED_F(SRSO_NO), > > Ehh. My resolution ended up being different. > > I did this instead: > > F(WRMSR_XX_BASE_NS), > SYNTHESIZED_F(SBPB), > SYNTHESIZED_F(IBPB_BRTYPE), > SYNTHESIZED_F(SRSO_NO), > + SYNTHESIZED_F(SRSO_USER_KERNEL_NO), > > which (apart from the line ordering) differs from your suggestion in > F() vs SYNTHESIZED_F(). > > That really seemed to be the RightThing(tm) to do from the context of > the two conflicting commits, but maybe there was some reason that I > didn't catch that you kept it as a plain "F()". Heh, I waffled on whether SRSO_USER_KERNEL_NO should be F() or SYNTHESIZED_F() when the initial commit went in. I would prefer to keep it F(), though it doesn't matter terribly at the moment. The "synthesized" features are for cases where the kernel stuffs X86_FEATURE_xxx via set_cpu_cap() even when the feature isn't present in CPUID, and it's correct for KVM to relay the synthesized feature to the guest. E.g. SRSO_NO is synthesized into cpu_caps for Zen1/2, and in that case the absense of the SRSO flaw extends to the guest as well. if (boot_cpu_data.x86 < 0x19 && !cpu_smt_possible()) { setup_force_cpu_cap(X86_FEATURE_SRSO_NO); return; } For SRSO_USER_KERNEL_NO, it's currently not force set, i.e. it's a pure reflection of hardware capabilities. Treating it as synthesized is effectively a nop with the current code, but that would change if the kernel were to force set the flag. If a future commit force set SRSO_USER_KERNEL_NO because of a ucode update that didn't also modify CPUID behavior, then treating the flag as synthesized would be desirabled, e.g. so that the guest could also avoid the overhead of mitigating SRSO. But if a future commit set the flag for some other reason, e.g. if the kernel somehow isn't vulnerable even when running on buggy hardware, then enumerating SRSO_USER_KERNEL_NO to the guest could cause the guest kernel to incorrectly skips its mitigation. My vote is to err on the side of caution and go with F().