Re: [RFC PATCH v4 04/26] x86/sgx: Add SGX_CHILD_PRESENT hardware error code

From: Kai Huang <kai.huang@intel.com>
To: Sean Christopherson <seanjc@google.com>,
	Dave Hansen <dave.hansen@intel.com>
Cc: linux-sgx@vger.kernel.org, kvm@vger.kernel.org, x86@kernel.org,
	jarkko@kernel.org, luto@kernel.org, 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: [RFC PATCH v4 04/26] x86/sgx: Add SGX_CHILD_PRESENT hardware error code
Date: Wed, 10 Feb 2021 10:03:02 +1300	[thread overview]
Message-ID: <ddc22787d6d4abf51c47b28ec6fe6df85d0fea3e.camel@intel.com> (raw)
In-Reply-To: <YCLBQYq2HaA7MFKH@google.com>

On Tue, 2021-02-09 at 17:07 +0000, Sean Christopherson wrote:
> On Tue, Feb 09, 2021, Dave Hansen wrote:
> > On 2/9/21 8:48 AM, Sean Christopherson wrote:
> > > On Tue, Feb 09, 2021, Dave Hansen wrote:
> > > > On 2/8/21 2:54 AM, Kai Huang wrote:
> > > > ...
> > > > > Add SGX_CHILD_PRESENT for use by SGX virtualization to assert EREMOVE
> > > > > failures are expected, but only due to SGX_CHILD_PRESENT.
> > > > This paragraph broke my brain when I read it.  How about:
> > > > 
> > > > 	Add a definition of SGX_CHILD_PRESENT.  It will be used
> > > > 	exclusively by the SGX virtualization driver to suppress EREMOVE
> > > > 	warnings.
> > > Maybe worth clarifying that the driver isn't suppressing warnings willy-nilly?
> > > And the error code isn't about suppressing warnings, it's about identifying the
> > > expected EREMOVE failure scenario.  The patch that creates the separate helper
> > > for doing EREMOVE without the WARN is what provides the suppression mechanism.
> > > 
> > > Something like this?
> > > 
> > >   Add a definition of SGX_CHILD_PRESENT.  It will be used exclusively by
> > >   the SGX virtualization driver to handle recoverable EREMOVE errors when
> > >   saniziting EPC pages after they are reclaimed from a guest.
> > 
> > Looks great to me.  One nit: to a me, "reclaim" is different than
> > "free".  Reclaim is a specific operation where a page is taken from one
> > user and reclaimed for other use.  "Free" is the more general case
> > (which includes reclaim) when a physical page is no longer being used
> > (because the user is done *or* had the page reclaimed) and may be either
> > used by someone else or put in a free pool.
> > 
> > I *think* this is actually a "free" operation, rather than a "reclaim".
> >  IIRC, this code gets used at munmap().
> 
> It does.  I used reclaim because userspace, which does the freeing from this
> code's perspective, never touches the EPC pages.  The SGX_CHILD_PRESENT case is
> handling the scenario where userspace has for all intents and purposed reclaimed
> the EPC from a guest.  If the guest cleanly tears down its enclaves, EREMOVE
> will not fail.
> 
> "free" is probably better though, the above is far from obvious and still not
> guaranteed to be a true reclaim scenario.  If using "freed", drop the "from a
> guest" part.

Thanks for feedback. I'll use below:

  Add a definition of SGX_CHILD_PRESENT.  It will be used exclusively by
  the SGX virtualization driver to handle recoverable EREMOVE errors when
  saniziting EPC pages after they are freed.