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;
MIME-Version: 1.0
References: <cover.1612563142.git.sathyanarayanan.kuppuswamy@linux.intel.com> <2f386325-58f5-6f4d-060e-f0261b6f19ee@intel.com>
In-Reply-To: <2f386325-58f5-6f4d-060e-f0261b6f19ee@intel.com>
From:   Dan Williams <dan.j.williams@intel.com>
Date:   Mon, 12 Apr 2021 10:24:32 -0700
Message-ID: <CAPcyv4jx6cpdimDjyJtVkHLGmq_jcb0SWpz+Yx05iB0LM9CUyw@mail.gmail.com>
Subject: Re: [RFC v1 00/26] Add TDX Guest Support
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>,
        Andi Kleen <ak@linux.intel.com>,
        Kirill Shutemov <kirill.shutemov@linux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
        Raj Ashok <ashok.raj@intel.com>,
        Sean Christopherson <seanjc@google.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, Apr 4, 2021 at 8:02 AM Dave Hansen <dave.hansen@intel.com> wrote:
>
> It occurred to me that I've been doing a lot of digging in the TDX spec
> lately.  I think we can all agree that the "Architecture Specification"
> is not the world's easiest, most disgestable reading.  It's hard to
> figure out what the Linux relation to the spec is.
>
> One bit of Documentation we need for TDX is a description of the memory
> states.  For instance, it would be nice to spell out the different
> classes of memory, how they are selected, who selects them, and who
> enforces the selection.  What faults are generated on each type and who
> can induce those?
>
> For instance:
>
> TD-Private memory is selected by the Shared/Private bit in Present=1
> guest PTEs.  When the hardware page walker sees that bit, it walk the
> secure EPT.  The secure EPT entries can only be written by the TDX
> module, although they are written at the request of the VMM.  The TDX
> module enforces rules like ensuring that the memory mapped by secure EPT
> is not mapped multiple times.  The VMM can remove entries.  From the
> guest perspective, all private memory accesses are either successful, or
> result in a #VE.  Private memory access does not cause VMExits.
>
> Would that be useful to folks?

That paragraph was useful for me as someone coming in cold to TDX
patch review. +1 for more of that style of commentary.