[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9dacbb0b-6c0a-fb35-e03b-eb4241045d78@intel.com>
Date: Thu, 20 May 2021 13:30:09 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Kuppuswamy, Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Tony Luck <tony.luck@...el.com>
Cc: Andi Kleen <ak@...ux.intel.com>,
Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
Raj Ashok <ashok.raj@...el.com>,
Sean Christopherson <seanjc@...gle.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC v2 27/32] x86/tdx: Exclude Shared bit from __PHYSICAL_MASK
On 5/20/21 11:48 AM, Kuppuswamy, Sathyanarayanan wrote:
>>> +/* The highest bit of a guest physical address is the "sharing"
>>> bit */
>>> +phys_addr_t tdg_shared_mask(void)
>>> +{
>>> + return 1ULL << (td_info.gpa_width - 1);
>>> +}
>>
>> Why not just inline this thing? Functions don't get any smaller than
>> that. Or does it not get used anywhere else? Or are you concerned
>> about exporting td_info?
>
> We don't want to export td_info. It has more information additional to
> shared mask details. Any reason for suggesting to use inline?
My favorite reason is that it eliminates the need for three declarations:
1. An extern for the header
2. A stub for the header
3. The real function in the .c file.
An inline removes two places that might get out of sync in some way and
eliminates the need to check two implementation sites when grepping.
Not in this case, but in general, inlines also result in faster, more
compact code since the compiler has more visibility into what the
function does at its call sites.
Not wanting to export td_info _is_ a reasonable argument, though.
Powered by blists - more mailing lists