Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp3580753ybf; Tue, 3 Mar 2020 08:29:05 -0800 (PST) X-Google-Smtp-Source: ADFU+vt0e1gmsu8a+uASH+g70jGcvpAYUbi+/FfIkN/802Epkgt8CoeotcvVzId6oivnXv73D+Nc X-Received: by 2002:aca:ec02:: with SMTP id k2mr3117989oih.105.1583252945430; Tue, 03 Mar 2020 08:29:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583252945; cv=none; d=google.com; s=arc-20160816; b=WGmdyu/ZX74cdWsjrl4FmpskcH7qq/aH3Q+PUjQ2B80V4H/7Do3+EwfQn/jzDOnPu+ PTQvA1tC7dafS04z+5TvQ4DM3w4aLodEl3VfktVgrhf/qctbLqmyGIbp9mGFakf6OqRm 2tbNldc5MFk9AUlqU+StjJY8rBK5PYEogAxVqUuaOnvAasCMVdAsDBy7go/sr1fXsHnp 4pXpazkdxoRrt5j6c+2cy81Xn263m0i1YshtoOL1MS33jVVF8G3iRfTVJbB5xjFvtAvM izFWGdy+2lXZr8OzbaKLd9b3r/x6SDj9p++4MQjBgWC8G/h2eeGf21gUrTffdmChY5aG APGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=8XlbvF41ksWuJIc2Q4SBnqb+Y7C+MScTmHcG+ZZKlS4=; b=rSj7EI79KzKfu/cEjjfpQm49PEZDinDYt6JbkyRxsvXYQ9dSnBCOCo0kpPGl5NTSCQ Q74dnaaqPRXya1UPcmUO4EFdS6rIW8GvTcJxC1sBUrRI1HVP/8L7FEWAQDg1Xw6BphYM EbCxb10oanYImOOKslBMw2kNvD2TVpHmOItb+jtZAXL51clj7L6ZrCdn+QiA4JIEGrJE Bdxu7ijM3ZCbwzJlwwuzw5acdSQt91lCv05x2zAgJ/5G0drl42yUIn7qXZZuvTVwlJY7 owwEvsjqzuUpvePTx3gAHcG7hQDW/RQ4mPzsvb7hv7KYpkrIXeYHVj+Scu+eMukOMmwh zg3w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y8si8848376otq.122.2020.03.03.08.28.53; Tue, 03 Mar 2020 08:29:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730393AbgCCQ2K (ORCPT + 99 others); Tue, 3 Mar 2020 11:28:10 -0500 Received: from mga07.intel.com ([134.134.136.100]:18741 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730385AbgCCQ2K (ORCPT ); Tue, 3 Mar 2020 11:28:10 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2020 08:28:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,511,1574150400"; d="scan'208";a="287035714" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by FMSMGA003.fm.intel.com with ESMTP; 03 Mar 2020 08:28:08 -0800 Date: Tue, 3 Mar 2020 08:28:08 -0800 From: Sean Christopherson To: Paolo Bonzini Cc: Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jan Kiszka , Xiaoyao Li Subject: Re: [PATCH 3/6] KVM: x86: Add dedicated emulator helper for grabbing CPUID.maxphyaddr Message-ID: <20200303162808.GJ1439@linux.intel.com> References: <20200302195736.24777-1-sean.j.christopherson@intel.com> <20200302195736.24777-4-sean.j.christopherson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 03, 2020 at 09:48:03AM +0100, Paolo Bonzini wrote: > On 02/03/20 20:57, Sean Christopherson wrote: > > Add a helper to retrieve cpuid_maxphyaddr() instead of manually > > calculating the value in the emulator via raw CPUID output. In addition > > to consolidating logic, this also paves the way toward simplifying > > kvm_cpuid(), whose somewhat confusing return value exists purely to > > support the emulator's maxphyaddr calculation. > > > > No functional change intended. > > I don't think this is a particularly useful change. Yes, it's not > intuitive but is it more than a matter of documentation (and possibly > moving the check_cr_write snippet into a separate function)? I really don't like duplicating the maxphyaddr logic. I'm paranoid something will come along and change the "effective" maxphyaddr and we'll forget all about the emulator, e.g. SEV, TME and paravirt XO all dance around maxphyaddr.