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 AC18234DCD1 for ; Wed, 4 Mar 2026 16:23:34 +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=1772641415; cv=none; b=XbBEm85d5CVaVAdl9CKQ3o+snUywbtC7lDAo7SRlODgrHO4+1+ShRn8zqVkQQi/LZgmr4I9A87Ye+6whl/5veIsyaJg+H/Q4Tc8MtLIpulev5SjlOtEn3Qcdwlk2m1HgErxfv5vRfVL0LrZJxIaiAjdg3rLymP3qGtZMSEuO73M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772641415; c=relaxed/simple; bh=+59wknHGTRW+W9SSh+h7PF3GSLLzGVapIaIAou5Ber0=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=A/qGGAxkbRHP31z6G+kd2JlPydi74nwxjSAa9+lkALAK5Q0RWn8X4TUJdqhRrkG7OVNnEIo3knELBiWCxwF8MPDYDOyYtGtqQWQmzzv9lBEX/A0u/tXHvP3/kaoX+PG4beTcY2wtOilHDijYWTt/+vB+3q7HXa46sSySRUAcVlQ= 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=qttMyaJY; 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="qttMyaJY" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2ae3badc00dso46686545ad.3 for ; Wed, 04 Mar 2026 08:23:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772641414; x=1773246214; 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=yrzSKo5+wXzomm7lL9SdcMFqNMmtfJshxUqsLyJWiLk=; b=qttMyaJYEkbbGPVshz/281IVwU/9Xus572XoR7cZ/lJhVdLZwGGGo0qSNqOi7zd+kO 8dxI/FIHnMJYBd64NhGYhgGdTB2O7L0RhpejDVKzVeMyCou2bfPsuoZDKdZsQ+Dv/lVS mLunqPQAYUupxi/U/PmgW5EowL9CQKCqarelt4pb2Aoche0PNojPzSaRVE0ZeeZFcK7K uVa4u6OQF/hZMowLwsxmU3VBwL3Fk0xqP+Mat9Kgn1Dff5KvYA4gDwlHplL9GMM9gS0f SS+QSWGs28kxsys8+SYuYOLO5rsricW3+MH7T8ovNGXhVmvy66/nyXOqFEEHhcIC9h3R l0Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772641414; x=1773246214; 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=yrzSKo5+wXzomm7lL9SdcMFqNMmtfJshxUqsLyJWiLk=; b=nhQ/WpI2ZBOPS8oZdtJA3HlnyW4K6Yp8VB1QxWKRoY02OPKKAjSdB97a/S4PI0fmzJ m9lVCESbgIRHFHfG8W8gpR/3jd5GrPB2UpudNwcrH3Rc+ionaISMEeT3YC6szyVH9lo+ FXBrHKqyeyNLRCsEbIe5It0OwNaDtFrmtSx41miFjzKdmDENFAXKSVzmM4EQn+fyBMY3 6YIGOPG83phZD5bQ0h1Sq9JCoo3S61mwqf+O+IxR6ANtipa+K7GuXgOtIrS5Xq0Om2/M iLTkMUO0MhKa4BNA7UPZRRbLUBRuNwPGTzppzOfcCu+ubAadvvKLU9aVe6XrAzYmgB0P 39ug== X-Forwarded-Encrypted: i=1; AJvYcCUM1/u0kQ8Hgp7bEmnZA0Yr85NaJ5ud3iiXG3f3vXdsU0i6XSiOdtklVshYAKXVt9YAUj0sjnIEDylbyf8=@vger.kernel.org X-Gm-Message-State: AOJu0YySuGyoRx4ddbY5Y5t+6zupY1SwdVDpFuOpDNKXPar6qKUsq+en ydPJxfYbQBcw7cnbl4X3Vq4fPp+PGoHkKpkDQdvw3xid4ALF9anHILNoKpJ+EmvbaqZgj89kiS6 2OhFY2g== X-Received: from play21.prod.google.com ([2002:a17:902:e195:b0:2ae:5075:50d4]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:b4f:b0:2ae:3b9b:db41 with SMTP id d9443c01a7336-2ae6ab4305fmr29611105ad.38.1772641413940; Wed, 04 Mar 2026 08:23:33 -0800 (PST) Date: Wed, 4 Mar 2026 08:23:32 -0800 In-Reply-To: <8731e234-22b8-4ccf-89ef-63feed09e9c5@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-8-xin@zytor.com> <8731e234-22b8-4ccf-89ef-63feed09e9c5@linux.intel.com> Message-ID: Subject: Re: [PATCH v9 07/22] KVM: VMX: Initialize VMCS FRED fields From: Sean Christopherson To: Binbin Wu Cc: "Xin Li (Intel)" , 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, chao.gao@intel.com, hch@infradead.org, sohil.mehta@intel.com Content-Type: text/plain; charset="us-ascii" On Wed, Jan 21, 2026, Binbin Wu wrote: > On 10/27/2025 4:18 AM, Xin Li (Intel) wrote: > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > > index fcfa99160018..c8b5359123bf 100644 > > --- a/arch/x86/kvm/vmx/vmx.c > > +++ b/arch/x86/kvm/vmx/vmx.c > > @@ -1459,6 +1459,15 @@ void vmx_vcpu_load_vmcs(struct kvm_vcpu *vcpu, int cpu) > > (unsigned long)(cpu_entry_stack(cpu) + 1)); > > } > > > > + /* Per-CPU FRED MSRs */ Meh, this is pretty self-explanatory code. > > + if (kvm_cpu_cap_has(X86_FEATURE_FRED)) { > > +#ifdef CONFIG_X86_64 > > Nit: > > Is this needed? > > FRED is initialized by X86_64_F(), if CONFIG_X86_64 is not enabled, this > path is not reachable. > There should be no compilation issue without #ifdef CONFIG_X86_64 / #endif. > > There are several similar patterns in this patch, using #ifdef CONFIG_X86_64 / > #endif or not seems not consistent. E.g. __vmx_vcpu_reset() and init_vmcs() > doesn't check the config, but here does. > > > + vmcs_write64(HOST_IA32_FRED_RSP1, __this_cpu_ist_top_va(ESTACK_DB)); > > + vmcs_write64(HOST_IA32_FRED_RSP2, __this_cpu_ist_top_va(ESTACK_NMI)); > > + vmcs_write64(HOST_IA32_FRED_RSP3, __this_cpu_ist_top_va(ESTACK_DF)); IMO, this is flawed for other reasons. KVM shouldn't be relying on kernel implementation details with respect to what FRED stack handles what event. The simplest approach would be to read the actual MSR. _If_ using a per-CPU read provides meaningful performance benefits over RDMSR (or RDMSR w/ immediate? I don't see an API for that...), then have the kernel provide a dedicated accessor. Then the accessor can be a non-inlined functions, and this code can be e.g.: if (IS_ENABLED(CONFIG_X86_64) && kvm_cpu_cap_has(X86_FEATURE_FRED)) { vmcs_write64(HOST_IA32_FRED_RSP1, fred_rsp(MSR_IA32_FRED_RSP1)); vmcs_write64(HOST_IA32_FRED_RSP2, fred_rsp(MSR_IA32_FRED_RSP2)); vmcs_write64(HOST_IA32_FRED_RSP3, fred_rsp(MSR_IA32_FRED_RSP2)); } where fred_rsp() is _declared_ unconditionally, but implemented only for 64-bit. That way the compiler will be happy, and the actual usage will be dropped before linking via dead-code elimination. Actually, we can probably do one better? if (cpu_feature_enabled(X86_FEATURE_FRED) && kvm_cpu_cap_has(X86_FEATURE_FRED)) {