From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.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 441481DF74D for ; Mon, 28 Oct 2024 18:27:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730140061; cv=none; b=QfM59trWejeQuhPtYJKUF/K4AFMSF15ECE3rD07Hk5uIOFAyqzZ7LKEX/aX+Ek55Vu7SLi8ypB0fAE0EY7TIR/0JTAFMYFiovl10Hr8VoV7VcLsCBD/0PqfBF5b3FPdjOmhhbYOxU8jbZqIbRa3ba2K1loWacKWD+rrMkHXVtog= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730140061; c=relaxed/simple; bh=b1S1kMmCum00nro+Vr3336NHK/tiVehkGpWnxsKKwWw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Tw5TuKLZ8sRPQ1MdHINBJZYbQtGsMXtc324eBb6097HDRDgaoHAtdnAql+K2bhhy5p0vlTyLeJa73+8/q4T/9CGQVOK3bdrNmA3kWwugqQ0wk4lur28IzIA+Osd+nlU2lyIt+1FVpoJt0/+rZC3CqhU0T380iDaYGLAHc7PaekE= 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=dIJp2+P5; arc=none smtp.client-ip=209.85.128.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="dIJp2+P5" Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-6e1fbe2a6b1so94835427b3.2 for ; Mon, 28 Oct 2024 11:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1730140058; x=1730744858; 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=cmnbZOU0qjIEimURD21SxRpoBoMeIUpyXKqWoTkNi2A=; b=dIJp2+P5X5PHVU8BE/doOTRgmnSVZxdnbz1OZM8RcfVnZSmOpPc9vMaZ4g6O5fliiK Lsj1+wGw5dgihVYMbItp2+oHmp1s52H/tv38LGlMVo8ZUa6QCh6ptHB/LmlmIJMXtQ7m uZT8ZDG9AX2mKEkY8j+4iHtvuacpJRsTLNaFaqNXYqs5IOdpJhfK2pQllemwf6ccR4DX 5qDnDeinhdrME/SEveYh0vszejw9eVoOFVs+7P4J63Xyowwtb+nDihI92dWgErXSxJtU TRGSuWaghojh3XQGhw7Wt6AhIV5ehLclk1k0tZVQQXj7ueqoclII86rEfB61nDweIvfq gMuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730140058; x=1730744858; 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=cmnbZOU0qjIEimURD21SxRpoBoMeIUpyXKqWoTkNi2A=; b=ooLpHf3+SOng+DHn7QHYC68uviCs36lsJ6yRwrsjwVTNZN6d8Bqj0gyQQwlkmax9hs /7qP0bBcNklEEsoLnyzcBoGm6dXl7fh8egFrKsnNuwCPMNAMoIt38D2XI6oPj4n5fexR a3UWACd7uKQDLfZRlGaE3OnJtRQcV9bfAzKoWKu07393zJz0LoPkno3IRFp8y8/VVvxz kBTt3Okqxfd4bOHG1d0ICG7S3c5b2nAYDGZd7YrxO4sm6prQx2G/qex9lNcGRpZAbQ0j 8YdvJHqQu/dqvpUUCYLegmH/ZPhmdUoDRVPLlDP4P3tMx3u4gDW5+E7dnPUG2atoS3Yi HOyA== X-Forwarded-Encrypted: i=1; AJvYcCXv3RZL54VkMr0f17S5rU0WugCz0ONjxawuvCzLLJJjZoG+yeRuESeF/7xuaUD/g9w6qmrylJK7REWdSgs=@vger.kernel.org X-Gm-Message-State: AOJu0YwGhlRv9bH7XZgFkOEC0QklduYVazMmYSZFjbEjZtRxdoAyeYb+ TDxnmP/ZpE/sOhNlsmn3k7XrpTLQy3xKf2IX2v6jLCK+mV19jXmYql6q9EtS16W/oa+tItm0OI6 JTQ== X-Google-Smtp-Source: AGHT+IFn240YgEA2N2ByflWwnKUPX22a8Bmi+G7kKnmPMa+4cJwROFpduXbMAKP/dP2eb/K6QoAQDQFEUeI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:9d:3983:ac13:c240]) (user=seanjc job=sendgmr) by 2002:a25:b28e:0:b0:e29:6df8:ef58 with SMTP id 3f1490d57ef6-e3087a5bd64mr65240276.4.1730140058246; Mon, 28 Oct 2024 11:27:38 -0700 (PDT) Date: Mon, 28 Oct 2024 11:27:36 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20241001050110.3643764-1-xin@zytor.com> <20241001050110.3643764-26-xin@zytor.com> Message-ID: Subject: Re: [PATCH v3 25/27] KVM: nVMX: Add FRED VMCS fields From: Sean Christopherson To: Chao Gao Cc: Xin Li , kvm@vger.kernel.org, linux-kernel@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 Content-Type: text/plain; charset="us-ascii" On Mon, Oct 28, 2024, Chao Gao wrote: > On Fri, Oct 25, 2024 at 12:25:45AM -0700, Xin Li wrote: > >> > static void nested_vmx_setup_cr_fixed(struct nested_vmx_msrs *msrs) > >> > diff --git a/arch/x86/kvm/vmx/nested.h b/arch/x86/kvm/vmx/nested.h > >> > index 2c296b6abb8c..5272f617fcef 100644 > >> > --- a/arch/x86/kvm/vmx/nested.h > >> > +++ b/arch/x86/kvm/vmx/nested.h > >> > @@ -251,6 +251,14 @@ static inline bool nested_cpu_has_encls_exit(struct vmcs12 *vmcs12) > >> > return nested_cpu_has2(vmcs12, SECONDARY_EXEC_ENCLS_EXITING); > >> > } > >> > > >> > +static inline bool nested_cpu_has_fred(struct vmcs12 *vmcs12) > >> > +{ > >> > + return vmcs12->vm_entry_controls & VM_ENTRY_LOAD_IA32_FRED && > >> > + vmcs12->vm_exit_controls & VM_EXIT_ACTIVATE_SECONDARY_CONTROLS && > >> > + vmcs12->secondary_vm_exit_controls & SECONDARY_VM_EXIT_SAVE_IA32_FRED && > >> > + vmcs12->secondary_vm_exit_controls & SECONDARY_VM_EXIT_LOAD_IA32_FRED; > >> > >> Is it a requirement in the SDM that the VMM should enable all FRED controls or > >> none? If not, the VMM is allowed to enable only one or two of them. This means > >> KVM would need to emulate FRED controls for the L1 VMM as three separate > >> features. > > > >The SDM doesn't say that. But FRED states are used during and > >immediately after VM entry and exit, I don't see a good reason for a VMM > >to enable only one or two of the 3 save/load configs. Not KVM's concern. > >Say if VM_ENTRY_LOAD_IA32_FRED is not set, it means a VMM needs to > >switch to guest FRED states before it does a VM entry, which is > >absolutely a big mess. Again, not KVM's concern. > If the VMM doesn't enable FRED, it's fine to load guest FRED states before VM > entry, right? Yep. Or if L1 is simply broken and elects to manually load FRED state before VM-Enter instead of using VM_ENTRY_LOAD_IA32_FRED, then any badness that happens is 100% L1's problem to deal with. KVM's responsiblity is to emulate the architectural behavior, what L1 may or may not do is irrelevant. > The key is to emulate hardware behavior accurately without making assumptions > about guests. +1000 > If some combinations of controls cannot be emulated properly, KVM > should report internal errors at some point.