Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <b456ea7c-18be-3397-0115-fa25007741bf@intel.com>
Date:   Thu, 8 Jun 2023 16:43:43 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [PATCH v11 12/20] x86/virt/tdx: Allocate and set up PAMTs for
 TDMRs
Content-Language: en-US
To:     kirill.shutemov@linux.intel.com, Kai Huang <kai.huang@intel.com>
Cc:     linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        linux-mm@kvack.org, tony.luck@intel.com, peterz@infradead.org,
        tglx@linutronix.de, seanjc@google.com, pbonzini@redhat.com,
        david@redhat.com, dan.j.williams@intel.com,
        rafael.j.wysocki@intel.com, ying.huang@intel.com,
        reinette.chatre@intel.com, len.brown@intel.com, ak@linux.intel.com,
        isaku.yamahata@intel.com, chao.gao@intel.com,
        sathyanarayanan.kuppuswamy@linux.intel.com, bagasdotme@gmail.com,
        sagis@google.com, imammedo@redhat.com
References: <cover.1685887183.git.kai.huang@intel.com>
 <4e108968c3294189ad150f62df1f146168036342.1685887183.git.kai.huang@intel.com>
 <20230608232452.yrx2tekugkvral4z@box>
From:   Dave Hansen <dave.hansen@intel.com>
In-Reply-To: <20230608232452.yrx2tekugkvral4z@box>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 6/8/23 16:24, kirill.shutemov@linux.intel.com wrote:
>>  	ret = -EINVAL;
>> +	if (ret)
>> +		tdmrs_free_pamt_all(&tdx_tdmr_list);
>> +	else
>> +		pr_info("%lu KBs allocated for PAMT.\n",
>> +				tdmrs_count_pamt_pages(&tdx_tdmr_list) * 4);
> "* 4"? This is very cryptic. procfs uses "<< (PAGE_SHIFT - 10)" which
> slightly less magic to me. And just make the helper that returns kilobytes
> to begin with, if it is the only caller.

Let's look at where this data comes from:

+static unsigned long tdmrs_count_pamt_pages(struct tdmr_info_list
*tdmr_list)
+{
+	unsigned long pamt_npages = 0;
+	int i;
+
+	for (i = 0; i < tdmr_list->nr_consumed_tdmrs; i++) {
+		unsigned long pfn, npages;
+
+		tdmr_get_pamt(tdmr_entry(tdmr_list, i), &pfn, &npages);
+		pamt_npages += npages;
+	}

OK, so tdmr_get_pamt() is getting it in pages.  How is it *stored*?

+static void tdmr_get_pamt(struct tdmr_info *tdmr, unsigned long *pamt_pfn,
+			  unsigned long *pamt_npages)
+{
...
+	pamt_sz = tdmr->pamt_4k_size + tdmr->pamt_2m_size + tdmr->pamt_1g_size;
++	*pamt_pfn = PHYS_PFN(pamt_base);
+	*pamt_npages = pamt_sz >> PAGE_SHIFT;
+}

Oh, it's actually stored in bytes.  So to print it out you actually
convert it from bytes->pages->kbytes.  Not the best.

If tdmr_get_pamt() just returned 'pamt_size_bytes', you could do one
conversion at:

	free_contig_range(pamt_pfn, pamt_size_bytes >> PAGE_SIZE);

and since tdmrs_count_pamt_pages() has only one caller you can just make
it:  tdmrs_count_pamt_kb().  The print becomes:

	pr_info("%lu KBs allocated for PAMT.\n",
		tdmrs_count_pamt_kb(&tdx_tdmr_list) * 4);

and tdmrs_count_pamt_kb() does something super fancy like:

	return pamt_size_bytes / 1024;

which makes total complete obvious sense and needs zero explanation.