Re: [PATCH 19/26] x86/tdx: Make pages shared in ioremap()

From: Dave Hansen
Date: Tue Jan 04 2022 - 19:43:15 EST


On 1/4/22 4:31 PM, Kirill A. Shutemov wrote:
> On Tue, Jan 04, 2022 at 12:36:06PM -0800, Dave Hansen wrote:
>> @@ -57,7 +58,6 @@ typedef struct { unsigned long iopte; }
>> typedef struct { unsigned long pmd; } pmd_t;
>> typedef struct { unsigned long pgd; } pgd_t;
>> typedef struct { unsigned long ctxd; } ctxd_t;
>> -typedef struct { unsigned long pgprot; } pgprot_t;
>> typedef struct { unsigned long iopgprot; } iopgprot_t;
>>
>> #define pte_val(x) ((x).pte)
>> @@ -85,7 +85,6 @@ typedef unsigned long iopte_t;
>> typedef unsigned long pmd_t;
>> typedef unsigned long pgd_t;
>> typedef unsigned long ctxd_t;
>> -typedef unsigned long pgprot_t;
>> typedef unsigned long iopgprot_t;
>>
>> #define pte_val(x) (x)
>
> Any arch that use STRICT_MM_TYPECHECKS hacks will get broken if compiled
> without the define (as sparc by default).

My read of STRICT_MM_TYPECHECKS was that "typedef unsigned long
pgprot_t" produces better code, but "typedef struct { unsigned long
pgprot; } pgprot_t;" produces better type checking.

I just compiled these patches on sparc with no issues.

...
> Is it the way to go we want?

I _think_ this was all a result of some review feedback from Tom
Lendacky about where the encryption-modifying pgprot helpers got placed
in the code. I don't feel strongly about it, but I'm not quite sure
that this is worth the trouble.

I'd be curious what Tom thinks now that he's gotten a peek at what it's
going to take to address his concerns.