From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43C1BC433E9 for ; Wed, 17 Feb 2021 22:21:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 195DB64E85 for ; Wed, 17 Feb 2021 22:21:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232607AbhBQWV3 (ORCPT ); Wed, 17 Feb 2021 17:21:29 -0500 Received: from mail.kernel.org ([198.145.29.99]:32968 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233536AbhBQWV2 (ORCPT ); Wed, 17 Feb 2021 17:21:28 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4E83F64DFF; Wed, 17 Feb 2021 22:20:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613600447; bh=UYGkLLRxSgCWyallw/00M7Zbt1lN5wnAZcPj6AvPTOs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rGmSqnJ/bgYlkbI/Nmb7BAnQfb6kbXWq1IKVGBxApOBZIzYYV9BnhtJM+c8auLnAo d1ZuikagYjN7DiHixRNG9hk9SCxBPY0tUPjG0vJZWW/4ZJDLBHP7KMFyUqCMFEm/pr 79XXezqfmnzDtMt5fApn4S8fVtPJnx5BauXXMhNTH7+neaPO4GYIUANSVsOx07mIbO MRlOLLkEW4gU7DIYnWxrBnzu2C/XYj5DMOiiE+Q4YxySKFjuZJXGC3crocw3mvQvqG r4GJBDf0CPUjQIGI1NfWzzW7wzVlKnEmNdtj+TGoabHBb5n0o7jbjL+ri7g0B4iBip O5SyPnjspi2UQ== Date: Thu, 18 Feb 2021 00:20:35 +0200 From: Jarkko Sakkinen To: Dave Hansen Cc: Borislav Petkov , "Huang, Kai" , "linux-sgx@vger.kernel.org" , "kvm@vger.kernel.org" , "x86@kernel.org" , "seanjc@google.com" , "luto@kernel.org" , "Edgecombe, Rick P" , "Huang, Haitao" , "pbonzini@redhat.com" , "tglx@linutronix.de" , "mingo@redhat.com" , "hpa@zytor.com" Subject: Re: [RFC PATCH v5 08/26] x86/sgx: Expose SGX architectural definitions to the kernel Message-ID: References: <1d6fe6bd392b604091b57842c15cc5460aa92593.1613221549.git.kai.huang@intel.com> <20210216103218.GB10592@zn.tnic> <20210216114851.GD10592@zn.tnic> <9dca76b9-a0f9-a7aa-5d85-f8b43f89a3d2@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9dca76b9-a0f9-a7aa-5d85-f8b43f89a3d2@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On Tue, Feb 16, 2021 at 07:18:27AM -0800, Dave Hansen wrote: > On 2/16/21 3:48 AM, Borislav Petkov wrote: > > What I'm trying to point you at is, to not give some artificial reasons > > why the headers should be separate - artificial as the SDM says it > > is architectural and so on - but give a reason from software design > > perspective why the separation is needed: better build times, less > > symbols exposed to modules, blabla and so on. > > I think I actually suggested this sgx_arch.h split for SGX in the first > place. > > I was reading the patches and I had a really hard time separating the > hardware and software structures. There would be a 'struct sgx_foo {}' > and some chit chat about what it did... and I still had no idea if it > was an architectural structure or not. > > This way, it's 100% crystal clear what Linux is defining and what the > hardware defines from the diff context. Let's worry about split later on when we add "big" SGX specific features like EDMM, and consider this more like "move and rename". /Jarkko