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 EF87A156870 for ; Wed, 3 Apr 2024 21:42:34 +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=1712180556; cv=none; b=EUetJiB9da18MdRC93vKCWTYYd+vgUvT2HPLOFRnze7GMELCANrLou1KYOugCf81EDvGuPMwP54n7KBnt/qV9DWmO/rITw0Jt0ocq7txeuh/yjgbJgbcNsdmj7xGDTp14GGkVk1nsrGaUwqeSXh462OsReH/n9m1eO/jVKCQvKk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712180556; c=relaxed/simple; bh=MfA2fO46lhLsDa7FeVjwGuSV2tB/w58dfCGAPaFO8U8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=WbqoameCCREnJxeuyBMnhQA0VF2bHt333z65vWH0YSAJBlNRit2kTKN19skpZ3WcUdeB6QSTcvOqowSzmwGqxLNQWkBpBJz2ST/a5MLudl6uh6WdxxYJDxNhQ0s+WZ8TC4ccdCAVmTTpmz4hzhafcGhjZdqby7q4rvrYOTO2rFg= 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=S+UUXE09; 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="S+UUXE09" Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-6150e36ca0dso5912487b3.1 for ; Wed, 03 Apr 2024 14:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1712180554; x=1712785354; 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=lUlMHgGwPaVmm9YD6Wuiedxqqf2KvncEVELWkk3e+OQ=; b=S+UUXE09cJdUa81gZWcSfstzh9O9ww3wYPOyTSvYdQJRb5mvzwfQQ7MKnHFk0KA5Iq u4/eHGfDy83TdOg7oJYv2VFfAHuAlnDyCsYFZ9XVd3w53YErRGQzAPjtNVJtdErmEhlX yVsbHn1RnmxOxp5xclX5g681ohk7kam0vjJ+eWLSocD2o1uxA6K9axN79Pa0iEFYV8jI OAs9jxtgYHmXQaTCjjpAo0f2lPX5nWjYa9hx6ELgnJsIt6egRGdx4IpQUNC9dDvWjw4+ 2bdk9ET5dLLSqo5iMpSoABng8OkfEuO1bi3z867udnIgdYpOClJP8BHTdY4ancw0QAfa H8ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712180554; x=1712785354; 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=lUlMHgGwPaVmm9YD6Wuiedxqqf2KvncEVELWkk3e+OQ=; b=BsgqaxgwxXiO9E/oD/0vVaM3YYZROy8uZX2xAgfd9XhBvaBjkxmnEQCLFY3uok6Rqy Wngrk6Sqz54GEQHC7kfeOCTqAs/Wjsrv3/LYbKXreOFYhe6gHsbhpnepDR1VvolhYbSs nNEdcDmN4XOfJUZL06vA8TLcSNk1L1qnSvjCg4RiPHmyY/Sf+VmAlpZFSMozj/N/QbCp bZ9xFINU3g4xGe52BbqHgu8PZVMiYgsHOovICFY/1GARoV3WUfHxbnw2837ws1BMOKE8 K6LRvvcBi8CKT53Fb9NjJgldq9ke5ZCOAigjlUsnd9dl9ZHGTCL0mrBjcTOKQYx2CCWM 2NFA== X-Forwarded-Encrypted: i=1; AJvYcCVnmNYTytKG3wgc3v47ik2CJ0xc7mnFJNuYO77qGztBh8CsxE5YCv8RaWt5zJBAERGW1cFGkzPt1I2z0yw/aQLnbCoR1fAuPDTCF/d5 X-Gm-Message-State: AOJu0YzgY/9t1z8tzMbOxBNGqBxcK/7juraLxPsViyc7m5Mja5go35Yx DmEkMmQUOcgY0UXKEVi6wmDezvm5AOE6rpF+lQzSV/kQYkpIGeISIOPz9TXncW3XsG0YYiyP4KI DRw== X-Google-Smtp-Source: AGHT+IHJ0aJM/2/LrQ2a81R9ZzCCLWbQnc2e93zBV1KvHULAXpNMMmDoIEmSZqsw6e8KfWoOaLDoSEDUKRM= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:723:b0:dc6:c94e:fb85 with SMTP id l3-20020a056902072300b00dc6c94efb85mr55084ybt.2.1712180553949; Wed, 03 Apr 2024 14:42:33 -0700 (PDT) Date: Wed, 3 Apr 2024 21:42:32 +0000 In-Reply-To: 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-2-seanjc@google.com> <2a369e6e229788f66fb2bbf8bc89552d86ba38b9.camel@intel.com> Message-ID: Subject: Re: [PATCH v6 1/9] x86/cpu: KVM: Add common defines for architectural memory types (PAT, MTRRs, etc.) From: Sean Christopherson To: Kai Huang Cc: "luto@kernel.org" , "x86@kernel.org" , "dave.hansen@linux.intel.com" , "peterz@infradead.org" , "bp@alien8.de" , "mingo@redhat.com" , "tglx@linutronix.de" , "pbonzini@redhat.com" , Xin3 Li , "kvm@vger.kernel.org" , Shan Kang , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="us-ascii" On Thu, Apr 04, 2024, Kai Huang wrote: > On 4/04/2024 7:57 am, Sean Christopherson wrote: > > On Wed, Mar 27, 2024, Kai Huang wrote: > > > IIUC, the purpose of this patch is for the kernel to use X86_MEMTYPE_xx, which > > > are architectural values, where applicable? > > > > Maybe? Probably? > > > > > Yeah we need to keep MTRR_TYPE_xx in the uapi header, but in the kernel, should > > > we change all places that use MTRR_TYPE_xx to X86_MEMTYPE_xx? The > > > static_assert()s above have guaranteed the two are the same, so there's nothing > > > wrong for the kernel to use X86_MEMTYPE_xx instead. > > > > > > Both PAT_xx and VMX_BASIC_MEM_TYPE_xx to X86_MEMTYPE_xx, it seems a little bit > > > odd if we don't switch for MTRR_TYPE_xx. > > > > > > However by simple search MEM_TYPE_xx are intensively used in many files, so... > > > > Yeah, I definitely don't want to do it in this series due to the amount of churn > > that would be required. > > > > $ git grep MTRR_TYPE_ | wc -l > > 100 > > > > I'm not even entirely convinced that it would be a net positive. Much of the KVM > > usage that's being cleaned up is flat out wrong, e.g. using "MTRR" enums in places > > that having nothing to do with MTRRs. But the majority of the remaining usage is > > in MTRR code, i.e. isn't wrong, and is arguably better off using the MTRR specific > > #defines. > > Yeah understood. > > But the patch title says we also "add common defines for ... MTRRs", so to > me looks we should get rid of MTRR_TPYE_xx and use the common ones instead. > And it also looks a little bit inconsistent if we remove the PAT_xx but keep > the MTRR_TYPE_xx. > > Perhaps we can keep PAT_xx but add macros? > > #define PAT_UC X86_MEMTYPE_UC > ... > > But looks not nice either because the only purpose is to keep the PAT_xx.. Ya, keeping PAT_* is the only option I strongly object to. I have no problem replacing MTRR_TPYE_* usage, I would simply prefer not to do it in this series. And I obviously have no problem leaving the MTRR stuff as-is.