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 4A8FA3ED5B9 for ; Fri, 6 Mar 2026 16:24:56 +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=1772814299; cv=none; b=LZbJXIUAlWqciKgEfRTp6rwP0UJAN7mVr3XwxWBdiOQ1S0GdeMVaVPN6hOiO2ZH+7vU6kEdrGWQ7/KuU1iFxgospNcuqN9K+CcKASis6yTj7uHAzDXSOwzKw1YxYYmaq2bqPKx16lp3+ia5l/4Tl5clZZNFmfzg7Yx7KAeqshTw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772814299; c=relaxed/simple; bh=nne6hfkcWfjwMq1RQmckYFoDq6sA/Hf2xSpxcsa2Lno=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Tx+JsnMPYVNpGrF+8cdWR91HWfk19v/Sxo6JzjidKO3rychVukLeQo9snxA7S7banm/HPeVW0OF1fuAdWhLqTCVxZlsphjmFekZ+pcFlEc1jFhga6HJoNIzfvqkUAYVxXtApDIEdksfbBV1xWbbx85ELAINN5btuj7mfBbXMZPA= 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=aNzMGWV7; 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="aNzMGWV7" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2ae65d5cc57so172280235ad.2 for ; Fri, 06 Mar 2026 08:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772814295; x=1773419095; 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=uf5NkfTgzKe1e6zjeS2xh88bJlDrw2IsrPqKeeEk998=; b=aNzMGWV72oX7NOdvqsC7g0D6xzsVlnd3h6faUsWgOvZTSfw86Hrj2uIGKUZDeQKCwp /M/RNI6k54ZtH86pkFYxpzCgcI17l4ugc8/aZ7Ezq7RekUjEkZd5Dh2EEfGY776uTfmC 7YPajNYTAV16ozsdWX3HdjGiPMxHRVJqwWairxjTlB0DTtNMWMTNCNzfYqfpkrbpPuFt 5MwJ0WI01Q9ecvP2uwAUv5pF/xO5tgfVAxTuEbmK0/uZ2KmzmMyxGwFIETfHBdGNfuEW ycHyYdbgMGLpzaNtxVDR8w7IuFvYyWQW0HccIn2Ncqvq7mwlPd8jVijIWCWgRjJ+Z9iT F23g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814295; x=1773419095; 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=uf5NkfTgzKe1e6zjeS2xh88bJlDrw2IsrPqKeeEk998=; b=PWMPPykdjFzg9PwndCLkf9ayM1lnCU9QKBsVwHCBgu7ciZcEBf0xkddd/QgnSKS5BC GCRDfoHdsDOYbbpvdKRdVALQg8qOZlBjTr0qtp9QjrVsesvWVK7aMKQ9AM95KEt3Gg1Y C6pZd4aUy+y/eKhwKxrVucl38WeZWxhwpg0ILbPji/S2W1TbWuLjhdI+JUmoqYVKmXIj LupDbJ9ivclUlvxLSp2ZMB6ohWONtWiABzzbdfSfGezD+s+om2YAVqgIUszCILUUMKdf rH9rrtv2JCpHQsJllaIMGn0YjbkeaHZrGCtPdkTV00O/Ujd14ZBsfW/U23/IkRm+sCtK b7/g== X-Forwarded-Encrypted: i=1; AJvYcCWLFIjL35R10bAPXrbB2mPUmRCVeY3XqchAHJl30oh12beEPGjwd44auNVl2NXvCA4I0tBEzYzn8fjK4Vo=@vger.kernel.org X-Gm-Message-State: AOJu0Yxpa7I1ih9LLRHPF0SQRROCfX+GFf7Fow+Z/1oyufSzyaa+OmC8 4vODHp+T0AKWmjaviytKrFnyTm9rdkUilTkxZiBgTAnaRD4+KdQNP3Mf3/BIaUzOog0MMfDfkxO 0FYTApA== X-Received: from plblf3.prod.google.com ([2002:a17:902:fb43:b0:2ae:3bf5:af0f]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:3bac:b0:2ae:8081:c5a0 with SMTP id d9443c01a7336-2ae8245e0afmr29642405ad.39.1772814295233; Fri, 06 Mar 2026 08:24:55 -0800 (PST) Date: Fri, 6 Mar 2026 08:24:54 -0800 In-Reply-To: <1795684a-b453-440e-88bb-035993d9deab@lanxincomputing.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260305235416.4147213-1-xin@zytor.com> <1795684a-b453-440e-88bb-035993d9deab@lanxincomputing.com> Message-ID: Subject: Re: [PATCH v1] KVM: VMX: Remove unnecessary parentheses From: Sean Christopherson To: BillXiang Cc: "Xin Li (Intel)" , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com Content-Type: text/plain; charset="us-ascii" On Fri, Mar 06, 2026, BillXiang wrote: > On 3/6/2026 7:54 AM, Xin Li (Intel) wrote: > > From: Xin Li > > > > Drop redundant parentheses; & takes precedence over &&. > > I would not recommend relying on default operator precedence. Eh, in practice, the kernel heavily relies on operator precedence all over the place, so I'm not worried about correctness. But as you note below, judicious use of parentheses can help readability. > > Signed-off-by: Xin Li > > --- > > arch/x86/kvm/vmx/capabilities.h | 10 +++++----- > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/arch/x86/kvm/vmx/capabilities.h b/arch/x86/kvm/vmx/capabilities.h > > index 4e371c93ae16..0dad9e7c4ff4 100644 > > --- a/arch/x86/kvm/vmx/capabilities.h > > +++ b/arch/x86/kvm/vmx/capabilities.h > > @@ -107,7 +107,7 @@ static inline bool cpu_has_load_perf_global_ctrl(void) > > > > static inline bool cpu_has_load_cet_ctrl(void) > > { > > - return (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_CET_STATE); > > + return vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_CET_STATE; > > } > > > > static inline bool cpu_has_save_perf_global_ctrl(void) > > @@ -162,7 +162,7 @@ static inline bool cpu_has_vmx_ept(void) > > static inline bool vmx_umip_emulated(void) > > { > > return !boot_cpu_has(X86_FEATURE_UMIP) && > > - (vmcs_config.cpu_based_2nd_exec_ctrl & SECONDARY_EXEC_DESC); > > + vmcs_config.cpu_based_2nd_exec_ctrl & SECONDARY_EXEC_DESC; > > } > > > > static inline bool cpu_has_vmx_rdtscp(void) > > @@ -376,9 +376,9 @@ static inline bool cpu_has_vmx_invvpid_global(void) > > > > static inline bool cpu_has_vmx_intel_pt(void) > > { > > - return (vmcs_config.misc & VMX_MISC_INTEL_PT) && > > - (vmcs_config.cpu_based_2nd_exec_ctrl & SECONDARY_EXEC_PT_USE_GPA) && > > - (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_RTIT_CTL); > > + return vmcs_config.misc & VMX_MISC_INTEL_PT && > > + vmcs_config.cpu_based_2nd_exec_ctrl & SECONDARY_EXEC_PT_USE_GPA && > > + vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_RTIT_CTL; > > } > > Removing the parentheses could significantly reduce code readability here. +1. For cases like cpu_has_load_cet_ctrl() where it's a single statement, I'm 100% in favor of dropping the parentheses because they're pure noise. E.g. putting them in the return statement is kinda like doing this: if ((vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_CET_STATE)) But for code where there are multiple checks, IMO it's totally fine to use parentheses, and probably even encourage. Can you send a v2 to just clean up cpu_has_load_cet_ctrl()? Ah, and the changelog will need to be different, because there's no &&, which is another argument for treating "return x & y;" differently.