All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: "Hansen, Dave" <dave.hansen@intel.com>,
	"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"Mallick, Asit K" <asit.k.mallick@intel.com>,
	"Scarlata, Vincent R" <vincent.r.scarlata@intel.com>,
	"Cai, Chong" <chongc@google.com>,
	"Aktas, Erdem" <erdemaktas@google.com>,
	"Annapurve, Vishal" <vannapurve@google.com>,
	"dionnaglaze@google.com" <dionnaglaze@google.com>,
	"bondarn@google.com" <bondarn@google.com>,
	"Raynor, Scott" <scott.raynor@intel.com>,
	"Shutemov, Kirill" <kirill.shutemov@intel.com>
Subject: Re: [PATCH 1/4] x86/sgx: Add total number of EPC pages
Date: Fri, 28 Mar 2025 10:42:13 +0200	[thread overview]
Message-ID: <Z-Zg5elc0xTwoxat@kernel.org> (raw)
In-Reply-To: <DM8PR11MB57503621B1D7674404A62004E7A02@DM8PR11MB5750.namprd11.prod.outlook.com>

On Fri, Mar 28, 2025 at 08:07:24AM +0000, Reshetova, Elena wrote:
> > Yes but obviously I cannot promise that I'll accept this as it is
> > until I see the final version
> 
> Are you saying you prefer *this version with spinlock* vs. 
> simpler version that utilizes the fact that sgx_nr_free_pages is changed
> into tracking of number of used pages? 

I don't know really what I do prefer.

Maybe +1 version would make sense where you keep with the approach
you've chosen (used pages) and better rationalize why it is mandatory,
and why free pages would be worse?

> 
> > 
> > Also you probably should use mutex given the loop where we cannot
> > temporarily exit the lock (like e.g. in keyrings gc we can).
> 
> Not sure I understand this, could you please elaborate why do I need an
> additional mutex here? Or are you suggesting switching spinlock to mutex? 

In your code example you had a loop inside spinlock, which was based on
a return code of an opcode, i.e. potentially infinite loop.

I'd like to remind you that the hardware I have is NUC7 from 2018 so
you really have to nail how things will work semantically as I can
only think these things only in theoretical level ;-) [1]


> 
> Best Regards,
> Elena.
> 

[1] https://social.kernel.org/notice/AsUbsYH0T4bTcUSdUW

BR, Jarkko

  reply	other threads:[~2025-03-28  8:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-21 12:34 [PATCH 0/4] Enable automatic SVN updates for SGX enclaves Elena Reshetova
2025-03-21 12:34 ` [PATCH 1/4] x86/sgx: Add total number of EPC pages Elena Reshetova
2025-03-22 21:58   ` Jarkko Sakkinen
2025-03-24 12:12     ` Reshetova, Elena
2025-03-26 19:43       ` Jarkko Sakkinen
2025-03-27 15:29         ` Reshetova, Elena
2025-03-27 21:28           ` Jarkko Sakkinen
2025-03-28  8:07             ` Reshetova, Elena
2025-03-28  8:42               ` Jarkko Sakkinen [this message]
2025-03-28  9:11                 ` Jarkko Sakkinen
2025-03-28  9:35                 ` Reshetova, Elena
2025-03-21 12:34 ` [PATCH 2/4] x86/sgx: Change counter sgx_nr_free_pages -> sgx_nr_used_pages Elena Reshetova
2025-03-22 22:10   ` Jarkko Sakkinen
2025-03-24 12:19     ` Reshetova, Elena
2025-03-26 20:07       ` Jarkko Sakkinen
2025-03-27 15:31         ` Reshetova, Elena
2025-03-27 21:21           ` Jarkko Sakkinen
2025-03-21 12:34 ` [PATCH 3/4] x86/sgx: Define error codes for ENCLS[EUPDATESVN] Elena Reshetova
2025-03-22 21:47   ` Jarkko Sakkinen
2025-03-24 12:21     ` Reshetova, Elena
2025-03-26 20:09       ` Jarkko Sakkinen
2025-03-27 15:38         ` Reshetova, Elena
2025-03-21 12:34 ` [PATCH 4/4] x86/sgx: Implement ENCLS[EUPDATESVN] and opportunistically call it during first EPC page alloc Elena Reshetova
2025-03-22 22:19   ` Jarkko Sakkinen
2025-03-24 12:26     ` Reshetova, Elena
2025-03-26 20:11       ` Jarkko Sakkinen
2025-03-27 15:42         ` Reshetova, Elena
2025-03-27 21:19           ` Jarkko Sakkinen
2025-03-28  8:27             ` Reshetova, Elena
2025-03-28  8:44               ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z-Zg5elc0xTwoxat@kernel.org \
    --to=jarkko@kernel.org \
    --cc=asit.k.mallick@intel.com \
    --cc=bondarn@google.com \
    --cc=chongc@google.com \
    --cc=dave.hansen@intel.com \
    --cc=dionnaglaze@google.com \
    --cc=elena.reshetova@intel.com \
    --cc=erdemaktas@google.com \
    --cc=kirill.shutemov@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=scott.raynor@intel.com \
    --cc=vannapurve@google.com \
    --cc=vincent.r.scarlata@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.