From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.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 40E40149C79 for ; Thu, 25 Apr 2024 14:42:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714056127; cv=none; b=DuYhZvtjZ4xGG5JicH+osOUF4aJzjCv66YQRNwtFvrYuivIbaFUwsMAjx9ffbQjnk265ltjzsD3hVTCfA63f1+6YhCcW3qiVjDYWPAoYpSsdkAsf7K/XwPjEmYkAO1TU7RxKcd56gNh500IK0qi3qwzaKXIDFYN2KhczNB+MEoo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714056127; c=relaxed/simple; bh=2HTb1/D2zJKsTz0x8dg2JPZ7AoAiGX0TfTBOVZ7lUok=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=PzN+LZUWT6kBj0oT+4VPb6IC7WiftppBpHDl4as3l8GH58c6Z7q/Es++6e2NANXiXv6C3oANUafEELUk+Jg6pLmA13xmURJS8PGK6brgBpiUwcqU7acxu7c+zTFdlTi0ty35ro6d8bSygn1J5k2H42rQI+pqoREPLlz05WACpaU= 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=x4Wwt5C6; arc=none smtp.client-ip=209.85.219.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="x4Wwt5C6" Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-de5823bd7eeso2353032276.0 for ; Thu, 25 Apr 2024 07:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1714056125; x=1714660925; 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=lDWCaTYULwF8F3zi592tmuoj8LcUAihXwO8QYVH28dw=; b=x4Wwt5C6hHRlcYDRs995liII8ZAoKfJ/K+N8bnJmVXX2igKQ7cMdCugkF51lNBM9Op P6hjJKUzNHAb9hkUtPhOWcFZHYjm97E3EZ+J6bJrLpKmgg4mQ5uJrHN4IQwHGbNpvxEP S2JwivEI1xD1IuUD422B+FRmrHvRpNFUWuWK03UBJA1l70O9wYS+WByYZGStRykVZh2/ 9EzKxkpElQH1Qd367hEAjELuWkofggcE7SgC6WEeQZGMK9d3fIRJBT+tT2xfSpeVj1aA FDmQ9TN2CzewaSN/aAzpySL4zYwCk+KlJpscn6sbBp2Mi8qR9u1KuOWCmi+u2OsSuM7I Gx3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714056125; x=1714660925; 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=lDWCaTYULwF8F3zi592tmuoj8LcUAihXwO8QYVH28dw=; b=B7U2LGAKH+8UgQIUzXKhvugL4kY797TSKYb0enAW/T+s/CWxUtOSMPRTr77rMdYU1j ehOigMnuVCNlTAY5YeqHDtBEOXMdeZNtwYplDt+1MaUeKEvLxks4OY6qsvQPWExPv0j2 pQRg/SvOJzW9TxGMZEkCHf8pQ0FCWt/Lm5uKDyImRd/zQBlc2a+/OP0ad9NahuEdltyq E/zKXZb4bFt4GLBZ5O6GUFUT1s34aBkSyRC48N5FC8D6o8FVKPr8vNJ++3J49rBjwhbD DVI9Sz7UCxp96ViO8RAybUJl417o5q8+PeqfCN+eQtkNM5DEb+6TwnhFTg8PN5HwIQpt Vuhw== X-Forwarded-Encrypted: i=1; AJvYcCXmEQEc5FZJeX+a8QopTAzgUNu6KwuEmbGx8gd0S7vNBuoaEuVVKAPPaSycXTOV65zWnJXPn63mBdr0XGYvzkFMR0I/KOzWipwu+pEM X-Gm-Message-State: AOJu0Ywb37wzqNuwc0+yfgAV0H4+Sgw2Dv+12+ysV9ySHXHN5nrYw8en wWwdMiYCzKm0JWFqSVwxWrFU4M41VT/exs0knGwCKpsCQZ3gWDeRg9NaQgdVAgL7eHh6JJxuWGW L3A== X-Google-Smtp-Source: AGHT+IF/g7wUX2d++6yDgZVRNlO+BsKqxODd8ENXt8KXPp295gAemRTfNn6a6plk1Xwk4cOuJTp3H44r+mI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:c12:b0:de4:6624:b763 with SMTP id fs18-20020a0569020c1200b00de46624b763mr945449ybb.0.1714056125345; Thu, 25 Apr 2024 07:42:05 -0700 (PDT) Date: Thu, 25 Apr 2024 07:42:03 -0700 In-Reply-To: <64cc46778ccc93e28ec8d39b3b4e31842154f382.camel@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240309012725.1409949-1-seanjc@google.com> <20240309012725.1409949-9-seanjc@google.com> <1e063b73-0f9a-4956-9634-2552e6e63ee1@intel.com> <64cc46778ccc93e28ec8d39b3b4e31842154f382.camel@intel.com> Message-ID: Subject: Re: [PATCH v6 8/9] KVM: VMX: Open code VMX preemption timer rate mask in its accessor From: Sean Christopherson To: Kai Huang Cc: Xiaoyao Li , "luto@kernel.org" , Xin3 Li , "x86@kernel.org" , "dave.hansen@linux.intel.com" , "peterz@infradead.org" , Zhao1 Liu , "mingo@redhat.com" , "tglx@linutronix.de" , "bp@alien8.de" , "pbonzini@redhat.com" , "kvm@vger.kernel.org" , Shan Kang , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="us-ascii" On Thu, Apr 25, 2024, Kai Huang wrote: > On Wed, 2024-04-24 at 13:06 -0700, Sean Christopherson wrote: > > > > static inline u32 vmx_basic_vmcs_mem_type(u64 vmx_basic) > > > > { > > > > return (vmx_basic & GENMASK_ULL(53, 50)) >> > > > > VMX_BASIC_MEM_TYPE_SHIFT; > > > > } > > > > > > > > looks not intuitive than original patch. > > > > > > Yeah, agreed, that's taking the worst of both worlds. I'll update patch 5 to drop > > > VMX_BASIC_MEM_TYPE_SHIFT when effectively "moving" it into vmx_basic_vmcs_mem_type(). > > > > Drat. Finally getting back to this, dropping VMX_BASIC_MEM_TYPE_SHIFT doesn't > > work because it's used by nested_vmx_setup_basic(), as is VMX_BASIC_VMCS_SIZE_SHIFT, > > which is presumably why past me kept them around. > > > > I'm leaning towards keeping things as proposed in this series. I don't see us > > gaining a third copy, or even a third user, i.e. I don't think we are creating a > > future problem by open coding the shift in vmx_basic_vmcs_mem_type(). And IMO > > code like this > > > > return (vmx_basic & VMX_BASIC_MEM_TYPE_MASK) >> > > VMX_BASIC_MEM_TYPE_SHIFT; > > > > is an unnecessary obfuscation when there is literally one user (the accessor). > > > > Another idea would be to delete VMX_BASIC_MEM_TYPE_SHIFT and VMX_BASIC_VMCS_SIZE_SHIFT, > > and either open code the values or use local const variables, but that also seems > > like a net negative, e.g. splits the effective definitions over too many locations. > > Alternatively, we can add macros like below to close to > vmx_basic_vmcs_size() etc, so it's straightforward to see. > > +#define VMX_BSAIC_VMCS12_SIZE ((u64)VMCS12_SIZE << 32) > +#define VMX_BASIC_MEM_TYPE_WB (MEM_TYPE_WB << 50) Hmm, it's a bit hard to see it's specifically VMCS12 size, and given that prior to this series, VMX_BASIC_MEM_TYPE_WB = 6, I'm hesitant to re-introduce/redefine that macro with a different value. What if we add a helper in vmx.h to encode the VMCS info? Then the #defines for the shifts can go away because the open coded shifts are colocated and more obviously related. E.g. static inline u64 vmx_basic_encode_vmcs_info(u32 revision, u16 size, u8 memtype) { return revision | ((u64)size << 32) | ((u64)memtype << 50); } and static void nested_vmx_setup_basic(struct nested_vmx_msrs *msrs) { /* * This MSR reports some information about VMX support. We * should return information about the VMX we emulate for the * guest, and the VMCS structure we give it - not about the * VMX support of the underlying hardware. */ msrs->basic = vmx_basic_encode_vmcs_info(VMCS12_REVISION, VMCS12_SIZE, X86_MEMTYPE_WB); msrs->basic |= VMX_BASIC_TRUE_CTLS if (cpu_has_vmx_basic_inout()) msrs->basic |= VMX_BASIC_INOUT; }