From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andy Lutomirski <luto@kernel.org>
Subject: Re: [intel-sgx-kernel-dev] [PATCH 08/10] kvm: vmx: add guest's
 IA32_SGXLEPUBKEYHASHn runtime switch support
Date: Sat, 20 May 2017 14:55:59 -0700
Message-ID: <CALCETrXYQCciYszYaGjL1-h+kf71AXq3YYJLyVNGpv1bCtxQZg@mail.gmail.com>
References: <20170508052434.3627-1-kai.huang@linux.intel.com>
 <20170508052434.3627-9-kai.huang@linux.intel.com> <58dcdb2d-6894-b0a3-8d6f-2ab752fd6d22@linux.intel.com>
 <CALCETrXG6KZEuxzDRwrAC5Wp=tCFaUBt4oPMQE40gdYB4p_A_Q@mail.gmail.com>
 <20170515124622.piupyk57vjdoppl5@intel.com> <478d9303-00b7-4f29-6124-0c1433851952@linux.intel.com>
 <1495030889.23465.13.camel@intel.com> <fc64a298-a15a-3fa6-413a-cca01623abe1@linux.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: Sean Christopherson <sean.j.christopherson@intel.com>,
        Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>, haim.cohen@intel.com,
        "intel-sgx-kernel-dev@lists.01.org"
        <intel-sgx-kernel-dev@lists.01.org>,
        kvm list <kvm@vger.kernel.org>,
        Radim Krcmar <rkrcmar@redhat.com>
To: "Huang, Kai" <kai.huang@linux.intel.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail.kernel.org ([198.145.29.99]:52006 "EHLO mail.kernel.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750748AbdETV4V (ORCPT <rfc822;kvm@vger.kernel.org>);
        Sat, 20 May 2017 17:56:21 -0400
Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com [209.85.217.175])
        (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
        (No client certificate requested)
        by mail.kernel.org (Postfix) with ESMTPSA id 17A7823990
        for <kvm@vger.kernel.org>; Sat, 20 May 2017 21:56:21 +0000 (UTC)
Received: by mail-ua0-f175.google.com with SMTP id u10so42298579uaf.1
        for <kvm@vger.kernel.org>; Sat, 20 May 2017 14:56:21 -0700 (PDT)
In-Reply-To: <fc64a298-a15a-3fa6-413a-cca01623abe1@linux.intel.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Thu, May 18, 2017 at 1:14 AM, Huang, Kai <kai.huang@linux.intel.com> wrote:
> You are making assumption that KVM will run ENCLS on behalf of guest. :)
>
> If we don't need to look into guest's SIGSTRUCT, EINITTOKEN, etc, then I
> actually prefer to using MTF, as with MTF we don't have to do all the
> remapping guest's virtual address to KVM's virtual address thing, if we
> don't need to look into guest's ENCLS parameter. But if we need to look into
> guest's ENCLS parameters, for example, to locate physical SECS page, or to
> update physical EPC page's info (that KVM needs to maintain), maybe we can
> choose running ENCLS on behalf of guest.

After thinking about this a bit, I don't see how MTF helps.
Currently, KVM works kind of like this:

local_irq_disable();
set up stuff;
VMRESUME;
restore some host state;
local_irq_enable();

If the guest is going to run with the EINIT-exiting bit clear, the
only way I see this working is to modify KVM along the lines of:

local_irq_disable();
set up stuff;
if (condition here) {
  WRMSR to SGXLEPUBKEYHASH;
  update percpu shadow copyl
  clear EINIT-exiting bit;
} else {
  set EINIT-exiting bit;
}
VMRESUME;
restore some host state;
local_irq_enable();

where "condition here" might be something like "the last VMRESUME
exited due to EINIT".

I don't see how MTF helps much.  And if I were the KVM maintainer, I
would probably prefer to trap EINIT instead of adding a special case
to the main vm entry code.