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 1B17C44D695 for ; Tue, 20 Jan 2026 15:25:15 +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=1768922717; cv=none; b=dKFC8X2a2nfD1/iB3AXqCXGc7lvZSeuiDFE+giQOra84DSCMqgipCafzeQND0+7B0huk1PylTN3gg7caz7HfSewcGSRRUNt3+Pzi5NWT3tcHYce/y7nYBQn3eSJ2P620ePJLRVJmsjmysPwGlV+c5Eoi55RiLaiHxRmBCb3ruLE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768922717; c=relaxed/simple; bh=Vr1w8/hRlrBVQxV/J2giFIsqc9Obiu5qNwZxH6Kan84=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=n5eakXvwtVHwi6OG2p9i4QCcX3VTocPqQ4fr8duJa4Fs2A45fFc+doUBdZn9/HtlLBmuMPWlBJKnPzkD4YLuQEBM0yqo8dzt4pmzDng4sDkTOpIdzGe3VXb56thkvmyB1im7wdKafK5Qy1UpcvN+Ymz4oNbhaVOo0PXFX7Rr970= 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=i/nUckfs; 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="i/nUckfs" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-2a13be531b2so52716645ad.2 for ; Tue, 20 Jan 2026 07:25:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1768922715; x=1769527515; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=UZLSVE2MzemDrn9erRb2jucT/zlZ8W02NgFFC89SMHc=; b=i/nUckfsUDWExv4d/o+j6+CYPL8bgKLLUEPMHIR8Ytv+QtnCRyzWmxhIos1svsDPM0 9m/nA23JRXNV6enPp3ijYDYffpGxuYxj9WAeQXN9RTJlwlLvJz3zeyAkMB26J4i4oE3i jFWmClUtX2fsbl17kK+DuVmwjGwnZ2aHY4pek/KFc3KMp9jC4x8EFLK+cG6d5drfn10/ qKfOruiLeAXCKqZbP6iWafXnCiz7kXHThpXOoIEtgc2+IBSNbeN7SgKrG7RI0uNRmGVH S7tlQg9omNJ8mclN7vfWyX6lg51ToM6wKzrJsb+Wo80DDdDkXKcqwZmbSIrWqNkUtCeL aITA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768922715; x=1769527515; h=content-transfer-encoding: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=UZLSVE2MzemDrn9erRb2jucT/zlZ8W02NgFFC89SMHc=; b=LuK6TZOOnLMexHewA9uMhaJsdcwi7mYxQW8AN4FSm6m8xCQZ1qbjGfs9uvfv3qRHGw D0U1KqyaxKHNGdvCDG/TA9in/eojHYIM4W7ClDsPIjuXPyLDXSLU4KSD+FewMQKusYXG s8Y0knBvGS3j4EKZzpFYpVfaOqhJ7VJwVXXKoQI6kvnRtcy9sXGy+ERL3/1Lrw5rt1zI bmSCCPmbiSbQj2AGp0DV2K3NXX5EKiyhDhJj5BSoqGzzl0wPjmheYOc/XfssgRbcY+44 FdMXN4dXgZhjLgBoOUtO1ccKsghFJ3Mh8pERivupWWe70V9Iik7FNvVE/cu9TC31i+mt T8bg== X-Forwarded-Encrypted: i=1; AJvYcCXP8ztTVG5DFLNgvNF35MhIb/ajvdn00PH+taPvh+rRscptuVonlZEkOVYYJDXwP7hAPKfyHiLp1yrd07A=@vger.kernel.org X-Gm-Message-State: AOJu0YwX6HQXKkUrw9F8Aao7iLal3+r7XRrPBj49rud2ah6Pb0HQQh6K WnhkWzpHSriJ1Z9WNtcSFDw4HZos0rJw6WdbSkam/qsiFB4xYUEqYOB9g9jlIw8s35vRRMhnvKc yujs44Q== X-Received: from plps11.prod.google.com ([2002:a17:902:988b:b0:2a0:e5e4:2e05]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:e80b:b0:267:a95d:7164 with SMTP id d9443c01a7336-2a717808c2dmr127036045ad.60.1768922715334; Tue, 20 Jan 2026 07:25:15 -0800 (PST) Date: Tue, 20 Jan 2026 07:25:13 -0800 In-Reply-To: <04d96812-f74a-4f43-9ea4-c4f2723251c5@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251026201911.505204-1-xin@zytor.com> <20251026201911.505204-18-xin@zytor.com> <71F2B269-4D29-4B23-9111-E43CDD09CF13@zytor.com> <04d96812-f74a-4f43-9ea4-c4f2723251c5@linux.intel.com> Message-ID: Subject: Re: [PATCH v9 17/22] KVM: x86: Advertise support for FRED From: Sean Christopherson To: Binbin Wu Cc: Xin Li , Chao Gao , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, pbonzini@redhat.com, corbet@lwn.net, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, peterz@infradead.org, andrew.cooper3@citrix.com, hch@infradead.org, sohil.mehta@intel.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 20, 2026, Binbin Wu wrote: > On 1/20/2026 5:09 PM, Xin Li wrote: > >> On Jan 20, 2026, at 12:07=E2=80=AFAM, Chao Gao wr= ote: > >> > >> On Mon, Jan 19, 2026 at 10:56:29PM -0800, Xin Li wrote: > >>> > >>> > >>>> On Nov 11, 2025, at 11:30=E2=80=AFPM, Chao Gao = wrote: > >>>> > >>>> I'm not sure if AMD CPUs support FRED, but just in case, we can clea= r FRED > >>>> i.e., kvm_cpu_cap_clear(X86_FEATURE_FRED) in svm_set_cpu_caps(). > >>> > >>> AMD will support FRED, with ISA level compatibility: > >>> > >>> https://www.amd.com/en/blogs/2025/amd-and-intel-celebrate-first-anniv= ersary-of-x86-ecosys.html > >>> > >>> Thus we don=E2=80=99t need to clear the bit. > >> > >> In this case, we need to clear FRED for AMD. > >> > >> The concern is that before AMD's FRED KVM support is implemented, FRED= will be > >> exposed to userspace on AMD FRED-capable hardware. This may cause issu= es. > >=20 > > Hmm, I think it=E2=80=99s Qemu does that. > >=20 > > We have 2 filters, one in Qemu and one in KVM, only both are set a feat= ure is enabled. > >=20 > > What I have missed? The userspace VMM, e.g. QEMU, is completely irrelevant. KVM must not adver= tise support for features it doesn't actually implement, and more importantly mu= st not internally treat such features as supported. > If a newer QEMU (with AMD's FRED support patch) + an older KVM (without A= MD's > FRED support, but KVM advertises it), it may cause issues. Yep. > I guess it's no safety issue for host though, Maybe. Without fully analyzing the SVM implementation for FRED and its int= eraction with KVM, I don't think we can confidently say that incorrectly treating FR= ED as supported is benign for the host. It's a moot point, I just want to emphas= ize how it important it is that KVM doesn't over-report features.