Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: tan22k0OQbCP8nEBO8iRsSuiLRsf9f+diONMhKaGoIpHM2ZoselvMATxhn9Whhn2jm+GMHTwRW
 Rvd3UMDa6nrA==
IronPort-SDR: L1Oqxf6/YcrJyEasuyDTiubV0+zBzpPaR+R4cvg4+ud+99ycMSH3Ewdk0x8ansxYeg50vsFXuj
 2sHSiX+XAqGQ==
Subject: Re: [RFC v2-fix-v2 1/1] x86: Introduce generic protected guest
 abstractionn
To:     Borislav Petkov <bp@alien8.de>,
        "Kirill A. Shutemov" <kirill@shutemov.name>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>,
        Dave Hansen <dave.hansen@intel.com>,
        Tony Luck <tony.luck@intel.com>,
        Andi Kleen <ak@linux.intel.com>,
        Kirill Shutemov <kirill.shutemov@linux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
        Dan Williams <dan.j.williams@intel.com>,
        Raj Ashok <ashok.raj@intel.com>,
        Sean Christopherson <seanjc@google.com>,
        linux-kernel@vger.kernel.org,
        Tom Lendacky <thomas.lendacky@amd.com>
References: <20210527042356.3983284-2-sathyanarayanan.kuppuswamy@linux.intel.com>
 <20210601211417.2177598-1-sathyanarayanan.kuppuswamy@linux.intel.com>
 <YLkcIuL2qvo0hviU@zn.tnic> <YLkcUts9dWDkDKpY@zn.tnic>
 <20210607195544.qlya6i5s2l2fkms2@box> <YL5+JkxaQbN4pNqD@zn.tnic>
From:   "Kuppuswamy, Sathyanarayanan" 
        <sathyanarayanan.kuppuswamy@linux.intel.com>
Message-ID: <fcc0d043-105b-79e4-f138-9888e7952549@linux.intel.com>
Date:   Mon, 7 Jun 2021 15:26:51 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <YL5+JkxaQbN4pNqD@zn.tnic>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 6/7/21 1:14 PM, Borislav Petkov wrote:
> On Mon, Jun 07, 2021 at 10:55:44PM +0300, Kirill A. Shutemov wrote:
>> I think conversions like this are wrong: relocate_kernel(), which got
>> called here, only knows how to deal with SME, not how to handle some
>> generic case.
> 
> What do you mean wrong? Wrong for TDX?
> 
> If so, then that can be
> 
> protected_guest_has(SME)
> 
> or so, which would be false on Intel.

I agree. Since most of the code changed in this patch is
not applicable to TDX, it might need product specific or
new function specific flags.

> 
> And this patch was only a mechanical conversion to see how it would look
> like.
> 
>> If code is written to handle a specific technology we need to stick
>> with a check that makes it clear. Trying to make sound generic only
>> leads to confusion.
> 
> Sure, fine by me.
> 
> And I don't want a zoo of gazillion small checking functions per
> technology. sev_<something>, tdx_<something>, yadda yadda.
> 
> So stuff better be unified. Even if you'd have vendor-specific defines
> you hand into that function - and you will have such - it is still much
> saner than what it turns into with the AMD side of things.

Agree. Currently we share code with AMD SEV in memory encryption support and
string I/O handling code. So defining common flag for such code is
useful.

> 

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer