[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CB372B69-7B1C-44B6-A4C3-179C7387B8FC@zytor.com>
Date: Tue, 20 Jan 2026 10:04:57 -0800
From: Xin Li <xin@...or.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Binbin Wu <binbin.wu@...ux.intel.com>, Chao Gao <chao.gao@...el.com>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
linux-doc@...r.kernel.org, pbonzini@...hat.com, corbet@....net,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
luto@...nel.org, peterz@...radead.org, andrew.cooper3@...rix.com,
hch@...radead.org, sohil.mehta@...el.com
Subject: Re: [PATCH v9 17/22] KVM: x86: Advertise support for FRED
> On Jan 20, 2026, at 7:25 AM, Sean Christopherson <seanjc@...gle.com> wrote:
>
>>>
>>> What I have missed?
>
> The userspace VMM, e.g. QEMU, is completely irrelevant. KVM must not advertise
> support for features it doesn't actually implement, and more importantly must not
> internally treat such features as supported.
Right, FRED virtualization is not supported on AMD and obviously SVM will
need to add FRED virtualization in their own fashion later.
>
>> If a newer QEMU (with AMD's FRED support patch) + an older KVM (without AMD'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 interaction
> with KVM, I don't think we can confidently say that incorrectly treating FRED as
> supported is benign for the host. It's a moot point, I just want to emphasize
> how it important it is that KVM doesn't over-report features.
I will remove it on AMD.
Powered by blists - more mailing lists