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.2 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 F3594C433E6 for ; Tue, 16 Mar 2021 12:48:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AD79C65054 for ; Tue, 16 Mar 2021 12:48:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232902AbhCPMrs (ORCPT ); Tue, 16 Mar 2021 08:47:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:56422 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232844AbhCPMqb (ORCPT ); Tue, 16 Mar 2021 08:46:31 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7914165039; Tue, 16 Mar 2021 12:46:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1615898791; bh=Ur86/kQH+7n2c1T3Xl1ln8o4FtX9RoHOK0NxalNWD8I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=csjAgYsd3yGhqD4TtqAl+ZYjIzLIQDBHXkXrWz2H8IONUDfMqhqdUqtQcOyKR1I/O LkN3e5KvxbgC7R3Wi4zyjdAMeRk3YRGHNDNzDf4umO+OQID0waSfjE6/MsrVmudg2V tCPUcx6kWN/9ZhMCXRjxzAJHfyrM63FaKSLZ1M/ORSJlB+o9qtNbAxvmWXIebLryAR 4X12nAzSlOeFN+vVYdeIpzYZk1c+Rhb+XzO7MT7LCLp6HPjuTTXSAbV/yyIKq8Prrz 3+sfbo6UVDxz8s8WsVwWbLaKOT7qG10FHFfi8XmTrfdWUyYDko7UqowSZyZWM3YBtK NQM5dtN3ORBwQ== Date: Tue, 16 Mar 2021 14:46:05 +0200 From: Jarkko Sakkinen To: Sean Christopherson Cc: Kai Huang , kvm@vger.kernel.org, linux-sgx@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, luto@kernel.org, dave.hansen@intel.com, rick.p.edgecombe@intel.com, haitao.huang@intel.com, pbonzini@redhat.com, bp@alien8.de, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com Subject: Re: [PATCH v2 07/25] x86/sgx: Initialize virtual EPC driver even when SGX driver is disabled Message-ID: References: <20210315161317.9c72479dfcde4e22078abcd2@intel.com> <20210316094859.7b5947b743a81dff7434615c@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 15, 2021 at 06:13:53PM -0700, Sean Christopherson wrote: > On Tue, Mar 16, 2021, Jarkko Sakkinen wrote: > > On Tue, Mar 16, 2021 at 01:05:05AM +0200, Jarkko Sakkinen wrote: > > > The way I've understood it is that given that KVM can support SGX > > > without FLC, vEPC should be available even if driver cannot be > > > enabled. > > > > > > This is also exactly what the short summary states. > > > > > > "Initialize virtual EPC driver even when SGX driver is disabled" > > > > > > It *does not* state: > > > > > > "Initialize SGX driver even when vEPC driver is disabled" > > > > > > Also, this is how I interpret the inline comment. > > > > > > All this considered, the other direction is undocumented functionality. > > > > Also: > > > > 1. There is *zero* good practical reasons to support the "2nd direction". > > Uh, yes there is. CONFIG_KVM_INTEL=n and X86_FEATURE_VMX=n, either of which > will cause vEPC initialization to fail. The former is obvious, the latter is > possible via BIOS configuration. Hmm... So you make the checks as if ret != -ENODEV? That's the sane way to deal with that situation IMHO. /Jarkko