[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dc7ac02e-857a-b1ce-f444-0d244405a099@intel.com>
Date: Fri, 26 Mar 2021 08:35:34 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Borislav Petkov <bp@...en8.de>
Cc: seanjc@...gle.com, Kai Huang <kai.huang@...el.com>,
kvm@...r.kernel.org, x86@...nel.org, linux-sgx@...r.kernel.org,
linux-kernel@...r.kernel.org, jarkko@...nel.org, luto@...nel.org,
rick.p.edgecombe@...el.com, haitao.huang@...el.com,
pbonzini@...hat.com, tglx@...utronix.de, mingo@...hat.com,
hpa@...or.com
Subject: Re: [PATCH v3 05/25] x86/sgx: Introduce virtual EPC for use by KVM
guests
On 3/26/21 8:29 AM, Borislav Petkov wrote:
> On Fri, Mar 26, 2021 at 08:17:38AM -0700, Dave Hansen wrote:
>> We're working on a cgroup controller just for enclave pages that will
>> apply to guest use and bare metal. It would have been nice to have up
>> front, but we're trying to do things incrementally. A cgroup controller
>> should solve he vast majority of these issues where users are quarreling
>> about who gets enclave memory.
> Maybe I'm missing something but why do you need a cgroup controller
> instead of controlling that resource sharing in the sgx core? Or the
> cgroup thing has additional functionality which is good to have anyway?
We could do it in the SGX core, but I think what we end up with will end
up looking a lot like a cgroup controller. It seems like overkill, but
I think there's enough infrastructure to leverage that it's simpler to
do it with cgroups versus anything else.
Powered by blists - more mailing lists