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;
Date:   Wed, 16 Feb 2022 18:37:03 +0300
From:   "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To:     Borislav Petkov <bp@alien8.de>
Cc:     Dave Hansen <dave.hansen@intel.com>,
        Tom Lendacky <thomas.lendacky@amd.com>, tglx@linutronix.de,
        mingo@redhat.com, luto@kernel.org, peterz@infradead.org,
        sathyanarayanan.kuppuswamy@linux.intel.com, aarcange@redhat.com,
        ak@linux.intel.com, dan.j.williams@intel.com, david@redhat.com,
        hpa@zytor.com, jgross@suse.com, jmattson@google.com,
        joro@8bytes.org, jpoimboe@redhat.com, knsathya@kernel.org,
        pbonzini@redhat.com, sdeep@vmware.com, seanjc@google.com,
        tony.luck@intel.com, vkuznets@redhat.com, wanpengli@tencent.com,
        x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2 22/29] x86/tdx: Make pages shared in ioremap()
Message-ID: <20220216153703.42wnvgxcvshgpkj2@black.fi.intel.com>
References: <1d77e91c-e151-7846-6cd4-6264236ca5ae@intel.com>
 <YgFWpGQfA84Y0mW/@zn.tnic>
 <20220214220926.fjwlyieatwjhcpij@black.fi.intel.com>
 <f1dfc268-7b2f-9980-27ce-0b5bb1aea962@amd.com>
 <20220215154118.ldpvvk5seljntl44@black.fi.intel.com>
 <dd21e54a-a431-4d6f-47b7-ab1a3e8e0cc8@amd.com>
 <20220215162722.cvzik5r57spr2krz@black.fi.intel.com>
 <52e34ee2-e6a8-5b5c-41f9-5fcf21902a25@intel.com>
 <20220215173321.lwvfl6rxifrkcoit@black.fi.intel.com>
 <YgzKymHnbAUAVSMT@zn.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YgzKymHnbAUAVSMT@zn.tnic>
Precedence: bulk

On Wed, Feb 16, 2022 at 10:58:34AM +0100, Borislav Petkov wrote:
> On Tue, Feb 15, 2022 at 08:33:21PM +0300, Kirill A. Shutemov wrote:
> > Like cc_mkencrypted()/cc_mkdecrypted()? I donno. Looks strange.
> 
> cc_mkenc/cc_mkdec probably.

Okay, what about this:

	static u64 cc_mask;

	pgprotval_t cc_mkenc(pgprotval_t protval)
	{
		if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
			return protval & ~cc_mask;
		else
			return protval | cc_mask;
	}

	pgprotval_t cc_mkdec(pgprotval_t protval)
	{
		if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
			return protval | cc_mask;
		else
			return protval & ~cc_mask;
	}
	EXPORT_SYMBOL_GPL(cc_mkdec);

	__init void cc_init(void)
	{
		if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
			cc_mask = tdx_shared_mask();
		else
			cc_mask = sme_me_mask;
	}

I did not introduce explicit vendor variable but opted for
X86_FEATURE_TDX_GUEST to check vendor. There's no X86_FEATURE counter part
on AMD side presumably because it get used too early to be functional.

TDX needs cc_platform_has() later and X86_FEATURE infrastructure is
already functional there (and we can benefit from static branch).

cc_init() got called from sme_enable() for AMD and from tdx_early_init()
for TDX.

I also reworked cc_platform_has() to use combination of
X86_FEATURE_TDX_GUEST and cc_mask to route to right helper:

	bool cc_platform_has(enum cc_attr attr)
	{
		if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
			return intel_cc_platform_has(attr);
		else if (cc_mask)
			return amd_cc_platform_has(attr);
		else if (hv_is_isolation_supported())
			return hyperv_cc_platform_has(attr);
		else
			return false;
	}

Any opinions?

-- 
 Kirill A. Shutemov