[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <778a6c80-a955-620d-a82a-c2ca82f26363@intel.com>
Date: Mon, 9 Jan 2023 17:22:08 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "Huang, Kai" <kai.huang@...el.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc: "Luck, Tony" <tony.luck@...el.com>,
"bagasdotme@...il.com" <bagasdotme@...il.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"Christopherson,, Sean" <seanjc@...gle.com>,
"Chatre, Reinette" <reinette.chatre@...el.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"Yamahata, Isaku" <isaku.yamahata@...el.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"Shahar, Sagi" <sagis@...gle.com>,
"imammedo@...hat.com" <imammedo@...hat.com>,
"Gao, Chao" <chao.gao@...el.com>,
"Brown, Len" <len.brown@...el.com>,
"sathyanarayanan.kuppuswamy@...ux.intel.com"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"Huang, Ying" <ying.huang@...el.com>,
"Williams, Dan J" <dan.j.williams@...el.com>
Subject: Re: [PATCH v8 11/16] x86/virt/tdx: Designate reserved areas for all
TDMRs
On 1/9/23 17:19, Huang, Kai wrote:
>> It's probably also worth noting *somewhere* that there's a balance to be
>> had between TDMRs and reserved areas. A system that is running out of
>> reserved areas in a TDMR could split a TDMR to get more reserved areas.
>> A system that has run out of TDMRs could relatively easily coalesce two
>> adjacent TDMRs (before the PAMTs are allocated) and use a reserved area
>> if there was a gap between them.
> We can add above to the changelog of this patch, or the patch 09 ("x86/virt/tdx:
> Fill out TDMRs to cover all TDX memory regions"). The latter perhaps is better
> since that patch is the first place where the balance of TDMRs and reserved
> areas is related.
>
> What is your suggestion?
Just put it close to the code that actually hits the problem so the
potential solution is close at hand to whoever hits the problem.
Powered by blists - more mailing lists