Messages in this thread | | | Date | Thu, 20 May 2021 19:33:22 +0000 | From | Sean Christopherson <> | Subject | Re: [RFC v2 27/32] x86/tdx: Exclude Shared bit from __PHYSICAL_MASK |
| |
On Thu, May 20, 2021, Kuppuswamy, Sathyanarayanan wrote: > Hi Dave, > > On 5/19/21 9:14 AM, Dave Hansen wrote: > > On 4/26/21 11:01 AM, Kuppuswamy Sathyanarayanan wrote: > > > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> > > > > > > tdx_shared_mask() returns the mask that has to be set in a page > > > table entry to make page shared with VMM. > > > > Here's a rewrite: > > > > Just like MKTME, TDX reassigns bits of the physical address for > > metadata. MKTME used several bits for an encryption KeyID. TDX uses a > > single bit in guests to communicate whether a physical page should be > > protected by TDX as private memory (bit set to 0) or unprotected and > > shared with the VMM (bit set to 1). > > > > Add a helper, tdg_shared_mask() (bad name please fix it) to generate the > > Initially we have used tdx_* prefix for the guest code. But when the code from > host side got merged together, we came across many name conflicts.
Whatever the conflicts are, they are by no means an unsolvable problem. I am more than happy to end up with slightly verbose names in KVM if that's what it takes to avoid "tdg".
> So to avoid such issues in future, we were asked not to use the "tdx_" prefix > and our alternative choice was "tdg_".
Who asked you not to use tdx_? More specifically, did that feedback come from a maintainer (or anyone on-list), or was it an Intel-internal decision?
> Also, IMO, "tdg" prefix is more meaningful for guest code (Trusted Domain Guest) > compared to "tdx" (Trusted Domain eXtensions). I know that it gets confusing > when grepping for TDX related changes. But since these functions are only used > inside arch/x86 it should not be too confusing. > > Even if rename is requested, IMO, it is easier to do it in one patch over > making changes in all the patches. So if it is required, we can do it later > once these initial patches were merged.
Hell no, we are not merging known bad crud that requires useless churn to get things right.
| |